Podman: Rootless Container als Docker-Alternative

1. Warum Podman ohne Daemon auskommt

Der Docker Daemon dockerd läuft dauerhaft als root Prozess und verwaltet sämtliche Container zentral über einen Unix Socket. Jeder Client, der diesen Socket ansprechen kann, erhält faktisch root Rechte auf dem Host, denn der Daemon selbst führt die angeforderten Aktionen mit vollen Privilegien aus. Diese Architektur ist historisch gewachsen und praktisch, stellt aber gerade auf Shared Hosts oder Build Servern ein erhebliches Risiko dar, weil ein kompromittierter Container Prozess über den Socket potenziell den gesamten Host übernehmen kann.

Podman verzichtet komplett auf diesen zentralen Daemon. Jeder podman run Aufruf startet einen eigenständigen Prozess, der Container direkt über die Kernel Schnittstellen erzeugt, üblicherweise mit conmon als schlankem Monitor Prozess pro Container und runc oder crun als OCI konformer Runtime darunter. Fällt ein Container Prozess weg, betrifft das ausschließlich diesen einen Container, es existiert kein zentraler Single Point of Failure, dessen Absturz sämtliche laufenden Container mit reißt.

# Podman Prozessbaum pro Container statt eines zentralen Daemons
ps -ef | grep -E "conmon|crun"

# Kein Socket, keine zentrale Autoritaet: jeder Aufruf ist eigenständig
podman run -d --name shop-cache redis:7-alpine
podman ps

2. Wie der Rootless-Modus technisch funktioniert

Im Rootless-Modus läuft der gesamte Container Prozessbaum unter der UID eines normalen, unprivilegierten Benutzers. Möglich wird das durch User Namespaces: Innerhalb des Containers erscheint der Prozess als root mit UID 0, auf dem Host ist dieselbe UID jedoch auf eine unprivilegierte, per /etc/subuid und /etc/subgid zugewiesene Range gemappt. Root im Container ist damit ein rein logisches Konstrukt ohne reale Host Privilegien.

Netzwerk, Storage und Cgroup Verwaltung funktionieren im Rootless-Modus über Userspace Tools statt Kernel Privilegien: slirp4netns oder das performantere pasta übernehmen das Networking ohne root Rechte, der Storage Treiber fuse-overlayfs ersetzt den klassischen, root benötigenden Overlay Treiber. Der Preis dafür ist ein gewisser Performance Overhead gegenüber echten Kernel Mounts, der für die meisten Web Workloads jedoch kaum ins Gewicht fällt.

# Subuid und Subgid Range für den aktuellen Benutzer pruefen
grep "$USER" /etc/subuid /etc/subgid

# Container als unprivilegierter Benutzer starten, root im Container
# bleibt außerhalb ein Prozess mit gemappter, unprivilegierter UID
podman run --rm -it alpine id

3. Konkrete Sicherheitsvorteile gegenüber root Containern

Der wichtigste Effekt des Rootless-Modus zeigt sich bei einem Container Escape: Gelingt es einem Angreifer, aus dem Container auszubrechen, landet er auf dem Host nicht als root, sondern als der unprivilegierte Benutzer, unter dem Podman lief. Selbst ein erfolgreicher Ausbruch bringt damit keine Host Root Rechte, sondern lediglich die eingeschränkten Rechte eines normalen Accounts, was den Schaden drastisch begrenzt.

Auf Multi Tenant Hosts, wie sie im Magento Hosting mit mehreren Kunden auf einer Maschine üblich sind, lässt sich dieses Modell direkt für Isolation zwischen Kunden nutzen: Jeder Kunde bekommt einen eigenen Linux Benutzer und betreibt seine Container ausschließlich unter dieser UID. Ein kompromittierter Container eines Kunden kann dann prinzipbedingt weder Dateien anderer Kunden lesen noch deren Container beeinflussen, weil die Betriebssystem eigene Benutzerisolation greift, lange bevor Container spezifische Mechanismen überhaupt ins Spiel kommen.

4. Kompatibilität zur Docker CLI und zu Docker Images

Podman implementiert bewusst dieselbe Kommandozeilen Syntax wie Docker: podman run, podman build, podman ps und die meisten Flags funktionieren identisch, sodass bestehende Skripte oft ohne Änderung laufen. Wer den Umstieg besonders einfach halten möchte, legt einfach einen Alias alias docker=podman an, viele Distributionen bieten dafür sogar ein eigenes podman-docker Paket, das den Befehl docker systemweit auf Podman umleitet.

Auch bei Images gibt es keine Reibung: Podman lädt Standard Docker Images aus der Docker Registry oder aus privaten Registries ohne Konvertierung, weil beide auf dem gemeinsamen OCI Image Format basieren. Ein Dockerfile lässt sich unverändert mit podman build bauen, und das resultierende Image lässt sich anschließend genauso in eine Registry pushen und mit Docker weiterverwenden. Ein Unterschied bleibt bei Docker Compose: Podman bringt mit podman-compose beziehungsweise nativer podman compose Unterstützung eine eigene Implementierung mit, die nicht in jedem Detail hundertprozentig deckungsgleich zum Original ist.

# Bestehendes Dockerfile unveraendert mit Podman bauen
podman build -t shop-app:latest .

# Docker Compose Datei mit Podman ausführen
podman compose -f docker-compose.yml up -d

5. systemd-Integration mit podman generate systemd

Anders als Docker, das Container über den eigenen Daemon dauerhaft am Leben hält, überlässt Podman das Lebenszyklus Management bewusst systemd, dem auf den meisten Linux Distributionen ohnehin bereits laufenden Init System. Der Befehl podman generate systemd erzeugt aus einem laufenden Container eine passende systemd Unit Datei inklusive Start, Stop und Restart Logik, sodass Container beim Boot automatisch starten und bei einem Absturz von systemd selbst neu gestartet werden, ganz ohne zusätzlichen Wrapper Dienst.

Diese generierten Units lassen sich sowohl systemweit als root Service als auch, was für den Rootless-Modus besonders relevant ist, als User Unit unter systemctl --user registrieren. Damit läuft der komplette Lebenszyklus eines Containers innerhalb der Session eines unprivilegierten Benutzers, inklusive Logging über journalctl und Ressourcenlimits über die vom User Manager verwalteten Cgroups.

# Laufenden Container in eine systemd Unit Datei ueberfuehren
podman generate systemd --new --files --name shop-cache

# Unit Datei für den aktuellen Benutzer registrieren und aktivieren
mkdir -p ~/.config/systemd/user
mv container-shop-cache.service ~/.config/systemd/user/
systemctl --user daemon-reload
systemctl --user enable --now container-shop-cache.service

6. Quadlet: Container deklarativ als systemd Unit beschreiben

Seit Podman 4.4 löst Quadlet die generierten Units zunehmend ab: Statt einen Container manuell zu starten und daraus eine Unit zu generieren, beschreibt eine .container Datei den gewünschten Zustand deklarativ, ähnlich einem Kubernetes Manifest, und systemd erzeugt daraus zur Laufzeit selbst die passende Service Unit. Änderungen an der Konfiguration erfolgen dadurch direkt in einer versionierbaren Textdatei, nicht mehr über einen imperativen generate Schritt nach jedem Neustart.

Quadlet Dateien landen unter ~/.config/containers/systemd/ für Rootless-Setups beziehungsweise /etc/containers/systemd/ für root Betrieb und werden von podman-system-generator beim systemd Start automatisch in reguläre Units übersetzt. Für produktive Setups ist das der empfohlene Weg, weil die gesamte Konfiguration in Git versioniert und über Konfigurationsmanagement ausgerollt werden kann, statt sich auf manuell generierte, leicht veraltende Unit Dateien zu verlassen.

# ~/.config/containers/systemd/shop-cache.container
[Unit]
Description=Redis Cache für den Magento Shop
After=network-online.target

[Container]
Image=docker.io/library/redis:7-alpine
PublishPort=127.0.0.1:6379:6379
Volume=shop-cache-data.volume:/data

[Service]
Restart=always

[Install]
WantedBy=default.target

7. Praxisbeispiel: Magento-Container rootless betreiben

Ein realistisches Setup teilt einen Magento Stack auf mehrere rootless Podman Container unter einer dedizierten Systembenutzer UID auf: PHP FPM, Nginx als Reverse Proxy und Redis für Session und Cache. Weil Ports unterhalb von 1024 im Rootless-Modus standardmäßig nicht gebunden werden können, läuft Nginx intern auf einem hohen Port, während ein root laufender, systemweiter Reverse Proxy wie ein weiteres Nginx oder Traefik den eigentlichen Port 443 nach außen terminiert und intern an den unprivilegierten Container weiterreicht.

Für den Dateizugriff zwischen Host und Container ist die UID Zuordnung entscheidend: Da root im Container auf eine gemappte, unprivilegierte Host UID abgebildet wird, müssen Volume Mounts mit podman unshare chown auf die korrekte gemappte UID gebracht werden, damit PHP FPM innerhalb des Containers tatsächlich Schreibrechte auf var und pub/media besitzt, ohne dass der Host Benutzer außerhalb des User Namespace root Rechte benötigt.

# Magento Verzeichnis für den Rootless Container Namespace vorbereiten
podman unshare chown -R 82:82 var pub/media

# PHP FPM Container rootless mit gemounteten Magento Dateien starten
podman run -d --name shop-php \
  --userns=keep-id \
  -v "$(pwd):/var/www/html:Z" \
  --network shop-net \
  magento-php-fpm:8.4

8. Pods als Bündel mehrerer Container

Podman kennt zusätzlich zum einzelnen Container das Konzept des Pods, angelehnt an die gleichnamige Kubernetes Einheit: Mehrere Container in einem Pod teilen sich einen Network Namespace und damit Localhost, sodass PHP FPM und Nginx innerhalb desselben Pods über 127.0.0.1 miteinander sprechen können, ohne ein separates Container Netzwerk mit DNS Auflösung zu benötigen. Nach außen exponiert nur der Pod selbst Ports, einzelne Container darin bleiben unsichtbar.

Dieses Modell erleichtert die spätere Migration nach Kubernetes erheblich, weil ein Podman Pod strukturell einem Kubernetes Pod entspricht und sich mit podman generate kube sogar direkt in ein Kubernetes Manifest exportieren lässt. Für kleinere Hosting Setups ohne vollwertige Orchestrierung bleibt ein einzelner rootless Pod pro Kunde oder Projekt trotzdem eine pragmatische, gut isolierte Lösung.

# Pod mit gemeinsamem Netzwerk für Magento Stack anlegen
podman pod create --name shop-pod -p 127.0.0.1:8080:8080

podman run -d --pod shop-pod --name shop-php magento-php-fpm:8.4
podman run -d --pod shop-pod --name shop-nginx nginx:1.27-alpine

9. Grenzen des Rootless-Modus und wann root Container sinnvoll bleiben

Der Rootless-Modus hat auch Grenzen: Manche Netzwerkfeatures wie das Binden niedriger Ports direkt im Container, bestimmte VLAN Konfigurationen oder macvlan Netzwerke mit eigener MAC Adresse benötigen echte Kernel Privilegien und funktionieren im Rootless-Modus nicht oder nur eingeschränkt über Workarounds. Auch der Performance Overhead von fuse-overlayfs gegenüber nativen Kernel Mounts fällt bei sehr IO intensiven Workloads messbar aus, etwa bei Datenbank Containern mit hohem Schreibdurchsatz.

Für solche Fälle bleibt der root Betrieb von Podman eine valide Option, die weiterhin deutlich sicherer ist als Docker, weil auch im root Modus kein dauerhafter, privilegierter Daemon existiert, sondern jeder Container Prozessbaum unabhängig verwaltet wird. Die pragmatische Empfehlung für Hosting Umgebungen lautet, Rootless-Container als Standard zu etablieren und root Betrieb gezielt nur dort einzusetzen, wo konkrete technische Anforderungen es erzwingen, statt aus reiner Gewohnheit alles privilegiert laufen zu lassen.

10. Zusammenfassung

11. FAQ: Podman Rootless