NVIDIA / gpu-operator / 31182784777

38%

main: 38%

push

github

Mount ServiceAccount token when dcgm-exporter env needs API access

The dcgm-exporter DaemonSet sets automountServiceAccountToken=false and
re-enables it only when pod metadata enrichment is turned on through the
typed enablePodLabels/enablePodUID fields. Users who configure the same
features through raw dcgmExporter.env are missed by that condition, and
setting DCGM_EXPORTER_CONFIGMAP_DATA crashes the exporter on startup
since it cannot read the ServiceAccount token. This worked before the
token was made opt-in.

Mount the token when the user-provided env reads a ConfigMap or enables
pod labels / pod UID. A DCGM_EXPORTER_CONFIGMAP_DATA value of "none" is
the exporter default meaning no ConfigMap is read, so it does not count.
Configurations that make no API calls keep the default.

Apply the same env check to the cluster-scoped RBAC gate. Enrichment
through raw env otherwise got a token but no matching permissions,
leaving the pod informer with only the namespaced Role, which grants pod
reads in the operator namespace without watch. The ConfigMap case keeps
a separate condition since it needs no cluster-scoped RBAC: the
namespaced Role already grants configmaps get/list and its RoleBinding
is ungated.

The daemonset test compared gpuv1.EnvVar against the container's
corev1.EnvVar, which can never be equal. Both render as v1.EnvVar in
failure output, so the mismatch stayed invisible until a test case set
env on the ClusterPolicy.

Signed-off-by: Rajath Agasthya <ragasthya@nvidia.com>

24 of 24 new or added lines in 1 file covered. (100.0%)

5591 of 14535 relevant lines covered (38.47%)

0.44 hits per line