What Containers Isolate, and What They Do Not

TL;DR: A container is an ordinary process given a private view of the system by namespaces (processes, network, mounts, users), limited by cgroups (CPU, memory), stripped of capabilities, filtered by seccomp and confined by AppArmor or SELinux. All containers on a host share one kernel, so a kernel vulnerability, a privileged container, a mounted container runtime socket or a host path mount can lead to the host. That is fine for running your own trusted services; it is a thin boundary for hostile code. gVisor interposes a user-space kernel, and microVMs (Firecracker, Kata) give each workload its own guest kernel behind hardware virtualisation.

Before you read

Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.

1. 1A team runs an agent's code-execution tool in a Docker container on the application server. To let the agent build images, they mount /var/run/docker.sock into the container. What have they given the agent?

   Commit to a guess, then reveal

What a container actually is

There is no "container" object in the Linux kernel. A container runtime starts an ordinary process and applies several kernel features:

Together these make a container look like its own machine. The crucial fact is that every system call still goes to the same host kernel.

How containers fail as a security boundary

Kernel vulnerabilities. The host kernel exposes a large attack surface, hundreds of system calls, through which a contained process can attack it. A privilege-escalation bug in the kernel is usually a container escape.

Misconfiguration, which is far more common:

• --privileged grants nearly all capabilities and device access, removing most isolation.
• Mounting the container runtime socket (docker.sock, containerd's socket) lets the container start new privileged containers.
• Host path mounts of /, /etc, /var/run or credential directories expose the host directly.
• Adding capabilities such as CAP_SYS_ADMIN, disabling seccomp or AppArmor, sharing the host network or PID namespace.
• Running as root without user namespaces, so a breakout lands as root on the host.

The runtime itself. Escapes do not come only from misconfiguration. The low-level runtime that sets up containers, runc, has had several:

The lesson is operational: a patch deadline for the container runtime is part of the isolation design.

Root without user namespaces. If a process escapes as user 0 and the container did not use a user namespace, it is root on the host. Kubernetes made user namespaces generally available in version 1.36 (April 2026), turned on per pod with hostUsers: false, after enabling them by default in beta from 1.33. With them, root inside the container maps to an unprivileged user on the host.

Shared resources. Containers on one host share the kernel, page cache and often devices such as GPUs, which creates side channels and resource contention.

What the default seccomp profile actually blocks

Docker's default seccomp profile is an allowlist that disables around 44 of more than 300 system calls. The blocked ones are telling: mount; the kernel keyring calls (add_key, keyctl, request_key), because the keyring is not namespaced; the io_uring calls, which Docker blocks because of vulnerabilities that have been used to break out of containers; creating new namespaces with unshare or clone; and reboot. Everything else, including most of the kernel, remains reachable. A profile built for the specific workload can be much tighter.

Stronger boundaries

• gVisor runs a user-space kernel (the Sentry) that implements Linux system calls itself and makes only a small set of calls to the host kernel. A kernel bug reachable from the workload is usually in gVisor's code, not the host's.
• MicroVMs such as Firecracker (used by AWS Lambda and Fargate) and Kata Containers run each workload in a lightweight virtual machine with its own guest kernel, behind hardware virtualisation. Escaping requires a hypervisor or virtual-device bug, a much smaller surface.
• Full VMs give the strongest conventional isolation at higher cost.

The trade-off is overhead and compatibility: gVisor adds system call latency and does not support every feature; microVMs add startup time and memory; GPUs are hard to share safely across any of them.

The stronger boundaries, with numbers

GPUs: the AI-specific escape surface

AI platforms add a component most container discussions skip: the NVIDIA Container Toolkit, which prepares GPU access when a container starts. It has had two critical host escapes in two years.

• CVE-2024-0132 (September 2024, CVSS 3.1: 9.0): a time-of-check to time-of-use flaw meant a crafted image could reach the host filesystem in the default configuration. It affected toolkit versions up to 1.16.1 and GPU Operator up to 24.6.1. Found by Wiz.
• CVE-2025-23266 (July 2025, CVSS 3.1: 9.0, "NVIDIAScape"): a flaw in a container initialisation hook let a malicious image run code with elevated privileges on the host. It affected versions up to 1.17.7 and was fixed in 1.17.8, after being demonstrated at Pwn2Own Berlin in May 2025.

Both were reachable by an image, which is exactly what a platform that runs customer models or customer containers accepts. GPU sandboxing options are narrower too: Google's GKE Sandbox supports GPUs with gVisor only for CUDA on a subset of models and notes that microVMs do not support GPUs.

Worked example: CPU jobs and GPU jobs on one platform

A platform runs 2,000 short Python jobs an hour written by an agent, and also loads customers' fine-tuned models on GPUs. The sizing figures are illustrative; the per-VM figures are Firecracker's published ones.

• CPU jobs go in a microVM per session. At about 125 ms per boot, 2,000 boots cost about 250 seconds of start-up per hour in total. If 200 run at once, VMM overhead is about 1,000 MiB, plus each guest's own memory.
• GPU jobs cannot use Firecracker. The choices are Kata with QEMU and GPU passthrough, gVisor with supported CUDA GPUs, or a dedicated node per tenant.
• Either way, the GPU nodes run the container toolkit, so its version and patch deadline belong in the design review alongside the boundary choice.

Choosing

Why this matters for AI systems

Agents that write and run code, data-analysis tools that execute model-generated Python, and platforms that load customer-provided models all run code nobody reviewed. Containers alone are a thin boundary for that, and the common shortcuts (mounting the Docker socket, sharing the host network, passing cloud credentials) remove even that. The sandboxing lesson builds the full design.

Misconceptions interviewers listen for

• "Containers are a security boundary like VMs." They share the host kernel, and runc itself had escapes in 2019, 2024 and 2025.
• "gVisor stops everything." By its own documentation it does not address hardware side channels or resource exhaustion.
• "Firecracker gives me isolated GPUs." It has no GPU passthrough.
• "A non-root user in the image is enough." Without user namespaces, an escape as root is root on the host.
• "The default seccomp profile blocks the dangerous calls." It blocks about 44 of 300+.

What if · interview follow-ups

Hold your answer as the constraints change

You are designing isolation for a platform that runs agent-generated code and customers' fine-tuned models on shared Kubernetes clusters with GPU nodes. The interviewer probes each boundary.

1. 1

   Start here

   Why is mounting the container runtime socket into a container equivalent to giving it root?

   Nudge meAnswer it out loud, then reveal

Revising, not practising? Show every answer

Primary references

References for the mechanisms discussed above, accessed 6 November 2026:

• gVisor architecture: the userspace kernel boundary.
• Linux namespace types and semantics.

How this shows up in interviews

"Containers, gVisor, microVMs, VMs: where is each isolation boundary?" is a standard infrastructure question for AI security roles. Strong answers name the kernel features, say plainly that containers share the host kernel, list the misconfigurations that defeat them, and choose a boundary by how much the code is trusted. Expect a follow-up about GPUs.

Say it in 30 seconds: "A container is a process with namespaces, cgroups, dropped capabilities, seccomp and an LSM, all on a shared host kernel. That's fine for our own code, but a kernel bug or a misconfiguration like privileged mode, a mounted Docker socket or a host mount gets you to the host. For untrusted or model-generated code I use gVisor, which interposes a user-space kernel, or a microVM like Firecracker with its own guest kernel, and I still remove credentials and lock down egress."

Check yourself

Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.

1. 1Why does running a container as a non-root user help even though the container already has namespaces?

   Answer it, then reveal

2. 2A microVM sandbox for agent code has full outbound internet access and an environment variable holding a cloud API key. Is it a strong sandbox?

   Answer it, then reveal

3. 3Name two NVIDIA Container Toolkit vulnerabilities and why they matter for AI platforms.

   Answer it, then reveal

4. 4What do Kubernetes user namespaces change about a container escape?

   Answer it, then reveal