Rootless Docker and User Namespaces

Every control so far hardened the container. This one hardens the daemon. By default dockerd runs as root (Chapter 1, topic 05), so the daemon itself is a root-owned service and container root is host root. Rootless Docker runs the daemon and the containers it starts as an unprivileged user, and user-namespace remapping maps container UID 0 to an unprivileged host UID — so a container escape through that mapping lands as an unprivileged user, not root.

This is the last layer in the stack. The previous topics made driftwood/web run as a non-root user with no capabilities on a read-only filesystem, but all of that still sat on top of a root-owned daemon, and a daemon compromise or a deep escape was still a path to host root. Rootless mode removes that premise: a container escape no longer lands on a root-owned daemon, because there is no host root in the chain to begin with — the blast radius is the unprivileged account that started Docker. (A kernel-level exploit can still bypass any container boundary; rootless shrinks the damage, it does not abolish it.)

The Daemon Runs as Root by Default

dockerd, and every container it starts, runs with host root authority by default (Chapter 1, topic 05). That is why docker.sock is root-equivalent — anyone who can talk to the socket can start a container that mounts the host and reads or writes anything — and why a container escape is a root escape. The whole threat model of this chapter rests on that one default, and rootless mode is what finally removes it.

Rootless Docker

In rootless mode the daemon, containerd, and runc all run as a normal unprivileged user, not root. The containers that daemon launches are owned by that user. A compromise of the daemon, or an escape from a container, is bounded to that one unprivileged account instead of host root — the attacker lands as the user who started Docker, with whatever that user can do and nothing more. The root-owned socket and the root daemon, the two things that made escapes catastrophic, are simply not there.

User-Namespace Remapping

The user namespace maps the container's UID range onto a different host range, so container UID 0 becomes some high, unprivileged host UID — 100000 is the typical base. A process that believes it is root inside the container has no privileges at all on the host; its "root" is host UID 100000, which owns nothing important. This is the mechanism that makes "container root" safe, and it is precisely the namespace that was off back in topic 60, where container UID 0 was host UID 0. Turning it on is what severs that identity.

The Limitations

Rootless is not a free swap. It can't bind host ports below 1024 without extra configuration — the same privileged-port constraint the non-root app user hit in topic 60, now applied to the whole daemon. Some storage drivers and networking features are restricted or slower, and a few capability-dependent workloads simply won't run. You trade some convenience and a handful of edge features for a much smaller blast radius, which is a good trade on hosts where a root-owned daemon is the unacceptable risk.

# rootless dockerd already runs as your unprivileged user;
# the per-container hardening from this chapter still applies
docker run -d --name web \
  --user app \
  --cap-drop=ALL \
  --read-only --tmpfs /tmp \
  --security-opt no-new-privileges \
  -p 8000:8000 \
  driftwood/web

# publish a high port; rootless can't bind below 1024 by default,
# so the proxy on the host holds 80/443 in front of this

Nothing about the container flags changes under rootless Docker — the non-root user, dropped capabilities, read-only rootfs, and no-new-privileges are identical. What changes is underneath: the daemon serving this run is an unprivileged process, so the bottom of the stack is no longer root either. Driftwood is now hardened from the application down to the daemon.

Podman Is Rootless by Default

Podman runs rootless and daemonless out of the box — the full treatment is Chapter 12, topic 74. The posture that rootless Docker opts into is Podman's starting point: each podman run forks the container as a child of your shell, with no root-owned daemon anywhere. The trade-offs are the same, because both rest on the same user-namespace kernel feature — the low-port restriction and the storage-driver limits apply to Podman exactly as they do to rootless Docker. If you want rootless as the default rather than an opt-in, Podman is the tool that starts there.