Rootless Docker: Wann es sich lohnt

1. Was Rootless Docker genau bedeutet

Im klassischen Setup läuft der Docker-Daemon als Root-Prozess auf dem Host. Jeder Benutzer, der Socket-Zugriff auf /var/run/docker.sock hat, besitzt de facto Root-Rechte auf dem Host, weil er Container mit Bind-Mounts starten, auf Host-Dateisysteme zugreifen und privilegierte Container hochfahren kann. Rootless Docker ändert dieses Modell grundlegend: Daemon und Container laufen als normaler Benutzer, isoliert durch Linux User Namespaces.

Die technische Grundlage von Rootless Docker sind Linux User Namespaces in Kombination mit dem newuidmap- und newgidmap-Mechanismus. Der Benutzer erhält einen privaten UID-Raum, in dem er UIDs von 0 (Root im Container) auf nicht-privilegierte UIDs des Hosts mappen kann – üblicherweise aus dem in /etc/subuid und /etc/subgid definierten Bereich. Root im Container ist also UID 100000 auf dem Host und hat dort keinerlei erhöhte Rechte. Ein Ausbruch aus dem Container würde nur Zugriff auf den Benutzeraccount des Docker-Nutzers geben, nicht auf Root des Hosts.

Seit Docker Engine 20.10 ist Rootless Docker produktionsreif und wird über das Installationsskript dockerd-rootless-setuptool.sh eingerichtet. Jeder Benutzer betreibt eine eigene Daemon-Instanz unter seinem Benutzerkontext, mit eigenem Docker-Socket in $XDG_RUNTIME_DIR/docker.sock. Das bedeutet, dass mehrere Entwickler auf demselben Server vollständig voneinander isolierte Docker-Umgebungen betreiben können, ohne Root-Rechte zu teilen.

2. Sicherheitsvorteile: Warum Root-Daemon riskant ist

Der klassische Docker-Socket /var/run/docker.sock ist bekannt als "Root-Backdoor". Jede Anwendung – Container, CI-Job, Script – mit Zugriff auf diesen Socket kann beliebige Container starten und damit vollen Root-Zugriff auf den Host erlangen. Das ist das zentrale Sicherheitsproblem von rootful Docker. Rootless Docker eliminiert diesen Angriffsvektor: Selbst wenn ein Angreifer den Docker-Socket eines Nutzers kompromittiert, erhält er nur Zugriff auf den Benutzerkontext dieses Nutzers – nicht auf Root des Hosts.

Ein zweiter kritischer Sicherheitsvorteil betrifft Container-Ausbrüche. Bekannte Container-Escape-Techniken nutzen Kernel-Schwachstellen aus, die Root-Rechte im Namespace erfordern. Bei Rootless Docker ist Root im Container auf dem Host ein unprivilegierter Benutzer – viele Kernel-Exploits scheitern daran, weil sie echte Host-Root-Rechte benötigen. Das reduziert die Wirksamkeit von Container-Escape-Angriffen erheblich, auch wenn es keinen vollständigen Schutz bietet.

Für Multi-Tenant-Umgebungen, in denen mehrere Teams oder Kunden auf demselben Host containerisierte Workloads betreiben, ist Rootless Docker besonders relevant. Jeder Benutzer betreibt seinen eigenen Daemon, hat keinen Einblick in die Container anderer Benutzer und kann nicht durch Fehlkonfiguration die Container anderer Nutzer beeinflussen. Diese Isolation ist mit rootful Docker und dem gemeinsamen Daemon-Socket nicht erreichbar.

3. Einschränkungen, die niemand erwähnt

Rootless Docker hat reale Einschränkungen, die in vielen Blog-Beiträgen unterschlagen werden. Die wichtigste: Ports unter 1024 können ohne zusätzliche Konfiguration nicht gebunden werden. Wer einen Webserver auf Port 80 oder 443 starten will, muss entweder net.ipv4.ip_unprivileged_port_start=80 im Kernel setzen oder über einen Reverse Proxy auf höhere Ports weiterleiten. Das ist lösbar, erfordert aber Anpassung bestehender Setups.

Overlay-Netzwerke – die Grundlage für Docker Swarm – funktionieren ohne Root-Rechte nicht vollständig. Rootless Docker verwendet stattdessen slirp4netns oder pasta für die Netzwerkimplementierung, was zu messbarem Performance-Overhead bei netzwerkintensiven Workloads führt. Für einfache Web-Anwendungen ist der Unterschied vernachlässigbar, für Datenbank-Replikation oder hochfrequentierte APIs kann er relevant sein.

Cgroup v1 wird von Rootless Docker nicht für die Ressourcenlimitierung unterstützt – dafür ist Cgroup v2 erforderlich, das in modernen Distributionen (Debian 11+, Ubuntu 21.10+, RHEL 9+) standardmäßig aktiv ist. Auf älteren Systemen bedeutet das, dass docker run --memory und --cpus ohne Cgroup v2 nicht funktionieren. Das ist ein relevantes Problem für Umgebungen, die Ressourcenlimits zur Isolation nutzen.

4. Installation und Konfiguration von Rootless Docker

Die Installation von Rootless Docker setzt voraus, dass uidmap installiert ist (stellt newuidmap und newgidmap bereit) und der Benutzer in /etc/subuid und /etc/subgid eingetragen ist. Das Setup-Skript prüft diese Voraussetzungen und gibt klare Fehlermeldungen, wenn etwas fehlt. Nach dem Setup läuft der Daemon als systemd-User-Service und startet automatisch beim Login des Benutzers – oder über loginctl enable-linger auch ohne aktive Session.

# Install prerequisites (Debian/Ubuntu)
sudo apt-get install -y uidmap dbus-user-session

# Ensure subuid/subgid entries exist for the current user
grep "$(whoami)" /etc/subuid || echo "$(whoami):100000:65536" | sudo tee -a /etc/subuid
grep "$(whoami)" /etc/subgid || echo "$(whoami):100000:65536" | sudo tee -a /etc/subgid

# Install rootless Docker for current user
dockerd-rootless-setuptool.sh install

# Set environment variables for the current session
export DOCKER_HOST=unix://${XDG_RUNTIME_DIR}/docker.sock
# Add to ~/.bashrc or ~/.profile for persistence:
echo 'export DOCKER_HOST=unix://${XDG_RUNTIME_DIR}/docker.sock' >> ~/.bashrc

# Enable Docker daemon to start without active login session
loginctl enable-linger $(whoami)

# Verify rootless daemon is running
systemctl --user status docker
docker info | grep -i rootless
# Output: rootlessKit.networkDriver: slirp4netns (or pasta on newer kernels)

Nach der Installation verhält sich Rootless Docker für die meisten Anwendungsfälle identisch zu rootful Docker. Die Docker-CLI-Befehle, Compose-Dateien und Dockerfiles müssen nicht angepasst werden. Die Umgebungsvariable DOCKER_HOST zeigt auf den benutzerspezifischen Socket statt auf den System-Socket. In CI-Umgebungen mit mehreren Agenten kann jeder Agent seinen eigenen Rootless Docker-Daemon betreiben, ohne Root-Rechte zu benötigen.

5. Ports unter 1024 und rootless Netzwerk

Das Port-Problem ist der häufigste Stolperstein beim Wechsel auf Rootless Docker. Linux erlaubt nicht-root-Prozessen standardmäßig keine Bindung an Ports unter 1024. Die empfohlene Lösung für Produktionsumgebungen ist nicht, ip_unprivileged_port_start=0 zu setzen und damit alle Ports für alle Benutzer zu öffnen, sondern über einen Reverse Proxy zu lösen: Rootless Docker hört auf Port 8080, ein systemweiter Nginx oder HAProxy leitet Port 80/443 weiter.

Alternativ kann für den spezifischen Benutzer-Namespace der Kernel-Parameter per sysctl angepasst werden, oder CAP_NET_BIND_SERVICE über Ambient Capabilities gesetzt werden. Das ist präziser als eine globale Kernel-Einstellung. Für Entwicklungsumgebungen, wo Port-80-Bindung weniger kritisch ist, ist die pragmatische Lösung einfach: höhere Ports verwenden und einen Browser-Bookmark anlegen.

Das Netzwerk-Backend slirp4netns emuliert einen virtuellen Netzwerk-Stack im User-Space. Das funktioniert zuverlässig, hat aber gegenüber dem nativen Netzwerk-Stack Overhead. Mit Linux Kernel 5.19+ steht pasta als modernere und schnellere Alternative bereit. Rootless Docker konfiguriert das Netzwerk-Backend automatisch, aber für performancekritische Anwendungen lohnt es sich, das Backend explizit auf pasta zu setzen und zu benchmarken.

6. Volume-Rechte in Rootless-Umgebungen

Volumes in Rootless Docker haben ein subtiles Rechteproblem: Root im Container entspricht dem UID-Offset auf dem Host. Wenn der Benutzer mirko (UID 1000) Rootless Docker betreibt und ein Container als Root läuft, schreibt der Container-Root-Prozess Dateien als UID 100000 auf dem Host. Das bedeutet, dass mirko diese Dateien auf dem Host nicht lesen oder schreiben kann – und umgekehrt kann der Container Dateien nicht lesen, die mirko auf dem Host geschrieben hat.

Die Lösung liegt im Verständnis des UID-Mappings. Der Container-Nutzer muss mit derselben UID konfiguriert werden, die dem Host-UID des tatsächlichen Benutzers entspricht. Wenn der Container-Prozess als UID 1000 läuft (nicht als Root), mappt das zu UID 100999 auf dem Host – immer noch kein Schreibzugriff auf Dateien von mirko. Die korrekte Konfiguration: Container-Prozess läuft als UID 0 (Root im Container, der auf UID 100000 gemappt wird) und Dateien auf dem Host sind mit UID 100000 besessen, oder alternativ der Container-Prozess läuft mit einer UID, die explizit auf die Host-UID des Benutzers gemappt ist.

# Understanding UID mapping in rootless Docker
# Host user: mirko (UID 1000), subuid range: 100000-165535
# Container root (UID 0) maps to host UID 100000
# Container UID 1000 maps to host UID 101000

# Check UID mapping of a running rootless container
cat /proc/$(docker inspect --format '{ {.State.Pid} }' mycontainer)/uid_map
# Output: 0 100000 65536 (container_uid host_uid count)

# Fix volume permissions for rootless: pre-create with correct host UID
mkdir -p /home/mirko/app-data
# Find what host UID maps to container UID 33 (www-data in php container)
# container UID 33 -> host UID 100000 + 33 = 100033
sudo chown -R 100033:100033 /home/mirko/app-data

# Alternative: use :z volume option to relabel for SELinux contexts
docker run -v /home/mirko/app-data:/var/www/html:z php:8.4-fpm

# Or run the container with --userns=keep-id (user maps to same UID in container)
# Only works if image supports non-root user
docker run --userns=keep-id -v /home/mirko/app-data:/data alpine

7. Rootless Docker in CI und Entwicklungsumgebungen

Rootless Docker ist in CI-Umgebungen besonders attraktiv, weil CI-Runner häufig auf gemeinsamen Hosts laufen, wo Root-Zugriff ein erhebliches Sicherheitsrisiko darstellt. GitHub Actions, GitLab CI und Jenkins-Agenten können Rootless Docker betreiben, ohne privilegierte Systemrechte zu benötigen. Das ermöglicht sicherere CI-Infrastrukturen, bei denen ein kompromittierter CI-Job keinen Root-Zugriff auf den Host erlangt.

In Entwicklungsumgebungen ist Rootless Docker eine hervorragende Wahl für Entwickler, die auf geteilten Linux-Workstations oder Remote-Entwicklungsservern arbeiten. Jeder Entwickler betreibt seinen eigenen Daemon-Kontext, kann Container starten und stoppen, ohne andere zu beeinflussen, und hat vollständige Kontrolle über seine Docker-Umgebung ohne Root-Rechte anzufragen. Das ist besonders wertvoll in Unternehmensumgebungen mit strikten Sicherheitsrichtlinien, wo Root-Zugriff auf Entwicklungsserver nicht gewährt wird.

Für lokale Entwicklungsumgebungen wie die Mark-Shust-Docker-Magento-Umgebung ist ein Wechsel auf Rootless Docker hingegen mit Vorsicht zu betrachten. Solche Setups haben oft spezifische Anforderungen an Netzwerk-Features, Port-Bindung und Volume-Rechte, die unter Rootless additional Konfiguration erfordern. Das Testen einer bestehenden Entwicklungsumgebung mit Rootless Docker sollte in einer nicht-produktiven Kopie erfolgen, bevor die Hauptumgebung umgestellt wird.

8. Rootless vs. Rootful Docker im direkten Vergleich

Die Entscheidung für oder gegen Rootless Docker ist keine pauschale, sondern hängt vom konkreten Einsatzszenario ab. Die folgende Tabelle fasst die relevantesten Unterschiede zusammen.

Das Fazit aus dem Vergleich: Rootless Docker lohnt sich klar für CI-Infrastrukturen mit geteilten Hosts, für Entwicklungsserver mit mehreren Benutzern und für Umgebungen, in denen das Prinzip minimaler Rechte konsequent umgesetzt werden soll. Für einzelne Produktionsserver, die ohnehin dediziert einem Dienst gehören, ist der Sicherheitsgewinn geringer und der Mehraufwand für Port- und Volume-Konfiguration spürbar.

9. Alternative: Rootless Podman als Docker-Ersatz

Während Rootless Docker einen Daemon benötigt, ist Podman von Haus aus daemonlos und rootless-first. Podman wurde von Red Hat mit dem expliziten Ziel entwickelt, Container ohne Root-Rechte und ohne Daemon zu starten. Jeder podman run-Aufruf startet den Container direkt als Kindprozess des aufrufenden Benutzers, ohne einen zentralen Daemon-Prozess. Das eliminiert einen weiteren Angriffspunkt.

Podman bietet eine weitgehend kompatible CLI zu Docker und kann über podman-docker als Drop-in-Ersatz konfiguriert werden. Compose-Dateien laufen mit podman compose oder dem separaten podman-compose-Tool. Für Teams, die von Docker-Tooling abhängig sind, ist der Wechsel aufwändiger, als es die CLI-Kompatibilität suggeriert: Einige Docker-spezifische Features wie BuildKit haben bei Podman andere Konfigurationswege, und die Netzwerk-Standardkonfiguration unterscheidet sich.

Für neue Umgebungen, die explizit für Security-First ausgelegt werden, ist Podman die stärkere rootlose Option. Für bestehende Umgebungen, die auf Docker-Tooling und Docker-Compose-Dateien aufgebaut sind, ist Rootless Docker der reibungslosere Weg zur verbesserten Sicherheit. Beide Optionen sind produktionsreif – die Wahl hängt vom vorhandenen Tooling-Ökosystem ab.

10. Zusammenfassung

Rootless Docker ist kein Allheilmittel, aber ein wichtiger Sicherheitsschritt für bestimmte Einsatzszenarien. Der Hauptvorteil liegt in der Isolation durch User Namespaces: Root im Container ist kein Root auf dem Host, und ein kompromittierter Docker-Socket gibt einem Angreifer nur Zugriff auf den Benutzerkontext, nicht auf Host-Root. Für CI-Infrastrukturen mit geteilten Hosts und für Multi-Tenant-Entwicklungsserver ist Rootless Docker die richtige Wahl.

Die Einschränkungen – privilegierte Ports, Netzwerk-Performance, Cgroup v2 Anforderung und das Volume-Rechte-Problem – sind real, aber lösbar. Der Schlüssel ist, Rootless Docker bewusst einzusetzen: für Szenarien, in denen die Sicherheitsvorteile die Konfigurationskosten überwiegen. Für einzelne dedizierte Produktionsserver mit strikten Sicherheitskontrollen auf anderer Ebene ist der Gewinn geringer. Die Entscheidung sollte auf einer ehrlichen Risikoanalyse basieren, nicht auf dem Trend.

Als konkreter nächster Schritt empfiehlt sich: das Setup auf einem nicht-produktiven Host ausprobieren, typische Anwendungsfälle testen und die Einschränkungen für die spezifische Umgebung bewerten. Rootless Docker und rootful Docker können auf demselben System koexistieren – der Wechsel muss nicht alles-oder-nichts sein. Eine schrittweise Migration, bei der neue Services in Rootless Docker betrieben werden, gibt dem Team Zeit, die Konfigurationsunterschiede kennen zu lernen, ohne den laufenden Betrieb zu riskieren.

11. FAQ: Rootless Docker