Making Kubernetes Safer with User Namespaces
summary
Proposal to add user namespace support to Kubernetes claims running root inside pods while remaining unprivileged on the host, reducing breakout impact. A working prototype exists in Kubernetes and containerd/cri and the effort is tracked as KEP 2101. Primary blocker is persistent volume handling: traditional mounts break ID mappings, so experiments with shiftfs and idmapped mounts show promise but expose performance and compatibility tradeoffs that still need resolution.
AI-written summary · about
chapters (5)
- 0:00Introduction to talk
- 3:37Kubernetes isolation challenges
- 8:00User namespaces solution
- 14:07Demo and practical use
- 19:15Summary and Q&A
related talks
25mIsolate the Users! Supporting User Namespaces in K8s for Increased Security
40mUser Namespaces in Kubernetes: Security and Flexibility - Pick Both
39mLinux User Namespaces: A Blessing and a Curse
22mRun As “Root”, Not Root: User Namespaces In K8s
31mTowards unprivileged container builds
31mUser Namespaces in Production: Enabling Root in Containers With RWX
47mLinux user namespaces: a blessing and a curse
35mSharing is Caring: Your Kubernetes Cluster, Namespaces, and You