Kubernetes Finally Has User Namespace Support. The Shared Kernel Problem Remains.

Kubernetes v1.36 shipped a feature the community has wanted for years: user namespace support for pods, now generally available. Set hostUsers: false and a container's root user remaps to an unprivileged UID on the host. A process that escapes the container boundary carries no administrative power over the node.

That is real progress. It is also not isolation.

The distinction matters more right now than it ever has.

What User Namespaces Actually Do

The mechanism is straightforward. When a pod sets hostUsers: false, UID 0 inside the container maps to an unprivileged user ID on the host. Capabilities like CAP_NET_ADMIN are scoped to the container's namespace rather than the host. If a process escapes the container boundary, it arrives on the host as nobody.

The Kubernetes team points to several HIGH and CRITICAL CVEs that user namespaces would have mitigated. That's accurate. Lateral movement between pods becomes harder when each pod's UIDs and GIDs map to non-overlapping ranges on the host.

These are meaningful mitigations. User namespaces reduce the blast radius of a specific class of container escapes. No serious reading of the feature should dismiss that.

But the Kubernetes announcement claims "we finally reached the point where 'rootless' security isolation can be used for Kubernetes workloads." That framing conflates two separate problems. One is what a compromised process can do with root on the host. The other is what any process can reach in the kernel. User namespaces address the first. They do not touch the second — and by some measures, they make it worse.

User Namespaces and the Kernel Attack Surface

Here is the part of the user namespace story that tends to get dropped from the announcement posts.

When a process calls unshare(CLONE_NEWUSER), it creates a new user namespace and receives a full set of capabilities inside it: CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_CHROOT. The documentation is correct that these capabilities don't grant host-level privileges. What the documentation leaves out is that those scoped capabilities invoke host kernel code that is not scoped at all.

CAP_NET_ADMIN inside a user+network namespace means a process can open a NETLINK_NETFILTER socket and interact directly with nftables. CAP_SYS_ADMIN inside a user+mount namespace means a process can mount tmpfs, overlayfs, devpts. The capabilities are namespaced. The kernel code they expose is not — it is the same nftables, overlayfs, and networking stack running in ring 0 on the shared host kernel.

We measured this directly. Running from inside an unprivileged container on an EKS cluster on kernel 6.18:

• Without user namespaces: 8 out of 40 tested kernel operations reachable
• With user namespaces: 27 out of 40

That is a 262% increase in kernel attack surface — reachable from an unprivileged container. We found 40 CVEs over five years that are only reachable when user namespaces are enabled. Eighteen of them are in nf_tables alone. CVE-2024-1086, a double-free in nf_tables verdict handling, achieved a 99.4% reliable exploitation rate for container escape. The exploit has 2,400 stars on GitHub.

User namespaces solve a real problem. They also expand the kernel surface available to hostile code. That tradeoff belongs in every announcement that calls user namespaces a security boundary.

The Shared Kernel Is Still the Problem

Every container on a Kubernetes node shares the same Linux kernel. That is true whether hostUsers is set to false or not. The kernel handles every syscall. It manages memory, networking, devices, and scheduling. It is the common substrate beneath every workload.

A kernel exploit bypasses user namespace protections entirely. If an attacker finds a vulnerability in a kernel subsystem — and the Linux kernel's CVE history makes clear these are found regularly — user namespace mapping does not enter the picture. The attacker is operating at a layer below where user namespace protections exist.

The announcement post acknowledges that without user namespaces, "a process running as root inside a container is also seen from the kernel as root on the host," and positions user namespaces as the fix. The fix addresses the UID layer. It does not address the kernel attack surface. Conflating those two problems misleads operators into believing their multi-tenant workloads are more isolated than they are.

For organizations running genuinely multi-tenant workloads — AI inference pipelines, untrusted code execution, regulated data — that distinction is not subtle. It is the difference between reducing blast radius and eliminating the blast path.

Why the Timing Makes This Urgent

When user namespaces became a Kubernetes feature, the assumption baked into every threat model was that finding exploitable kernel vulnerabilities was hard. It required elite talent, deep specialization, and weeks of manual work. That scarcity was a de facto part of most organizations' security posture.

That scarcity is gone.

Anthropic's Claude Mythos Preview scores 83.1% on CyberGym, Anthropic's cybersecurity capability benchmark, compared to 66.6% for Opus 4.6. That is not linear improvement. Nicholas Carlini, a research scientist at Anthropic, demonstrated near-100% success rates identifying remotely exploitable kernel vulnerabilities — including a buffer overflow in an NFS driver that went undiscovered for 23 years. Anthropic's red team produced 500 validated high-severity vulnerabilities using similar methodology. The bottleneck in vulnerability disclosure is no longer finding bugs. It is humans processing the flood of verified reports.

Kernel vulnerabilities are exactly the class of bug that bypasses user namespace protections entirely. The threat timeline has compressed from months to days. Detect-and-respond assumes you have a moment to respond. When exploit development is automated and parallel, that moment may not exist.

Layering namespace mitigations on top of a shared kernel, while AI-assisted exploit tools systematically probe that kernel for reachable bugs, is not a security posture. It is a patching treadmill that cannot be exited.

The Architecture That Changes the Threat Model

User namespaces operate above the kernel. The only controls that change the threat model operate below it.

Edera puts a Type-1 Xen-based hypervisor, rewritten in Rust, between workloads and the host. Each workload runs inside a zone — an isolated environment with its own kernel, memory, and device namespace. A kernel exploit inside a container has no path to the host or to adjacent workloads because there is no shared kernel to exploit.

This is not a narrower attack surface on a shared substrate. It is a different substrate entirely. The kernel inside each zone is isolated by hardware enforcement. What happens in one zone stays in one zone — not because a policy says so, but because the hypervisor boundary physically separates the memory spaces.

Zone startup is 766ms. CPU overhead is under 1%. A four-week public audit by Trail of Bits found zero critical findings. Security, performance, and density are not a tradeoff here — they are the point.

What Kubernetes v1.36 Gets Right

User namespace GA in Kubernetes v1.36 is a meaningful step. The community has worked toward this for years, and the result reduces exposure for a real class of attacks. Teams running multi-tenant workloads should enable it.

But "rootless security isolation" is not what user namespaces deliver. They remap identities. They do not isolate kernels. For the majority of workloads that will never face a targeted kernel exploit, that distinction may not matter in practice. For organizations running AI infrastructure, untrusted code, or multi-tenant SaaS on shared nodes — especially now, when the tools for finding kernel bugs are broadly available and improving rapidly — the distinction is everything.

Changing how root behaves is not the same as changing what it can reach. Until the boundary moves below the kernel, the failure mode stays the same.

FAQ

What did Kubernetes v1.36 change about user namespace support?

Kubernetes v1.36 brought user namespace support for pods to general availability. Setting hostUsers: false in a pod spec remaps the container's root user to an unprivileged UID on the host, so an escaped process carries no administrative power over the node.

Do user namespaces make Kubernetes containers secure?

User namespaces reduce the impact of certain container escapes, but they do not change the shared-kernel threat model. Every container on a Kubernetes node still shares the same Linux kernel. A kernel exploit bypasses user namespace protections entirely because it operates at a layer below where namespace remapping applies.

What is the shared kernel problem in Kubernetes?

Every container on a Kubernetes node makes syscalls to the same host kernel. If an attacker exploits a vulnerability in a kernel subsystem, they gain access to the host and every workload on the node, regardless of namespace configuration. Namespace controls restrict what a process can do with compromised privileges — they do not restrict which kernel code an attacker can reach.

Do user namespaces increase kernel attack surface?

Yes. When a process creates a user namespace, it receives capabilities scoped to that namespace. Those capabilities expose kernel subsystems — nftables, overlayfs, virtual network devices — that would otherwise be unreachable from an unprivileged container. Edera's research found a 262% increase in reachable kernel operations with user namespaces enabled, and 40 CVEs over five years that are only exploitable through user namespace access.

What provides actual kernel isolation for Kubernetes pods?

Hardware-enforced isolation. Running each pod in its own VM boundary — with its own kernel, backed by a Type-1 hypervisor — ensures that a kernel exploit inside one workload has no path to the host or adjacent workloads. Edera provides this through zones: isolated execution environments with sub-second startup and near-native performance.

‍A version of this blog was previously published on The New Stack on May 6, 2026.