[Feature]: Support custom GPG keys for private repositories in Driver CRD

[botinca]

Description## Motivation

In restricted or air-gapped Kubernetes environments, deploying the GPU Operator requires using private package repositories (mirrors) to download the necessary driver dependencies. The NvidiaDriver CRD already provides parameters like certConfig for custom TLS certificates and repoConfig for private package manager repositories.
However, many enterprise-grade private mirrors use their own GPG keys for package signing and validation. Currently, there is no native way in the NvidiaDriver CRD spec to pass a custom GPG key to the driver installer pods, leaving a critical configuration gap for secure, private setups.

Current Workarounds

To make the driver daemonset pull packages from a signed private repository, users currently have to resort to two less-than-ideal workarounds:

1. Disabling security validation entirely by setting trusted=yes inside the repoConfig sources list, which violates security policies in production environments.
   2. Explicitly defining the key inline inside the sources list configuration using the signed-by option:

deb [signed-by=/etc/apt/sources.list.d/aptly-noble.asc] http://ubuntu.mirror ubuntu main

While this method works, it forces files to be mounted or generated in paths where they don't natively belong (e.g., placing .asc keyrings directly inside /etc/apt/sources.list.d/), which can lead to friction and conflicts during standard OS/APT operations inside the container.

Proposed Solution

It would be highly logical to introduce a gpgKeyConfig parameter alongside the existing certConfig and repoConfig. This would allow mounting a ConfigMap containing custom GPG public keys directly into the trusted keyring directories of the driver containers (e.g., /usr/share/keyrings/ or /etc/apt/trusted.gpg.d/ for Debian/Ubuntu).
Proposed CRD Spec Structure:

apiVersion: ://nvidia.comkind: NvidiaDrivermetadata:
name: nvidia-driverspec:
driver:
repoConfig:
configMapName: "custom-repo-config"
certConfig:
name: "custom-registry-certs"
gpgKeyConfig: # Proposed field
configMapName: "custom-gpg-keys"

The Operator would then automatically pick up this ConfigMap and safely mount it to the correct path depending on the underlying Linux distribution running inside the driver daemonset container.

[rahulait]

Thanks for the feature request and the detailed use case.

Securely using a signed private APT repository is already possible with the existing repoConfig support: include both the repository .list file and the public .asc key in the ConfigMap, then reference the key explicitly with signed-by, for example:

deb [signed-by=/etc/apt/sources.list.d/private-repo.asc] http://ubuntu.mirror ubuntu main

APT does not parse the .asc file as a repository definition, but it may emit a notice that the file is ignored while scanning /etc/apt/sources.list.d, since only .list and .sources are valid source-list filename extensions. The key can nevertheless be used successfully through the explicit signed-by reference.

A dedicated GPG-key configuration would provide a cleaner conventional keyring location and avoid this notice, but it is a usability enhancement rather than a requirement for securely using private repositories. We have not received other customer requests for this capability, so we do not currently plan to prioritize it.

Could you share a concrete example of any issue beyond the APT notice with the existing repoConfig approach? That would help us understand whether there is a case the current configuration cannot support.

If this is important to your environment and you are interested in contributing, community contributions are welcome.