User Namespaces: Stateful Pods Now Available in Kubernetes 1.28!

Kubernetes v1.25 introduced support for user namespaces only for stateless Pods. With Kubernetes 1.28, this limitation has been lifted following some design changes made in version 1.27.

The beauty of this feature lies in the fact that:

• it can be adopted effortlessly (just set a boolean field in the Pod specification)
• no changes are required for most applications
• security is drastically improved by enhancing container isolation and mitigating CVEs rated HIGH and CRITICAL.

This post explains the basics of user namespaces and demonstrates:

• the changes introduced with the current Kubernetes v1.28 release
• a demonstration of a HIGH-rated vulnerability that cannot be exploited with user namespaces
• the runtime requirements to leverage this feature
• what you can expect in future versions regarding user namespaces.

What is a User Namespace?

A user namespace is a Linux feature that isolates the user and group identifiers (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 used for different containers never overlap. Additionally, the identifiers can be mapped to unprivileged non-overlapping UIDs and GIDs on the host. This essentially means two things:

• 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 break out of the container boundaries. For example, if Container A runs with different UIDs and GIDs on the host than Container B, the operations it can perform on Container B’s files and processes are limited: it can only read/write what a file allows for others, as it will never have owner or group permissions (the UIDs/GIDs on the host are guaranteed to be different for different containers).

• Since the UIDs and GIDs are mapped to unprivileged users on the host, a container that breaks out of its 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 send signals to, etc.

Moreover, the granted capabilities are only valid within the user namespace and not on the host.

Without using a user namespace, a container running as root would have root privileges on the node in the event of a container breakout. And if the container was granted some capabilities, those capabilities would also be valid on the host. None of this applies when using user namespaces (except for bugs, of course 🙂).

Changes in 1.28

As mentioned earlier, starting with version 1.28, Kubernetes supports user namespaces with Stateful Pods. This means that Pods with user namespaces can use any type of volume and are no longer restricted to certain volume types as before.

The feature flag to enable this function has been renamed. It is no longer called UserNamespacesStatelessPodsSupport, but from 1.28 onwards, you should use UserNamespacesSupport. Many changes have been made, and the requirements for node hosts have changed. The feature flag was renamed to reflect this.

ayedo GmbH is happy to support you in implementing and utilizing Kubernetes and new features like user namespaces to make your applications more secure and flexible.

Source: Kubernetes Blog