Docker ohne Root: der Sicherheitsgewinn und seine Betriebsfallen

Standardmäßig läuft der Docker-Daemon als Root. Ein Ausbruch aus einem Container oder eine Lücke im Daemon bedeutet dann schnell Root auf dem ganzen Host. Rootless Docker dreht das um: Der Daemon läuft als normaler Benutzer. Das schließt eine ganze Risikoklasse, und ich betreibe meine Dienste bewusst so. Man muss aber ein paar Eigenheiten kennen, sonst verliert man Stunden mit „warum geht das nicht“.

Was rootless bedeutet

Der Docker-Daemon läuft unter einem gewöhnlichen Benutzerkonto, verwaltet über den Benutzer-Dienst (systemctl --user), die Daten liegen im Home des Nutzers. Wie man diesen Modus einrichtet, beschreibt der Rootless-Modus in der Docker-Dokumentation. Ein Detail ist wichtig, damit die Container auch ohne aktive Anmeldung weiterlaufen. Ohne linger beendet systemd den Benutzer-Dienst nämlich, sobald sich der Nutzer abmeldet:

# Container laufen weiter, auch wenn niemand eingeloggt ist:
loginctl enable-linger <benutzer>
systemctl --user enable --now docker

Der Gewinn ist konkret: Ein kompromittierter Container sitzt in einem unprivilegierten Kontext. Er bekommt eben nicht automatisch Root auf dem Host, wie es bei klassischem Docker droht.

Falle 1: der Socket ist woanders

Die häufigste erste Hürde. Werkzeuge und Skripte suchen den Docker-Socket am Standardort, aber im rootless-Betrieb liegt er im Laufzeitverzeichnis des Nutzers. Ohne die passende Variable meldet jedes docker-Kommando, es finde keinen Daemon, obwohl alles läuft:

export DOCKER_HOST=unix:///run/user/1000/docker.sock

Diese Zeile gehört ins Profil, sonst tappt man bei jedem neuen Skript wieder hinein.

Falle 2: privilegierte Ports

Ein rootless-Daemon darf Ports unter 1024 nicht ohne Weiteres belegen. Wer einen Dienst direkt auf 80 oder 443 legen will, braucht eine gezielte Capability-Freigabe. Sauberer ist meist, die Dienste bewusst auf hohe Ports zu legen und den Reverse Proxy davor die öffentlichen Ports übernehmen zu lassen. Man plant die Portvergabe also von vornherein anders.

Falle 3: die echte Quell-IP verschwindet

Beim rootless-Port-Publishing kommt beim Container nicht die echte Absender-IP an, sondern eine interne Adresse. Das ist harmlos, bis man sich darauf verlässt: Eine IP-basierte Abwehr direkt am Dienst, etwa fail2ban oder ein IP-Filter, läuft ins Leere, weil alle Verbindungen gleich aussehen. Der Schutz muss dann über Verschlüsselung, Authentifizierung und Zugriffsregeln tragen. Denselben Effekt beschreibe ich in den Beiträgen zu CrowdSec und zum Standort-Tracking.

Falle 4: frische Netze ohne Ausgang

Ein neu angelegtes Docker-Netz hatte in meinem Setup zunächst keinen Weg nach draußen. Die Container darin erreichten das Internet erst, als sie am bereits funktionierenden Netz hingen. Wer ein Problem mit fehlendem Outbound oder scheiternder Namensauflösung hat, sollte zuerst prüfen, ob das Netz überhaupt einen Ausgang hat, statt lange in der Anwendung zu suchen. Wie Docker Netze und Treiber verwaltet, erklärt die Netzwerk-Dokumentation von Docker.

Ehrlich: der Gewinn kostet etwas Reibung

Rootless Docker ist die richtige Härtung für einen selbst betriebenen Server, aber sie ist nicht gratis. Sie verlangt, dass man den Socket-Pfad, die Portvergabe und die Netz-Eigenheiten kennt. Wer sie nicht kennt, verliert Zeit an Probleme, die es unter klassischem Docker nie gab. Der Tausch lohnt sich trotzdem: ein bisschen Reibung im Betrieb gegen den Wegfall eines Root-Daemons, der auf jedem Server das lohnendste Ziel ist.

Sie betreiben eigene Dienste und wollen sie so absichern, dass eine einzelne Lücke nicht den ganzen Server kostet? Ich baue Container-Betrieb, der von Grund auf gehärtet ist, mit den Eigenheiten, die dazugehören. Mehr unter IT-Sicherheit & ISMS, das Erstgespräch ist unverbindlich.