Kubernetes v1.33 enables user namespaces by default for better isolation

In a post on the Kubernetes Blog in April 2025, maintainers announced that Kubernetes v1.33 enables support for Linux user namespaces by default. This change allows pods to opt into stronger isolation without requiring feature flags, provided the underlying infrastructure meets specific kernel and runtime requirements.

What happened

Prior to this release, using user namespaces in Kubernetes required enabling explicit feature gates and navigating complex configuration steps. With version 1.33, the feature is stable and active by default. When the stack requirements are met, users can simply opt in via pod specifications. This shift marks a significant step toward secure-by-default container orchestration, reducing the friction associated with implementing least-privilege security models.

The announcement clarifies that this is a Linux-only feature. It distinguishes Linux user namespaces, which isolate user identifiers at the kernel level, from Kubernetes namespaces, which are logical clusters for resources. The update aims to mitigate risks associated with container escapes by ensuring that processes running as root inside a container do not hold root privileges on the host node.

How it works

Linux user namespaces isolate the User IDs (UIDs) and Group IDs (GIDs) of processes within a container from those on the host system. When a pod uses a user namespace, the UIDs and GIDs inside the container are mapped to different, unprivileged identifiers on the host. For example, a process running as UID 0 (root) inside the container might map to UID 100000 on the host. This mapping ensures that even if a container process escapes its boundaries, it lacks the permissions to modify host files or interact with other host processes as a privileged user.

This mechanism relies heavily on "idmap mounts," a Linux kernel feature that applies UID/GID mappings when accessing mounted file systems. Idmap mounts allow each pod to use distinct UIDs on the host without requiring manual changes to file ownership (chown) on volumes. This simplifies volume management and enables features like sharing volumes between pods with different user mappings. However, the file systems used for volumes must support idmap mounts. Most common file systems are supported, but NFS is notably absent from current support lists.

Key details

• Opt-in mechanism: Users enable the feature by setting hostUsers: false in the pod specification.
• Kernel requirements: A Linux kernel version 6.3 or higher is recommended to support tmpfs for secrets and config maps. Kernel 5.19 is the minimum for overlayfs support.
• Runtime compatibility: Containerd version 2.0 or higher is required. CRI-O works out of the box. Other runtimes, including cri-dockerd, do not currently support this feature with Kubernetes.
• Security benefits: Prevents lateral movement between containers and ensures capabilities granted inside the namespace are invalid on the host.
• Limitations: Applications requiring direct host privileges, such as loading kernel modules, cannot use user namespaces. NFS volumes are not supported with idmap mounts.

Why it matters

For software engineers and platform teams, this update addresses a long-standing security dilemma: running applications as root inside containers for compatibility while trying to minimize host risk. Traditionally, running as non-root required significant application refactoring or complex custom solutions to manage file permissions. User namespaces allow teams to run applications as root internally without granting host-level privileges, effectively decoupling application logic from infrastructure security constraints.

The default enablement also strengthens defense against container escape vulnerabilities. Common CVEs, such as CVE-2024-21626 and CVE-2022-0492, are mitigated because escaped processes retain only unprivileged host identities. This reduces the attack surface for lateral movement, where a compromised container might otherwise access files or processes belonging to other containers on the same node. By guaranteeing unique host UIDs for each pod, the kubelet enforces isolation that was previously difficult to achieve consistently.

What you can do

• Verify your nodes are running Linux kernel 6.3 or newer to ensure full compatibility with tmpfs volumes.
• Upgrade container runtimes to containerd 2.0+ or ensure you are using a compatible version of CRI-O.
• Test existing workloads by adding hostUsers: false to pod specs in a staging environment to identify any permission-related issues.
• Review volume types used in your clusters; avoid NFS for pods opting into user namespaces until support is added.
• Consult the mount_setattr man page to check idmap mount support for specific file systems if using older kernels.
• Evaluate applications that require host-level privileges, such as kernel module loaders, as they will not function with user namespaces enabled.