Understanding Kubernetes User Namespaces and Their Evolution in v1.28

Kubernetes v1.25 introduced user namespace support limited to stateless Pods, and this restriction was removed in v1.28 after design changes in v1.27. The feature is simple to enable—just set a bool field in the Pod spec—and requires no code changes for most applications.

Key advantages include stronger container isolation, reduced impact of high and critical CVEs, and the ability to run containers with non‑privileged host IDs, preventing privilege escalation even if a container breaks out.

The article covers the basics of user namespaces, explains how they map container UID/GID to host IDs, and why they improve security compared to running containers as root.

Changes in v1.28 – User namespaces now support stateful Pods and any volume type. The feature flag was renamed from UserNamespacesStatelessPodsSupport to UserNamespacesSupport . Node requirements also changed, requiring Linux kernel 6.3+ and specific container runtimes (CRI‑O ≥ 1.28.1 with crun ≥ 1.9, containerd ≈ 2.0).

Demo – A demonstration using CVE‑2022‑0492 shows that the vulnerability is exploitable without user namespaces but mitigated when the feature is enabled.

Node System Requirements – Linux 6.3+, idmap mounts support, and compatible runtimes (CRI‑O, crun, runc, containerd) are needed. Containerd 1.7 provides experimental support but may add startup overhead.

Future Work – In Kubernetes 1.29, SIG Auth plans to integrate user namespaces into Pod Security Standards, relaxing checks for fields such as spec[.*].securityContext.runAsUser , runAsNonRoot , allowPrivilegeEscalation , and capabilities when user namespaces are used.

How to Contribute – Interested users can join the SIG Node Slack channel, mailing list, or GitHub, and contact the authors directly.