What the GPU Operator Is: Kubernetes-Native GPU Management and Its Attack Surface
For executives
The NVIDIA GPU Operator is the Kubernetes component that automates the deployment and management of everything needed to run GPU workloads in a cluster: the GPU driver, the Container Toolkit, the device plugin, MIG configuration, and monitoring components. The GPU Operator's role gives it broad permissions across the cluster. Its security history — multiple CVEs directly involving the Operator — makes it a component that security teams should actively manage rather than treat as infrastructure background.
What the GPU Operator manages
In a Kubernetes cluster without the GPU Operator, deploying GPU support requires manually installing the NVIDIA driver on each node, deploying the Container Toolkit, configuring the device plugin, and managing updates manually. For clusters with many GPU nodes, this is operationally complex.
The GPU Operator automates this via Kubernetes reconciliation: it watches GPU nodes, deploys required components as DaemonSets, handles version management, and reconciles any drift from the desired configuration.
The components the GPU Operator deploys and manages: NVIDIA GPU driver (as a container, loaded as a kernel module), NVIDIA Container Toolkit, NVIDIA Kubernetes Device Plugin, NVIDIA DCGM (Data Center GPU Manager) for telemetry, MIG Manager for Multi-Instance GPU configuration, and GPU Feature Discovery for node labelling.
Why the GPU Operator's permissions are broad
To deploy DaemonSets, it needs permission to create DaemonSets in the namespace it manages. To manage node labels, it needs permission to modify node objects. To deploy the device plugin, it needs ServiceAccount permissions that allow the plugin to interact with the kubelet API.
This broad permission set is necessary. It also means that a compromise of the GPU Operator's controller pod gives the attacker significant cluster-wide authority.
CVE history directly involving the GPU Operator
The July 2025 Container Toolkit bulletin (CVE-2025-23266 and CVE-2025-23267) was simultaneously a GPU Operator bulletin. Patching required upgrading the GPU Operator (25.3.1 or later) as well as the Container Toolkit (v1.17.8). An organisation that patched the Container Toolkit directly on nodes without updating the GPU Operator risked the Operator reconciling the nodes back to the vulnerable version.
This is a specific operational challenge: the GPU Operator is not just a deployment vehicle — it is an active reconciliation system that will overwrite manual node configurations if they conflict with its desired state. Security patches applied manually can be reversed by the GPU Operator if the Operator's desired state still specifies the vulnerable version.
The Helm chart default configuration risk
The GPU Operator is deployed via a Helm chart with default values for all configuration parameters. Some default values may create security exposures. Security teams should audit the Helm chart values against security best practices rather than accepting defaults, particularly for parameters related to the Container Toolkit's security posture — including the allow-cuda-compat-libs-from-container flag introduced in the CVE-2025-23359 patch that re-enables a TOCTOU vulnerability if explicitly set.