Kubernetes v1.33: User Namespaces Now Enabled by Default!

In Kubernetes v1.33, support for user namespaces is enabled by default. This means that Pods, when system requirements are met, have the ability to use user namespaces. There’s no longer a need to activate a Kubernetes feature flag!

What are User Namespaces?

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.

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

One Linux namespace that is often overlooked is the user namespace. This isolates the UIDs and GIDs of containers from those of the host. Identifiers in a container can be mapped to identifiers on the host in such a way that there are no overlaps in UID/GIDs between host and container. Furthermore, the identifiers can be mapped to unprivileged, non-overlapping UIDs and GIDs on the host. This brings three 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 breach container boundaries. Suppose Container A runs with different UIDs and GIDs on the host than Container B. In this case, the operations Container A can perform on Container B’s files and processes are limited: it can only read/write what a file allows others to, as it never has owner or group 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 breaches container boundaries, even if it runs as root within the container, has no permissions on the host. This significantly protects which host files it can read/write, which processes it can address, etc. Moreover, the permissions granted are only valid within the user namespace and not on the host, which significantly limits the impact of a container escape.

• Enabling New Use Cases: User namespaces allow containers to gain certain permissions within their own user namespace without affecting the host. This opens up new possibilities, such as running applications that require privileged operations without granting full root access on the host. This is especially useful for running nested containers.

If a Pod running as a root user without a user namespace breaks out, it has root rights on the node. If some permissions were granted to the container, these are also valid on the host. None of this applies when using user namespaces (except in the case of bugs, of course 🙂).

With the introduction of user namespaces in Kubernetes v1.33, developers and DevOps teams can significantly enhance their security architecture and realize new, innovative use cases. ayedo is here as your partner to help you make the most of these new opportunities!

Source: Kubernetes Blog