Root Without Risk: A Decade-Long Quest for True Container Isolation
summary
KEP‑127 enables mapping container root to an unprivileged host range so root inside becomes UID 65536 mapped on the node; end‑to‑end changes touch kubelet → CRI → containerd → runc with idmap mounts that cut startup chown time ~97%. Demos show CVE-2024-21626 Leaky Vessel no longer yields host root. Requires kernel >=5.12 (overlayfs idmap improvements in 6.3), Kubernetes v1.33+ defaults and v1.36 GA metrics; NFS and raw volume devices remain incompatible.
AI-written summary · about
chapters (19)
- 0:00Container root isolation intro
- 1:02Original root-in-container problem
- 2:08Security evolution in containers
- 3:52Kernel and filesystem milestones
- 5:37User namespace in Kubernetes
- 7:43ID mapping vs chown performance
- 8:47Host users flag simplified config
- 9:08Kubelet user namespace logic
- 10:32CRI API changes for user namespaces
- 11:54Syscalls behind user namespace mapping
- 13:40Verifying isolation in practice
- 15:05Leaky vessel vulnerability demo
- 18:59Container escape without user namespaces
- 20:46Secure isolation with user namespaces
- 21:49Tuning user namespace ranges
- 23:11Caveats and unsupported cases
- 23:52Production readiness and versions
- 25:12Security layers beyond user namespaces
- 26:32Q&A and advanced use cases
related talks
14mcontainerd: Rootless Containers 2020
22mRun As “Root”, Not Root: User Namespaces In K8s
30mThe Route To Rootless Containers
40mUser Namespaces in Kubernetes: Security and Flexibility - Pick Both
25mIsolate the Users! Supporting User Namespaces in K8s for Increased Security
31mTowards unprivileged container builds
38mUnderstanding root inside and outside a container
44mRootless containers