What a Container Is at the Kernel Level: Namespaces, Cgroups, and Why GPU Containers Break the Model
For executives
A container is not a virtual machine. It does not have a separate OS kernel. It does not have hardware-enforced isolation from the host. A container is a Linux process that runs with a restricted view of the system, enforced by kernel features called namespaces and cgroups. Understanding this distinction is fundamental to understanding GPU container security: because containers share the host kernel, any vulnerability that crosses the boundary between the container's restricted view and the host's full view is a container escape.
What namespaces provide
Linux namespaces create isolated views of system resources for groups of processes. The namespaces relevant to containers:
Mount namespace: the process sees its own filesystem tree, not the host's. Container filesystems are layered images that appear as the root filesystem within the mount namespace.
PID namespace: the process sees only the processes in its namespace. The container's init process appears as PID 1.
Network namespace: the process has its own network stack, interfaces, and routing tables.
User namespace: processes can have different UIDs inside and outside the namespace. A process that appears to be root inside a container can be a non-root user on the host.
What cgroups provide
Control groups (cgroups) limit how much of a resource a process or group of processes can use. CPU time, memory, disk I/O, and GPU device access are all controllable via cgroups or analogous mechanisms.
What namespaces and cgroups do NOT provide
Namespaces and cgroups are software mechanisms enforced by the Linux kernel. They do not provide: hardware isolation (processes in a container share the host's physical hardware), kernel isolation (all containers share the same kernel — a kernel vulnerability exploited from inside a container gives the attacker access to the host kernel), or GPU isolation (the GPU is a physical device on the host, controlled by the Container Toolkit and device plugin, not by native kernel namespaces).
How GPU containers bridge the namespace boundary
A container normally has no access to GPU hardware — it is outside the container's namespace. The NVIDIA Container Toolkit bridges this gap by: bind-mounting GPU device files from the host into the container's mount namespace, bind-mounting host CUDA libraries into the container's filesystem, and configuring the container's environment for GPU access.
Each of these operations crosses the namespace boundary deliberately. When the Container Toolkit has a vulnerability, that deliberate crossing becomes an unintended crossing — a container escape.
Why container escape matters more for GPU containers
A CPU container escape reaches the host filesystem and process space. A GPU container escape reaches all of that plus the GPU memory and execution context of every other GPU workload on the node.