Kubernetes 1.30: Enhanced Security with User Namespace for Pods

Linux offers various namespaces to isolate processes from each other. A typical Kubernetes Pod runs in a network namespace to isolate network identity and in a PID namespace to isolate processes.

One Linux namespace that has been overlooked until now is the User Namespace. This namespace allows us to isolate the user and group IDs (UIDs and GIDs) we use inside the container from those of the host.

This powerful abstraction allows us to run containers as “root”: we are root inside the container and can do everything a root within the Pod can do. However, our interactions with the host are limited to what an unprivileged user can do. This is great for limiting the impact of a container breakout.

A container breakout occurs when a process inside a container can escape to the host through an unpatched vulnerability in the container runtime or kernel, allowing it to access or modify files on the host or other containers. By running our Pods with User Namespaces, the permissions the container has over the rest of the host are reduced, and the files outside the container it can access are also limited.

In Kubernetes v1.25, we introduced support for User Namespaces only for stateless Pods. Kubernetes 1.28 lifted this restriction, and now, with Kubernetes 1.30, we are moving into the beta phase!

What is a User Namespace?

Note: Linux User Namespaces are a different concept from Kubernetes Namespaces. The former is a feature of the Linux kernel; the latter is a feature of Kubernetes.

User Namespaces are a Linux feature that isolates the UIDs and GIDs of containers from those of the host. The identifiers in the container can be mapped to identifiers on the host such that the host UIDs/GIDs for different containers never overlap. Moreover, the identifiers can be mapped to unprivileged, non-overlapping UIDs and GIDs on the host. This brings two key benefits:

• Prevention of lateral movement: Since the UIDs and GIDs for different containers are mapped to different UIDs and GIDs on the host, containers find it harder to attack each other, even if they cross container boundaries. Suppose Container A runs with different UIDs and GIDs on the host than Container B. In that case, the operations it can perform on Container B’s files and processes are restricted: it can only read/write what the file allows others to, as it will never have the owner’s or group’s permissions (the UIDs/GIDs on the host are guaranteed to be different for different containers).

• Increased host isolation: Since the UIDs and GIDs are mapped to unprivileged users on the host, a container that crosses container boundaries, even if running as root inside the container, has no privileges on the host. This significantly protects which host files it can read/write, which processes it can send signals to, etc. Moreover, the granted permissions are only valid within the User Namespace and not on the host, limiting the impact of a container breakout.

Without using a User Namespace, a container running as root would have root rights on the node in the event of a container breakout. If the container was granted some permissions, these would also be valid on the host. None of this applies when using User Namespaces (except in the case of bugs, of course 🙂).

By introducing User Namespaces in Kubernetes 1.30, the security and isolation of Pods are significantly enhanced. This is especially important for DevOps teams concerned with the security of their applications and data. At ayedo, we are happy to support you as a partner in implementing these new functionalities!

Source: Kubernetes Blog