How do you implement rootless containers in production? Compare Docker rootless mode, Podman's rootless architecture, and user namespaces. What are the limitations and when do you still need privileged containers?
Quick Answer
Rootless containers run the container runtime and containers as a non-root user using user namespaces to map UID 0 inside the container to an unprivileged UID on the host. Podman is natively rootless (daemonless), Docker supports rootless mode (separate daemon per user). Limitations include no binding to privileged ports (<1024) and limited network modes.
Detailed Answer
User Namespace Fundamentals
User namespaces allow a process to have UID 0 (root) inside its namespace while being UID 100000+ on the host. This means even if a container escape occurs, the attacker has unprivileged access on the host. The mapping is defined in /etc/subuid and /etc/subgid.
Docker Rootless Mode
Docker can run its daemon (dockerd) as a non-root user since Docker 20.10+. The user runs dockerd-rootless.sh which starts a user-namespaced daemon. Containers launched by this daemon are doubly isolated: user namespace for rootless, plus standard container namespaces. - Storage: Uses fuse-overlayfs (slower than kernel overlayfs) or native overlayfs (kernel 5.11+) - Networking: Uses slirp4netns or pasta for userspace networking (no iptables access) - Port binding: Can't bind to ports <1024 without CAP_NET_BIND_SERVICE on the host
Podman Rootless
Podman is daemonless and natively designed for rootless operation. Each podman run creates a container directly without a long-running daemon. Uses the same user namespace and fuse-overlayfs stack but without the daemon overhead. Podman also supports systemd integration for container lifecycle management.
Limitations of Rootless
1. No access to privileged ports (<1024) - use port forwarding or sysctl net.ipv4.ip_unprivileged_port_start=80 2. Performance overhead from fuse-overlayfs (typically 5-15% for I/O heavy workloads) 3. No iptables/nftables manipulation - limited networking features 4. Cannot use overlayfs on older kernels (need 5.11+ for rootless overlayfs) 5. cgroup management may require systemd user delegation
When Privileged is Still Needed
- Network plugins that modify iptables (CNI in Kubernetes) - Storage drivers that need device mapper or direct LVM access - Hardware access (GPU, FPGA, SR-IOV) - Certain security tools (eBPF-based monitoring requires CAP_BPF)