User Namespaces in Kubernetes: Security and Flexibility - Pick Both
summary
Kubernetes 1.30 enables user namespaces in beta so containers can map an internal root to an unprivileged host UID, reducing damage from escapes; demo shows a trivial runC bug that leaks a file descriptor and lets an attack escalate when host and container UIDs match. It requires containerd/runC release candidates (or crun) and Linux with ID‑mapped mounts (Linux 6.3 / Ubuntu 24.04). Works for Docker-in-Docker without --privileged by nesting cgroups via CRI/O; eBPF (Tetragon) and Kata/gVisor remain alternatives.
AI-written summary · about
chapters (6)
- 0:00User namespaces basics demo
- 6:50What user namespaces are
- 17:43Why Kubernetes added support
- 24:46Docker in user namespaces
- 31:34Security trade-offs
- 34:21Summary and future
related talks
25mIsolate the Users! Supporting User Namespaces in K8s for Increased Security
21mMaking Kubernetes Safer with User Namespaces
22mRun As “Root”, Not Root: User Namespaces In K8s
39mLinux User Namespaces: A Blessing and a Curse
47mLinux user namespaces: a blessing and a curse
31mTowards unprivileged container builds
32mRoot Without Risk: A Decade-Long Quest for True Container Isolation
32mLinux user namespaces: a blessing and a curse