Posts

This blog post is part of a series on user namespaces in Kubernetes. In the previous post, we saw how idmap mounts let containers with different userns mappings share volumes. Now let’s see what other questions we need to answer for the implementation: Who decides the mapping: the kubelet or the runtime? Kubernetes supports running different runtimes on one node, so the simplest approach is for the kubelet to decide the mappings. Otherwise, runtimes have no way to know if a range is already used by another runtime. How large should the mapping be for each pod? Most container images already use IDs up to 65535. If a UID in use is not mapped, it will be shown as the overflow id and you can’t modify it. So using 0-65535 seems like a simple choice here. The implementation The UID/GID space in Linux is 32 bits. We divide the ID space into chunks of 16 bits each: ...

This blog post is part of a series on user namespaces in Kubernetes. Although userns have been in Linux for a long time, limited support for volumes has held back wider adoption in the container world. Mappings and files When we create a userns, we need to specify a mapping: which UIDs and GIDs inside the container correspond to which ones outside. For example: UID inside userns UID outside userns count 0 100000 1 This maps UID 0 inside the userns to UID 100k outside. Processes inside the userns see themselves as UID 0 (even whoami says root), but from the host’s point of view they run as UID 100k. ...

This blog post is part of a series that will deep dive into user-namespaces support in Kubernetes. User-namespaces (userns) support reached GA in Kubernetes 1.36. This means you can have pods that run inside a user-namespace. The most common reasons people want to do that are: Improve isolation: Adopting it will significantly increase the host isolation and reduce lateral movement. UIDs/GIDs don’t overlap with any other pod or the host, and capabilities are only valid inside the pod. Secure nested containers: It’s possible to create a container inside a container with userns, so you can run dockerd inside a Kubernetes pod (with some other adjustments, but all available now), you can build container images, etc. How to use it One of the design goals was to make it trivial to adopt. All you need to do is set hostUsers to false in your pod spec. If you have the right versions of the stack, all will just work: ...