Podman: rootless Container verwalten statt Docker-Daemon

Podman ist eine Container-Engine, die Docker-Befehle versteht, aber ohne ständig laufenden Hintergrunddienst (Daemon) und ohne root-Rechte auskommt. Du installierst sie mit einem Paketbefehl, richtest einmalig die rootless-Umgebung ein und startest deinen ersten Container mit podman run -it --rm alpine sh. Für die meisten Linux-Setups ist das der sicherere Weg, Container zu betreiben.

Container sind abgekapselte Pakete, in denen eine Anwendung samt ihrer Abhängigkeiten läuft – isoliert vom restlichen System. Wer das bisher mit Docker gemacht hat, stolpert früher oder später über die Frage: Geht das auch ohne den Docker-Daemon, der dauerhaft als root im Hintergrund läuft? Genau hier setzt Podman an. Die Podman Containerverwaltung verzichtet auf diesen zentralen Dienst und führt jeden Container als gewöhnlichen Linux-Prozess unter deinem Benutzerkonto aus.

Podman oder Docker – wann lohnt der Umstieg?

Beide Werkzeuge nutzen dasselbe Image-Format (OCI, der offene Standard für Container-Abbilder), und die Befehle sind fast deckungsgleich. Der Unterschied steckt unter der Haube:

• Architektur: Docker arbeitet mit einem zentralen Daemon, der klassisch als root läuft. Podman ist daemonless – jeder Befehl ist ein eigener Prozess, der sich beendet, sobald der Container steht.
• Sicherheit: Podman läuft standardmäßig rootless, also ohne Administrator-Rechte. Bricht ein Angreifer aus einem Container aus, landet er als rechtloser Benutzer auf dem Host, nicht als root. Podman vergibt Containern außerdem nur 11 der Linux-Capabilities statt 14 – das schließt einige Angriffswege von vornherein.
• Aufwand: Bei Docker musst du den rootless-Modus erst über ein Extra-Skript aktivieren. Bei Podman ist er ab Werk dabei.

Für Entwicklungsrechner, Heimserver und alles, wo du keinen privilegierten Hintergrunddienst willst, ist Podman die naheliegende Wahl. Docker bleibt stark, wenn dein Team komplett auf Docker-Tooling (Docker Compose, Docker Desktop, Swarm) eingespielt ist.

Podman installieren

Podman steckt in den Paketquellen aller großen Linux-Distributionen. Die aktuelle stabile Version ist Podman 5.8 (Stand Juni 2026); die 6.0er-Reihe steht als Release Candidate in den Startlöchern. Installiere über die Paketverwaltung deiner Distribution:

• Fedora / RHEL / CentOS Stream: sudo dnf install podman
• Ubuntu / Debian: sudo apt install podman
• Arch Linux: sudo pacman -S podman

Prüfe danach mit podman --version, welche Version installiert ist. Auf Fedora und RHEL ist Podman besonders gut gepflegt, weil das Projekt aus dem Red-Hat-Umfeld stammt – dort bekommst du die neuesten Versionen am schnellsten.

Rootless-Umgebung einrichten

Damit rootless Container starten, braucht dein Benutzer einen eigenen Bereich an Unter-Benutzer-IDs (subordinate UIDs/GIDs). Damit bildet Podman die Benutzer im Container auf einen harmlosen Bereich außerhalb deines echten Kontos ab. Auf Fedora und aktuellen Ubuntu-Versionen ist das oft schon eingerichtet – prüfe es zuerst:

1. Bestehende Zuordnung prüfen: Sieh in den Dateien nach mit cat /etc/subuid und cat /etc/subgid. Steht dort eine Zeile mit deinem Benutzernamen, bist du fertig.
2. Falls leer, Bereich eintragen: Trage als root in beide Dateien je eine Zeile ein, z. B. deinname:100000:65536. Das reserviert deinem Konto 65.536 IDs ab der Nummer 100000. Bequem geht das mit sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 deinname.
3. Änderung aktiv schalten: Melde dich neu an oder führe podman system migrate aus, damit Podman die neue Zuordnung übernimmt.
4. Gegenprüfen: podman info zeigt im Abschnitt idMappings, ob die rootless-Konfiguration erkannt wird.

Ein kleiner Stolperstein aus der Praxis: Wenn der Container-Start mit einer Meldung über fehlende Sub-UIDs abbricht, fehlt fast immer die Zeile in /etc/subgid – die wird gern vergessen, weil viele nur an die UIDs denken.

Den ersten Container starten

1. Testcontainer hochfahren: podman run -it --rm alpine sh lädt das schlanke Alpine-Linux-Image, startet eine Shell im Container und räumt ihn nach dem Verlassen (--rm) wieder weg.
2. Image gezielt laden: podman pull docker.io/library/nginx holt einen Webserver. Mit podman images siehst du alle lokalen Images, mit podman rmi entfernst du eines.
3. Dienst im Hintergrund: podman run -d -p 8080:80 docker.io/library/nginx startet nginx losgelöst (-d) und leitet Port 8080 deines Rechners auf Port 80 im Container.
4. Laufende Container ansehen: podman ps listet aktive Container, podman stop <name> hält sie an.

Praktisch beim Arbeiten mit eigenen Dateien: Das Flag --userns=keep-id behält deine Benutzer-ID im Container bei. Dann gehören Dateien, die der Container im gemounteten Ordner anlegt, hinterher wieder dir und nicht einer kryptischen ID-Nummer.

Mehrere Container als Pod bündeln

Ein Pod ist eine Gruppe von Containern, die sich Netzwerk und Ports teilen – dasselbe Konzept, das auch Kubernetes nutzt. Das macht Podman zur natürlichen Lernumgebung, wenn du später in Richtung Kubernetes willst.

1. Pod anlegen: podman pod create --name webpod -p 8080:80
2. Container in den Pod hängen: podman run -d --pod webpod docker.io/library/nginx
3. Status prüfen: podman pod ps zeigt alle Pods und ihre Container.

Container als systemd-Dienst: Quadlet

Das ist die wichtigste Neuerung der letzten Podman-Generation. Mit Quadlet beschreibst du einen Container in einer einfachen Textdatei, und systemd – der Dienste-Manager von Linux – kümmert sich um Start, Neustart und Autostart beim Hochfahren. Kein selbstgebasteltes Start-Skript mehr nötig.

Lege für deinen Benutzer eine Datei ~/.config/containers/systemd/webserver.container an:

• Im Abschnitt [Container] trägst du Image=docker.io/library/nginx und PublishPort=8080:80 ein.
• Im Abschnitt [Service] sorgt Restart=on-failure für automatischen Neustart bei Absturz.
• Im Abschnitt [Install] macht WantedBy=default.target den Dienst autostart-fähig.

Danach systemctl --user daemon-reload ausführen und mit systemctl --user start webserver starten. Seit der 4.4er-Reihe an Bord, hat sich Quadlet 2026 zum Standardweg entwickelt, Container dauerhaft laufen zu lassen.

Docker-Compose-Dateien weiternutzen

Bestehende docker-compose.yml-Dateien musst du nicht wegwerfen. Es gibt zwei Wege:

• podman-compose: ein eigenständiges Community-Tool (in Python), das die Compose-Syntax versteht. Installation z. B. über pip install podman-compose.
• podman compose: seit Podman 5 als dünner Aufsatz dabei, der eine vorhandene Compose-Engine im Hintergrund anspricht.

Kleinere Anpassungen können nötig sein, vor allem bei Netzwerk- und Volume-Definitionen. Für dauerhafte Dienste auf einem Server ist Quadlet allerdings die robustere Lösung als Compose.

Häufige Fragen

Ist Podman kostenlos?

Ja. Podman ist freie Open-Source-Software unter Apache-2.0-Lizenz und für Privat- wie Firmennutzung kostenlos – ohne die Lizenzbeschränkungen, die für Docker Desktop in größeren Unternehmen gelten.

Kann ich Docker-Befehle mit Podman nutzen?

Weitgehend ja. Podman ahmt die Docker-CLI nach, sodass podman run, podman build oder podman pull fast identisch funktionieren. Viele setzen sogar alias docker=podman. Einzelne Optionen unterscheiden sich, vor allem bei Netzwerk und Volumes.

Was bedeutet rootless bei Podman?

Rootless heißt, dass Container ohne Administrator-Rechte unter deinem normalen Benutzerkonto laufen. Über User-Namespaces wird die Container-root auf eine harmlose ID auf dem Host abgebildet – das senkt das Sicherheitsrisiko deutlich.

Läuft Podman unter Windows oder macOS?

Ja, über Podman Desktop. Container brauchen einen Linux-Kernel, deshalb startet Podman unter Windows und macOS eine kleine Linux-VM im Hintergrund. Die Bedienung bleibt gleich, es entsteht nur ein geringer Mehraufwand.

Was ist ein Quadlet?

Ein Quadlet ist eine einfache Textdatei, mit der du einen Container als systemd-Dienst beschreibst. systemd übernimmt dann Start, Neustart und Autostart – seit 2026 der Standardweg, Container dauerhaft laufen zu lassen.

Hintergrund: Warum geht das ohne root?

Der Trick steckt in den User-Namespaces des Linux-Kernels. Innerhalb des Containers darf ein Prozess scheinbar als root agieren, in Wahrheit ist diese Container-root nur auf eine harmlose, unprivilegierte ID auf dem Host abgebildet – genau auf den Sub-UID-Bereich, den du oben eingetragen hast. Für die Prüfungsvorbereitung lohnt es, sich das zu merken: Namespaces isolieren was ein Prozess sieht (Dateisystem, Netzwerk, Prozessliste), während Capabilities steuern, was er darf. Podman kombiniert beides, um Container ohne zentralen Daemon und ohne root sicher zu betreiben. Das daemonless-Design hat noch einen Nebeneffekt: Es läuft kein Dauerprozess im Hintergrund, der Ressourcen zieht oder selbst zum Angriffsziel wird.