Securing Kubernetes 1.33 Pods: The Impact of User Namespace Isolation and hostUsers: false

Kubernetes 1.33 was released on April 23, 2025, and, as usual, introduces a host of fixes and new features. Be sure to check out the release notes; I assure you, you won’t be disappointed!

As the Team Leader of a DevSecOps group, I tend to focus on security features. In this article, I want to highlight the new pod support for user namespaces.

This feature isn’t entirely new—it was first introduced as an Alpha feature (UserNamespacesSupport) in Kubernetes 1.28. However, as of version 1.33, it is enabled by default, and there’s no longer any need to set a Kubernetes feature flag.

This means the feature is now much easier to use, and you should definitely consider enabling it for your pods as well.

Why Is This So Important?

This capability relies on a Linux kernel feature that enables pods to use “user namespaces.” A pod is essentially a process (or a group of processes) running on a Kubernetes worker node, utilizing its CPU, memory, and storage.

With user namespaces, Kubernetes can remap the UID and GID of the pod within its own namespace, ensuring that it runs as an unprivileged user on the host. This greatly enhances the security of your workloads.

This is how the user namespace influences the UID remapping of the pods:

• Root inside Pod 1 (UID 0) → Host UID 65536
• Root inside Pod 2 (UID 0) → Host UID 131072

The Benefits of Enabling User Namespaces for Pods

Process Isolation
Each pod runs with a unique, unprivileged UID/GID range on the host, even if the container operates as root internally. This ensures that containerized processes cannot inadvertently (or maliciously) access host resources or other pods. For example, a root user inside the container maps to a non-root UID on the host, as described in Kubernetes’ default user namespace implementation.

Lateral Movement Prevention
By isolating UID/GID ranges per pod, a compromised container faces significant barriers to attacking adjacent pods or the host. Even if an escape occurs, the attacker inherits the pod’s unprivileged host identity, limiting access to files, processes, or network resources outside its namespace.

Enhanced Functionality Without Host Risk
User namespaces allow containers to safely use privileged capabilities (e.g., CAP_SYS_ADMIN for FUSE mounts) without exposing the host. This is particularly valuable for CI/CD pipelines where build containers often require elevated privileges but shouldn’t endanger the underlying node.

How to Enable User Namespaces

Starting with Kubernetes 1.33, user namespaces are enabled by default for pods that opt in via hostUsers: false in the pod spec.

Here’s a minimal example:

apiVersion: v1
kind: Pod
metadata:
  name: secured-pod
spec:
  hostUsers: false # Enables user namespace isolation
  containers:
    - name: nginx
      image: nginx:latest

Is User Namespace “Free” in Kubernetes 1.33?

While Kubernetes 1.33 enables user namespaces by default, adopting this feature isn’t entirely “free”, it requires specific infrastructure and runtime prerequisites. Below are the key requirements to ensure compatibility:

Prerequisites

Kubernetes Cluster

• v1.33+: User namespaces are enabled by default.
• v1.28–1.32: Requires enabling the UserNamespacesSupport feature gate.

Worker Node Requirements

• Linux Kernel ≥ 6.3: Mandatory for idmap mounts support.

Container Runtimes

• containerd ≥ 2.0 or CRI-O ≥ 1.25
• runc ≥ 1.2 or crun ≥ 1.9 (recommended: crun ≥ 1.13)

Storage File Systems The file system used for /var/lib/kubelet/pods/ must support idmap mounts. Compatible options include:

Why These Requirements Matter

• Idmap Mounts: Ensure file ownership mappings between container and host users work seamlessly. Without this, volumes (e.g., ConfigMaps, Secrets) may fail to mount correctly.
• Runtime Compatibility: Older runtimes like cri-dockerd lack user namespace support, necessitating upgrades to containerd or CRI-O.

Security Impact: A Nice Improvement!

User namespaces mitigate critical vulnerabilities like CVE-2022-0492 (container escape via cgroups). By mapping container root to unprivileged host UIDs, even compromised pods cannot escalate privileges on the host.

For a hands-on demonstration, watch this video showing how user namespaces block container breakouts.
For deeper insights, refer to the Kubernetes documentation or this blog post .