Rootless Container Architecture

In this lesson, you will learn how the Linux kernel facilitates running container orchestration stacks entirely within a non-privileged user context, bypassing the need for host root access.

The Foundation: Unprivileged User Namespaces

At the core of rootless container architecture lies the CLONE_NEWUSER namespace. By default, a non-privileged user cannot perform operations that require CAP_SYS_ADMIN (like mounting filesystems or configuring network bridges). However, when a process is granted a user namespace, it becomes the "root" inside that isolated environment. To the kernel, this user is mapped to a high-range sub-UID/GID on the host, effectively stripping them of any power over the host system while allowing them to manage internal container resources.

Kernel Requirements for Orchestration

To run a full stack (like Podman or Rootless Docker) without host root, the kernel must support specific primitives:

1. User Namespace Delegation: The kernel must permit unprivileged users to create namespaces. If kernel.unprivileged_userns_clone is set to 0, the architecture collapses.
2. Subordinate ID Mapping: The host must have /etc/subuid and /etc/subgid files configured. The kernel uses these to map the container’s "root" user to a range of non-privileged IDs on the host.
3. FUSE and Overlays: Without root, you cannot mount traditional overlayfs on the host kernel. Rootless architectures rely on fuse-overlayfs, which executes in userspace, or shiftfs, to handle filesystem permission mapping without requiring privileged mounts.
4. Network Namespaces: Since an unprivileged user cannot create a veth pair connected to the host’s physical bridge, the stack often employs slirp4netns. This tool bridges the container network to the host using a userspace-to-kernel translation layer.

Practical Implications

When a process inside a container attempts an action, the kernel validates it against the user namespace mapping:

# Example: Checking if you have user namespace mapping enabled
sysctl kernel.unprivileged_userns_clone

If the kernel sees you are a mapped root within a namespace, it allows the action only within that namespace. Because you lack global CAP_DAC_OVERRIDE or CAP_SYS_ADMIN, you remain a standard user from the perspective of the host’s kernel subsystems.

Key Takeaway: Rootless architecture relies on User Namespaces to map an unprivileged host process to a privileged container environment, ensuring the kernel treats the orchestration stack as a standard user regardless of the internal container identity.