Docker und Podman 5.x: Rootless Container für Self-Hosting – so funktioniert es wirklich

Rootless Container sind kein Nischenthema mehr. Mit der Podman-5.x-Linie und den aktuellen Docker-Updates ist die Frage, ob man Container ohne Root-Rechte im Self-Hosting sinnvoll betreiben kann, längst beantwortet – die Frage ist nur noch, welche Runtime die besseren Kompromisse liefert.

Warum Root-Rechte im Container-Betrieb ein Problem sind

Wer einen Self-Hosting-Server betreibt und Docker-Container über den klassischen dockerd-Daemon startet, tut das de facto mit einem permanent als Root laufenden Hintergrunddienst. Das ist historisch gewachsen und für viele Setups lange akzeptabel gewesen. Aber die Konsequenz ist klar: Gelingt einem Angreifer ein Container-Breakout oder eine Privilege-Escalation über den Docker-Socket, landet er mit Root-Rechten auf dem Host-System. Kein theoretisches Szenario. Docker-Socket-Zugriff ist in der Praxis einer der direktesten Wege zur vollständigen Host-Übernahme.

Das Least-Privilege-Prinzip – ein Grundsatz, der in jedem ernsthaften Sicherheitskonzept steht – verlangt, dass Prozesse nur die Rechte bekommen, die sie tatsächlich brauchen. Container, die Webdienste, Datenbanken oder Mediaplayer ausführen, brauchen in den meisten Fällen keine Root-Rechte auf dem Host. Sie brauchen Netzwerkzugriff, Dateisystemmapping und CPU-Zeit. Das ist alles.

Rootless Container sind die Antwort auf dieses strukturelle Problem. Und Podman hat diesen Ansatz von Anfang an architektonisch konsequent umgesetzt, während Docker Rootless-Unterstützung nachgerüstet hat.

Podman-5.x und die daemonless Architektur

Der zentrale Unterschied zwischen Podman und Docker ist nicht die CLI-Syntax – die ist weitgehend kompatibel. Es ist die Architektur. Podman läuft ohne zentralen Daemon. Kein permanent aktiver podman.service mit Root-Rechten, der auf einen Socket wartet. Jeder Container-Start ist ein eigener Prozess, gestartet unter dem jeweiligen Benutzeraccount.

Die Podman-5.x-Linie, die im Laufe von 2024 erschienen ist, hat diese daemonless-Architektur weiter stabilisiert und die Kompatibilität mit OCI-Images verbessert. Podman 5 bringt unter anderem überarbeitetes Networking über Netavark als Standard-Backend, verbesserte Unterstützung für Podman Quadlets – das sind systemd-Unit-Dateien für Container – sowie Verbesserungen im Bereich der Rootless-Netzwerkkonfiguration über slirp4netns und pasta.

Für Self-Hosting-Setups ist die systemd-Integration besonders relevant. Wer Container als systemd-User-Services betreibt, kann mit Podman Quadlets Containerisierung und Init-System direkt verbinden: Container werden beim Login gestartet, überwacht und neu gestartet, ohne dass Root-Dienste eingebunden sein müssen. Das ist architektonisch sauberer als Docker-Compose-Dateien, die von Hand oder über Cron verwaltet werden.

Docker Rootless: nachgerüstet, aber funktional

Docker hat Rootless-Unterstützung nicht ignoriert. Der dockerd-rootless-setuptool.sh-Ansatz ermöglicht es, Docker Engine ohne Root zu installieren und zu betreiben. Technisch funktioniert das: Der Docker-Daemon läuft dann im User-Namespace, Container starten unter dem jeweiligen Benutzer. Für viele Anwendungsfälle reicht das.

Der Unterschied ist konzeptioneller Natur. Bei Docker ist Rootless eine Option, die aktiviert werden muss und architektonisch auf ein Daemon-Modell aufgesetzt ist, das für Root-Betrieb entworfen wurde. Bei Podman ist Rootless der Default-Betriebsmodus, für den die gesamte Architektur ausgelegt ist. Das zeigt sich in Details: Networking, Cgroup-Handling, User-Namespace-Zuordnungen. Podman ist in diesem Bereich schlicht konsistenter.

Wer Docker im Team einsetzt und von bestehenden Docker-Compose-Stacks, wie DDEV es ab Version 1.25.0 für beide Runtimes beschreibt, nicht abweichen will, fährt mit Docker Rootless pragmatisch gut. Aber es ist ein Workaround auf einem Root-First-System, kein neuer Ausgangspunkt.

Rootless Container in der Praxis: Was wirklich funktioniert

Ein Rootless Docker-Container oder Podman-Container läuft in einem User-Namespace. Das bedeutet: UID 0 im Container ist nicht UID 0 auf dem Host, sondern wird auf eine unprivilegierte UID gemapped. Ein Angreifer, der aus dem Container ausbricht, landet nicht als Root auf dem Host. Das ist der eigentliche Sicherheitsgewinn.

In der Praxis gibt es Grenzen, die oft zu optimistisch kommuniziert werden. Rootless bedeutet nicht, dass gar keine Privilegien mehr nötig sind. Netzwerk-Binding auf Ports unter 1024 erfordert unter Linux weiterhin besondere Konfiguration – in der Regel über sysctl net.ipv4.ip_unprivileged_port_start. Overlay-Filesysteme funktionieren in Rootless-Umgebungen nur, wenn der Kernel entsprechende User-Namespace-Unterstützung mitbringt, was auf aktuellen Linux-Distributionen wie Fedora oder Ubuntu 22.04+ standardmäßig der Fall ist, auf älteren oder minimalen Systemen aber nicht.

SELinux und AppArmor können Rootless-Container zusätzlich einschränken – was einerseits gut ist, andererseits Konfigurationsaufwand bedeutet. Wer auf RHEL oder Fedora mit SELinux arbeitet, muss Container-Labels und Policy-Kontexte sauber setzen, sonst scheitert das Volume-Mounting. Das ist kein Fehler von Podman, sondern korrekte MAC-Policy-Durchsetzung. Aber es ist ein häufiger erster Frustrationspunkt.

Meine eigene Einschätzung: Rootless Container auf einem frischen Fedora- oder Debian-System mit aktuellem Kernel funktionieren heute deutlich reibungsloser als noch vor zwei Jahren. Die Infrastruktur im Kernel und in den Tools ist jetzt weit genug, dass es kein Experiment mehr ist.

Docker Compose und Podman: die Reibungsfläche bleibt

Der häufigste Praxishaken bei der Migration von Docker zu Podman ist nicht die Container-Runtime selbst – sondern Docker Compose. Wer bestehende docker-compose.yml-Stacks auf Podman umziehen will, hat mehrere Optionen: podman-compose als Python-basierter Ersatz, den Docker-Kompatibilitäts-Socket von Podman, der Docker-CLI-Zugriffe weiterleitet, oder den nativen Podman-Play-Kube-Ansatz mit Kubernetes-YAML.

Red Hat positioniert Podman klar als Enterprise-taugliche Alternative mit Rootless-Fokus, aber die Compose-Ebene ist auch in offiziellen Dokumentationen als Bereich mit Einschränkungen markiert. podman-compose deckt die häufigen Use Cases ab, ist aber kein vollständiger Feature-Ersatz für Docker Compose in komplexen Stacks. Wer Compose stark nutzt und viele Services mit komplexen Netzwerkdefinitionen, Health-Checks und Dependency-Chains betreibt, sollte das vorher testen.

Eine saubere Alternative für Podman sind die bereits erwähnten Quadlets. Wer bereit ist, von Compose wegzukommen und Container als systemd-User-Units zu verwalten, bekommt eine solidere Integration in das Init-System des Hosts – inklusive Logging über journald, automatischem Neustart und klarer Abhängigkeitssteuerung. Das erfordert Umdenken, ist aber keine Verschlechterung.

Multi-User-Umgebungen und Isolation

Ein Bereich, in dem Podman strukturell stärker ist als klassisches Docker, sind Mehrbenutzer-Systeme. Wenn auf einem Linux-Server mehrere Nutzer Container betreiben – etwa in einem Homelab mit mehreren Diensten unter separaten Accounts oder in einer geteilten Entwicklungsumgebung –, ist die Isolation bei Podman von Haus aus besser.

Jeder Benutzer verwaltet seine Container vollständig isoliert. Es gibt keinen gemeinsamen Docker-Socket, über den ein Nutzer die Container eines anderen Nutzers beeinflussen könnte. Das ist bei Docker nur durch zusätzliche Konfiguration und Zugriffsbeschränkungen auf den Socket erreichbar – und selbst dann bleibt der gemeinsame Daemon eine potenzielle Angriffsfläche.

ATIX beschreibt in einem detaillierten Praxisbeitrag, wie Rootless Podman in Enterprise-Linux-Umgebungen eingesetzt wird – gerade weil die User-Namespace-Isolation und die fehlende Daemon-Abhängigkeit in regulierten Umgebungen ein klares Plus sind. Das gilt genauso für Self-Hosting auf einem Server, den man mit anderen teilt oder auf dem mehrere Dienste unter verschiedenen Service-Accounts laufen sollen.

Wer etwa Nextcloud, Vaultwarden und einen Reverse Proxy unter separaten Systemaccounts betreiben will, bekommt mit Podman eine sauberere Trennung als mit Docker. Jeder Account hat seinen eigenen Container-Namespace, seine eigenen Images und seinen eigenen Netzwerkstack.

Migration von Docker zu Podman: was konkret zu tun ist

Der erste Schritt ist meistens einfacher als erwartet. alias docker=podman ist kein Witz – in vielen Fällen funktioniert genau das für einfache Container-Starts, weil die CLI-Syntax weitgehend identisch ist. Docker-Images aus dem Docker Hub lassen sich direkt pullen, weil Podman OCI-kompatibel ist und mit denselben Registry-Endpunkten arbeitet.

Für Compose-basierte Stacks ist der Prozess aufwendiger. Entweder podman-compose installieren und testen, oder Schritt für Schritt auf Quadlets umstellen. Wer den Quadlet-Weg geht, legt für jeden Service eine .container-Datei im Verzeichnis ~/.config/containers/systemd/ an. Podman generiert daraus automatisch systemd-Unit-Dateien, die über systemctl --user verwaltet werden. Volumes, Netzwerke und Umgebungsvariablen werden direkt in der Quadlet-Datei definiert. Der Vorteil gegenüber Compose: Die Integration ins System ist tiefer, Logs landen in journald, Abhängigkeiten zu anderen Units lassen sich direkt ausdrücken.

Ein wichtiger Punkt bei der Migration ist die Suche nach hartkodierten Annahmen über den Docker-Socket-Pfad /var/run/docker.sock. Viele Tools und Drittanwendungen – darunter Monitoring-Agents, CI-Runner oder Portainer – setzen diesen Pfad voraus. Podman kann einen kompatiblen Socket unter ~/.config/systemd/user/podman.socket bereitstellen, aber die entsprechende Umgebungsvariable DOCKER_HOST muss gesetzt sein. Das ist dokumentiert, aber regelmäßig ein stiller Fehler bei schnellen Migrationen.

Typische Stolpersteine und wie man sie vermeidet

Wer die Migration konkret plant, begegnet neben dem Socket-Problem noch weiteren wiederkehrenden Hürden. Eine davon betrifft den Loginctl-User-Linger-Mechanismus: Systemd-User-Services laufen standardmäßig nur, solange eine aktive Login-Session des jeweiligen Nutzers besteht. Wer Container-Dienste auch nach dem Ausloggen im Hintergrund weiterlaufen lassen will, muss loginctl enable-linger <username> ausführen. Das ist eine einmalige Konfiguration, aber einer der häufigsten Gründe, warum Dienste nach einem Server-Reboot nicht wie erwartet starten.

Ein weiteres praktisches Problem betrifft Image-Speicherorte. Bei Docker landen Images systemweit unter /var/lib/docker und sind für alle Nutzer mit Docker-Zugriff erreichbar. Bei Podman im Rootless-Betrieb liegen Images unter ~/.local/share/containers/storage, also pro Nutzer getrennt. Das ist aus Isolationsgründen korrekt, bedeutet aber, dass dasselbe Image für mehrere Service-Accounts mehrfach gespeichert wird. Auf Systemen mit knappem Speicherplatz kann das relevant werden. Die Lösung ist ein gemeinsames graphRoot in der containers/storage.conf, das als Read-only-Basis für alle Nutzer dient – technisch möglich, aber manuell zu konfigurieren.

Auch bei der Netzwerkdurchsetzung lohnt ein genauer Blick: Das Standard-Backend pasta in Podman 5.x ist für die meisten Rootless-Setups der bessere Ersatz für das ältere slirp4netns, weil es performanter ist und IPv6 nativ unterstützt. Wer jedoch komplexe Netzwerkbrücken oder direkte Verbindungen zwischen Containern verschiedener Nutzer benötigt, stößt auch hier auf Grenzen, die bewusstes Design erfordern. In solchen Setups – etwa wenn mehrere isolierte Dienste über einen gemeinsamen Reverse Proxy kommunizieren sollen – ist ein explizites durchdachtes Sicherheitskonzept für den gesamten Self-Hosting-Stack kein Luxus, sondern Grundvoraussetzung.

Wann bleibt Docker die bessere Wahl

Das wäre eine einseitige Darstellung, wenn ich Docker nur als Legacy-System abtäte. Docker bleibt aus konkreten Gründen die bessere Wahl in bestimmten Szenarien. Erstens: Compose-Stacks mit komplexen Abhängigkeiten, bei denen podman-compose noch Lücken hat. Zweitens: Umgebungen mit starker Drittanbieter-Integration, bei der Docker-Socket-Kompatibilität vorausgesetzt wird und kein Spielraum für Konfigurationsanpassungen besteht. Drittens: Teams mit bestehenden Docker-Kenntnissen und CI/CD-Pipelines, die auf Docker Build und Docker Hub aufgebaut sind – hier überwiegt der Wechselaufwand den Sicherheitsgewinn in vielen Fällen.

Docker ist nicht veraltet. Das Ökosystem um Docker Hub, Docker Compose und Docker Desktop ist nach wie vor das größte im Container-Bereich. Für Entwicklungsumgebungen auf dem eigenen Laptop, wo Rootless nicht die erste Priorität ist, bleibt Docker die reibungslosere Option. Auch Docker Swarm als einfaches Multi-Host-Orchestrierungswerkzeug hat in bestimmten kleineren Self-Hosting-Szenarien seinen Platz – auch wenn der Trend klar Richtung Kubernetes-naher Workflows geht.

Meine Einschätzung ist pragmatisch: Wer neu aufbaut und Self-Hosting auf einem Linux-Server plant, sollte Podman ernsthaft in Betracht ziehen. Wer einen bestehenden Docker-Stack betreibt, der stabil läuft, hat keinen zwingenden Grund für einen sofortigen Wechsel – aber gute Gründe, Rootless-Betrieb zumindest zu evaluieren.

Was bleibt und was als nächstes ansteht

Die technische Ausgangslage ist klar: Rootless Container sind kein Experiment mehr. Podman 5.x liefert eine stabile, systemd-integrierte Runtime ohne Root-Daemon, Docker bietet mit dem Rootless-Modus einen funktionalen Nachrüst-Ansatz. Die eigentliche Entscheidung ist keine technische Entweder-Oder-Frage, sondern eine Frage der Prioritäten: Wie wichtig ist architektonische Sicherheit im Vergleich zu Tooling-Kompatibilität?

Was noch fehlt, ist breitere Tool-Unterstützung. Portainer, Watchtower und viele Monitoring-Integrationen setzen immer noch auf Docker-Socket-Semantik. Das wird sich ändern – aber langsamer als die Runtime-Entwicklung selbst. Wer heute einen neuen Self-Hosting-Stack aufbaut, sollte deshalb nicht nur die Container-Runtime wählen, sondern auch das Management-Tooling auf Podman-Kompatibilität prüfen.

Haben Sie Ihren bestehenden Docker-Stack schon auf Rootless-Betrieb geprüft – und falls nicht, was hält Sie konkret davon ab?