Pod user namespaces are stable: set hostUsers to false and verify

On 6 October 2026 the Kubernetes blog reminded cluster operators that pod user namespace support graduated to stable in Kubernetes v1.36. The feature maps root inside a container to an unprivileged user on the node, so a process that escapes the container lands on the host with no administrative rights. It is one of the few container hardening settings that costs almost nothing in application changes.

What's affected

The feature is opt-in per pod, so nothing changes until you set hostUsers: false in the pod spec. The Kubernetes documentation lists what the node needs first:

• Linux nodes only, with a filesystem for /var/lib/kubelet/pods/ that supports idmap mounts (btrfs, ext4, xfs, fat, tmpfs and overlayfs are listed).
• Linux 6.3 or later, because tmpfs gained idmap mount support in that kernel and Kubernetes uses tmpfs for service account tokens and Secrets.
• runc 1.2 or later, or crun 1.9 or later (1.13 or later recommended).
• containerd 2.0 or later, or CRI-O 1.25 or later.

Pods that use a user namespace cannot also set hostNetwork, hostIPC or hostPID, cannot use raw block volumes, and cannot mount NFS volumes, because the Linux NFS client does not yet support idmap mounts.

What to do now

1. Check kernel and runtime versions on each node pool. uname -r gives the kernel, and containerd, CRI-O and runc each print their version from their own version command.
2. Pick one low-risk workload that runs as root but does not touch host namespaces, and add the field:

apiVersion: v1
kind: Pod
metadata:
  name: userns
spec:
  hostUsers: false
  containers:
  - name: app
    image: debian:trixie-slim
    command: ["sleep", "3600"]

3. Prove the mapping. Inside the pod run readlink /proc/self/ns/user and cat /proc/self/uid_map. The docs say the last number in uid_map must be 65536 inside the container and a larger number on the host, and the namespace id must differ from the one you see on the node.
4. Watch the kubelet metrics started_user_namespaced_pods_total and started_user_namespaced_pods_errors_total while you roll out. A rising error counter usually means a volume on a filesystem without idmap support.
5. Expand pool by pool. Keep host namespace pods (CNI agents, node exporters) outside this policy, since they cannot use it.

The documentation notes that several HIGH and CRITICAL container vulnerabilities were not exploitable while user namespaces were active, and that the project expects the feature to blunt future ones. That is mitigation, not a replacement for patching.

Quick check

Sources

• Kubernetes blog: The Shift to cgroup v2 in Kubernetes (6 October 2026)
• Kubernetes docs: User Namespaces
• Kubernetes docs: Use a User Namespace With a Pod