Userns-in-Kubernetes-Series

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 needed to answer for a Kubernetes implementation: Who decides the mapping: the kubelet or the runtime? Kubernetes supports running different runtimes on one node, so the kubelet needs 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. Using 0-65535 is a sensible choice here and also divides the 32-bit UID space evenly. How to choose which ID (UIDs/GIDs) range a pod will use? Pods have a unique ID range chosen on the node at pod creation time that doesn’t overlap with ranges used by other pods. After the last post, we know we can do that without issues if we use idmap mounts. This gives pods better isolation in case of a container breakout: they can’t read/write inodes owned by a different UID/GID (unless the inodes have permissions for others), they can’t send signals to other pods, etc. Furthermore, we can also reserve a separate range for the host’s files and processes, extending the same isolation to the host. 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 has 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 also lets you run tools like apt inside the container. ...

This blog post is part of a series that will deep dive into user-namespaces support in Kubernetes. New to user namespaces? See question 6 for introductory material. 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: ...