User Namespace Remapping

The kernel translates the container's root user (UID 0) to a high-numbered, unprivileged UID (e.g., 100000) on the host. This mapping is defined in the /etc/subuid and /etc/subgid files. Inside the container, the process believes it has full root capabilities, but on the host, it operates with the permissions of a regular user, rendering a container escape ineffective for gaining host root.

The primary threat model addressed is a container escape where an attacker exploits a kernel vulnerability to break out of the container's namespaces. Without remapping, a successful escape immediately grants root-level access to the entire host. With user namespace remapping enabled, the escaped process finds itself running as an unprivileged high-numbered user on the host, with no access to root-owned files or the ability to perform privileged system calls, effectively neutering the attack.

User namespaces are the foundational technology enabling rootless containers. Runtimes like Podman and rootless Docker daemons leverage this feature to allow users to build, run, and manage containers without any root privileges whatsoever. This shifts the security boundary from the daemon to the user, eliminating the risk of a compromised container runtime granting an attacker host root access.

When user namespaces are enabled, the container runtime must manage file ownership carefully. Files created by the container's root (UID 0) are actually owned by the high-numbered host UID on disk. This requires a shadowed filesystem or a dedicated storage driver that correctly maps UIDs during file operations. Tools like newuidmap and newgidmap are used to set up these mappings before the container process starts.

User namespace remapping works in concert with other Linux security primitives. When a process creates a new user namespace, it gains a full set of capabilities within that namespace only. This allows an unprivileged user on the host to create a container where they appear as root and can mount filesystems or bind to privileged ports—operations that are strictly scoped to the namespace and have no effect on the host. This is the mechanism that makes rootless containers functionally powerful yet securely isolated.

In Kubernetes, user namespace remapping is supported as a Pod-level security feature (graduating to stable in v1.30). When enabled via the hostUsers: false field in a Pod's security context, the kubelet creates a unique user namespace for the Pod, mapping its users to a range of unprivileged host UIDs. This provides a critical additional layer of defense for multi-tenant clusters, ensuring that a container breakout in one tenant's Pod does not compromise the host or other tenants.

A granular privilege model that splits the traditional all-or-nothing root privilege into distinct units. Instead of running as root, a process gets only the specific capabilities it needs.

• CAP_NET_BIND_SERVICE allows binding to ports below 1024 without full root
• CAP_SYS_ADMIN is a particularly dangerous catch-all capability that should almost never be granted
• Combined with user namespace remapping, even a process that thinks it has full capabilities is actually constrained