Xshell Lab

With the release of Kubernetes v1.36, User Namespaces have finally reached General Availability (GA) after years of development. This Linux-only feature marks a pivotal moment for cluster security, enabling truly rootless workloads. In this Q&A, we break down what User Namespaces mean, how they work under the hood, and how you can start using them today.

1. Why is the GA of User Namespaces such a big deal for Kubernetes?

The move to GA means User Namespaces are now production-ready and fully supported. For security-focused teams, this brings the long-awaited ability to run containers with true rootless isolation. Previously, root inside a container was still root on the host – a major attack vector. With User Namespaces, you can set hostUsers: false in your Pod spec, and the container's root user becomes a non-privileged user on the host. This dramatically reduces the impact of container breakouts. Capabilities like CAP_NET_ADMIN become namespaced, giving workloads administrative power over container-local resources without affecting the host. In short, it closes a fundamental security gap that has existed since Kubernetes began.

2. How does the root user inside a container pose a security risk?

By default, a process running as UID 0 (root) inside a container is also seen as root by the host kernel. If an attacker exploits a kernel vulnerability, misconfiguration, or mount issue to break out of the container, they gain full root privileges on the host node. While Kubernetes has many security layers (e.g., Pod Security Policies, seccomp, AppArmor), none change the underlying identity of the process – it still retains some 'root-like' power. User Namespaces solve this by remapping the container's UID 0 to a high, unprivileged UID on the host. Even if the container process escapes, it has no more privileges than a regular user, effectively neutering many exploits.

3. What is ID-mapped mounts and why was it essential for this feature?

ID-mapped mounts (introduced in Linux 5.12) are the engine that makes User Namespaces practical. Before this kernel feature, volumes mounted into a user-namespaced Pod required the kubelet to perform a recursive chown on every file – an O(n) operation that destroyed startup performance for large volumes. With ID-mapped mounts, the kernel transparently remaps UIDs/GIDs at mount time. The container sees files owned by UID 0, while on disk ownership remains unchanged. This is an O(1) operation – instant and efficient. No modifications to container images or volume data are needed. This breakthrough removed the biggest blocker to user namespace adoption in production.

4. How can I enable User Namespaces for my Pods in v1.36?

Enabling User Namespaces is straightforward – simply set hostUsers: false in your Pod spec. No changes to container images or complex configuration are required. The interface remains identical to what was 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

When hostUsers: false is set, Kubernetes automatically creates a user namespace for the Pod. The container can still run as root (UID 0) – but that root is mapped to a high, unprivileged UID on the host. This works with stateful workloads, volumes, and all standard Kubernetes features.

5. Are there any prerequisites or limitations for using User Namespaces?

Yes, a few important notes:

• Linux only: This feature requires a Linux node kernel version 5.12 or later (for ID-mapped mounts).
• Volume support: All volumes attached to the Pod must support ID-mapped mounts. Most common volume types (hostPath, CSI drivers, etc.) work, but verify with your storage provider.
• No changes to images: Container images do not need modification – the remapping is done at the kernel level.
• Capability behavior: Capabilities like CAP_NET_ADMIN become namespaced – they grant control over container-local resources, not host resources.
• Performance: Since no chown is needed, startup time is unaffected.

For more details, see the earlier blog posts on User Namespaces alpha, stateful pods, and beta enhancements.

6. What new use cases does this feature enable?

User Namespaces unlock workloads that previously required fully privileged containers. For example:

• Network tools: Containers needing CAP_NET_ADMIN can now modify their own network stack without host access.
• System daemons: Services like NTP or DHCP clients can run as 'root' inside the container while being confined to the user namespace.
• Build environments: CI/CD pipelines that install packages or modify system files can do so safely.
• Multi-tenant clusters: Operators can offer stronger isolation between tenants without using VM-based solutions.

Previously, achieving this level of separation required complex seccomp profiles, AppArmor, or even running containers in VMs (e.g., Kata Containers). User Namespaces provide a simpler, kernel-native approach.

7. How does this compare to previous rootless container approaches?

Earlier rootless container solutions (e.g., Rootless Podman, rootless containerd) required running the entire container runtime as a non-root user. This prevented many use cases because standard volumes, privileged operations, and certain networking features were broken. Kubernetes v1.36's User Namespaces integration works at the Pod level – the runtime and kubelet remain privileged, but each Pod gets its own user namespace. This means all existing Kubernetes features (including CSI volumes, service meshes, and network policies) continue to work. The feature is also transparent to the container image: you can use any image that expects to run as root, and it will run securely in a user namespace. It's a significant step forward in hardening cluster workloads.