Rootless Docker, RootlessKit, User Namespaces, Networking, Storage, Limitations, and Threat Reduction: Configuration, Design Choices, and Tradeoffs

1. Rootless versus rootful least privilege: choose the daemon boundary intentionally

2. RootlessKit network choices are operational choices, not invisible implementation details

Current rootless networking can use combinations of gvisor-tap-vsock, slirp4netns, pasta, and specific port drivers. Their throughput, source-IP behavior, SUID/helper requirements, and support status differ. Docker Engine 29.5 packaging stopped installing slirp4netns by default and introduced gvisor-tap-vsock as the preferred default path; Engine 29.8 updates RootlessKit to 3.1.0 and adds an optional pesto port driver with pasta.

Do not tune this from folklore. Capture Engine/RootlessKit versions, current driver configuration, actual latency/throughput, and source-IP requirements first.

3. Rootless BuildKit / daemon for CI versus privileged Docker-in-Docker

A user-owned rootless daemon or rootless BuildKit worker can be a useful CI boundary because build jobs do not need access to a shared rootful daemon socket. That reduces one class of escalation path. It does not automatically make untrusted builds safe: the kernel remains shared, build inputs can exfiltrate credentials, cache trust still matters, and host mounts can expand authority.

Docker documents a dind-rootless image, but when it is launched inside a rootful container it still requires outer --privileged. That means “rootless inside” must not be described as removing the outer privileged-container risk.

4. Resource governance: cgroup v2 + systemd delegation is a prerequisite, not a tuning hint

Rootless CPU, memory, and PID limits are supported when the host uses cgroup v2 and systemd can delegate the needed controllers to the user service. If the host does not provide that hierarchy, the right correction is at the host/user-service architecture—not pretending the Docker flag succeeded.

stat -fc %T /sys/fs/cgroup
systemctl --user status docker --no-pager 2>/dev/null || true
docker info --format 'CgroupVersion={{.CgroupVersion}} CgroupDriver={{.CgroupDriver}}' 

5. Storage design: choose supported state, then verify the actual driver

On modern Linux kernels, rootless overlay2 is preferred when supported. fuse-overlayfs provides compatibility on older kernels; btrfs and vfs have their own prerequisites/tradeoffs. Rootless Docker’s user-owned data root should not be placed on unsupported backing storage such as NFS.

Because a rootless daemon has its own image/container store, cache lifecycle and disk accounting are also per-daemon concerns. “The host has the image” is ambiguous unless the daemon/context is named.

6. Separate user daemons versus one shared rootful daemon

Per-user rootless daemons give users separate sockets, image stores, caches, networks, and container inventories. That improves isolation of Docker control planes but duplicates storage and may complicate shared-build caching. A shared rootful daemon centralizes storage and operations but gives every authorized socket client root-equivalent power over that host.

The decision is therefore about trust and tenancy, not convenience alone.

7. Docker Desktop is not “rootless Engine on your laptop”

Docker Desktop runs Docker Engine inside a managed Linux VM. Docker’s own Linux FAQ explicitly explains that Desktop chose a VM rather than ordinary rootless Docker to obtain a dedicated kernel and consistent cross-platform behavior. On macOS and Windows, container root is root inside that Linux VM, not root on the macOS/Windows host; host file sharing is an explicit boundary.

When comparing threat models, say native Linux rootless Engine, native Linux rootful Engine, or Docker Desktop VM Engine. Collapsing them into one “non-root Docker” category hides the most important boundary.

8. Decision worksheet

Knowledge check

Official references and version notes

• Docker Engine rootless mode — architecture, prerequisites, setup, contexts, and subordinate UID/GID requirements.
• Rootless mode tips — socket/data-root locations, systemd user service, cgroup resource controls, ports, and advanced operation.
• Rootless troubleshooting — supported storage drivers, cgroup requirements, unsupported features, networking drivers, source-IP behavior, and current host-network behavior.
• User namespace remapping — contrast between a rootful daemon with remapped containers and fully rootless daemon execution.
• Storage driver selection — rootless overlay2/fuse-overlayfs guidance and backing-filesystem considerations.
• Docker Engine 29 release notes — Engine 29.5 rootless networking changes and Engine 29.8 RootlessKit updates.
• Docker Desktop for Linux FAQ — why Docker Desktop uses a VM instead of ordinary Rootless Docker.
• Docker Desktop networking — VM/backend networking boundary on Desktop platforms.
• RootlessKit upstream — user-namespace networking and port-forwarding implementation used by Rootless Docker.