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 userNamespace influence the UID remapping of the pods
Host UID/GID Range | Usage | Container UID/GID Mapping |
0 – 65535 | Reserved for host | N/A |
65536 – 131071 | Pod 1 | 0 – 65535 (in container) |
131072 – 196607 | Pod 2 | 0 – 65535 (in container) |
196608 – 262143 | Pod 3 | 0 – 65535 (in container) |
... | ... | ... |
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 are clear and impactful:
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 Namespaces "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:
File System | Notes |
ext4 | Widely supported |
xfs | Requires ftype=1 |
tmpfs | Suitable for ephemeral storage |
overlayfs | Default for container layers |
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.
Next Steps
Verify Kernel and Runtimes: Use uname -r and containerd --version to check compatibility.
Audit Storage: Ensure /var/lib/kubelet uses a supported file system.
Test Gradually: Start with non-critical pods using hostUsers: false
For deeper insights, refer to the Kubernetes documentation or this blog post .
No comments:
Post a Comment