Kubernetes v1.36 Makes User Namespaces Generally Available: A New Era for Container Security

Introduction

With the release of Kubernetes v1.36, a long-anticipated security feature has finally reached General Availability (GA): User Namespaces. This Linux-only capability marks a significant milestone for container security, particularly for those working with low-level runtimes and rootless technologies. After years of development, Kubernetes workloads can now benefit from true rootless isolation, and administrators gain new ways to manage container privileges without compromising host security.

Kubernetes v1.36 Makes User Namespaces Generally Available: A New Era for Container Security

The Long-Awaited GA

User Namespaces have been in the making for several releases, progressing from alpha to beta and now to stable. The GA status in v1.36 confirms that the feature is production-ready. It enables a critical pattern: running workloads with specific privileges while still confining them within a user namespace. When you set hostUsers: false in a Pod spec, capabilities like CAP_NET_ADMIN become namespaced—they grant administrative control over container-local resources without affecting the host. This opens up use cases that previously required fully privileged containers.

Why User Namespaces Matter

The Problem with UID 0

In traditional container deployments, a process running as root (UID 0) inside a container is also seen as root by the host kernel. If an attacker exploits a kernel vulnerability or a misconfigured mount, they could break out of the container and gain root access on the host. While various security measures exist—such as seccomp, AppArmor, and read-only root filesystems—they do not change the underlying identity of the process. The process retains some "parts" of root, leaving a residual attack surface.

User Namespaces solve this by mapping the container's root to a non-privileged UID on the host. Even if a container process is compromised, it has no special privileges outside its namespace.

The Technical Breakthrough: ID-Mapped Mounts

The journey to GA wasn't just about the Kubernetes API; it required kernel-level support. One of the biggest blockers was volume ownership. Originally, if you mapped a container to a high UID range, the Kubelet had to recursively chown every file in attached volumes so the container could read or write them. For large volumes, this operation was prohibitively expensive, destroying startup performance.

The key enabler was ID-mapped mounts, introduced in Linux 5.12 and refined in later versions. Instead of rewriting file ownership on disk, the kernel remaps UIDs and GIDs at mount time. When a volume is mounted into a Pod with User Namespaces enabled, the kernel performs a transparent translation. To the container, files appear owned by UID 0; on disk, ownership remains unchanged—no chown is needed. This is an O(1) operation: instant and efficient.

How to Use User Namespaces in Kubernetes v1.36

Using User Namespaces is straightforward. All you need to do is set hostUsers: false in your Pod spec. No changes to your container images are required, and there's no complex configuration. The interface remains the same as introduced during the alpha phase. Here's an example:

apiVersion: v1
kind: Pod
metadata:
  name: isolated-workload
spec:
  hostUsers: false
  containers:
  - name: app
    image: fedora:42
    securityContext:
      runAsUser: 0

In this example, the container runs as UID 0, but that root is mapped to a non-privileged user on the host. The hostUsers: false setting opts out of the host user namespace, providing isolation.

What This Means for Workloads

With GA, Kubernetes administrators can now run workloads that require certain capabilities—like CAP_NET_ADMIN for network configuration—without granting host-level privileges. These capabilities are fully namespaced, meaning they only affect resources within the container's user namespace. This enables new patterns for network plugins, storage tools, and other privileged operations while maintaining strong security boundaries.

Additionally, User Namespaces mitigate many container escape vulnerabilities. In practice, several CVEs rated HIGH have been demonstrated to be ineffective when User Namespaces are enabled. For detailed examples, refer to the previous blog posts:

Looking Ahead

The GA of User Namespaces in Kubernetes v1.36 is a testament to the community's dedication to improving container security. While the feature is currently Linux-only, it lays the groundwork for broader adoption. As more workloads adopt hostUsers: false, the overall security posture of Kubernetes clusters will improve significantly. For those involved in container runtimes and rootless technologies, this is indeed a milestone worth celebrating.

Now is the time to test User Namespaces in your environments. Start with non-production workloads, validate compatibility with your storage and networking plugins, and plan for gradual rollout. The future of secure, isolated containers is here.

Server Virtualization