Podman hat mit Version 6.0 ein Update veröffentlicht, das die Architektur der beliebten Docker-Alternative an mehreren Stellen grundlegend erneuert. Für IT-Leiter im deutschen Mittelstand lohnt sich ein genauer Blick: Die rootless und daemonless Bauweise von Podman gilt seit Jahren als Sicherheitsvorteil gegenüber klassischen Docker-Umgebungen, und Version 6.0 vertieft diesen Ansatz mit einem modernisierten Netzwerk-Stack und überarbeiteten Verwaltungswerkzeugen.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Das Wichtigste in Kürze
- Podman 6.0 wechselt von slirp4netns und iptables zu Netavark, Pasta und nftables
- Quadlets erhalten REST-API-Unterstützung für deklarative, systemd-integrierte Verwaltung
- Die Docker-API-Kompatibilität hat sich verbessert, Migrationen sollen einfacher werden
- Für BSI- und NIS2-relevante Umgebungen bleibt die rootless Architektur der zentrale Sicherheitsvorteil
Warum gilt Podman als sicherer als Docker?
Der Kernunterschied zwischen beiden Systemen liegt tief in der Architektur. Docker setzt auf einen Daemon namens dockerd, der dauerhaft als root-Prozess läuft und sämtliche Container verwaltet. Wird eine Anwendung innerhalb eines Containers kompromittiert, steigt damit das Risiko einer Privilege-Escalation auf den gesamten Host. Podman verzichtet komplett auf diesen Daemon und startet Container stattdessen als eigenständige Kindprozesse direkt unter der Rechteebene des aufrufenden Nutzers. Ein kompromittierter Container erlangt im schlimmsten Fall nur die Rechte des jeweiligen Linux-Nutzerkontos, nicht automatisch Root-Zugriff auf den Host.
Warum die daemonless Architektur für IT-Leiter im deutschen Mittelstand jetzt strategisch relevant wird.
- – dockerd läuft dauerhaft als root-Prozess
- – Kompromittierter Container kann Host-Root gefährden
- – Exponierte Docker-Sockets sind häufige Fehlkonfiguration
- + Kein Daemon, Container laufen als Kindprozesse
- + Rechte bleiben auf Ebene des Nutzerkontos begrenzt
- + Geringere Angriffsfläche für laterale Bewegungen
„Der Verzicht auf einen privilegierten Daemon ist kein Nice-to-have mehr, sondern wird für Unternehmen mit NIS2-Pflichten zu einem dokumentierbaren Baustein der Risikobewertung.“
Die Netzwerk-Modernisierung ist die tiefgreifendste Neuerung dieser Version. Podman wechselt von slirp4netns und iptables zu Netavark, Pasta und nftables und reduziert damit Angriffsflächen im Netzwerk-Namespace, während gleichzeitig die Wartbarkeit für sicherheitskritische Deployments steigt. Ergänzt wird das durch experimentelle Pesto-Unterstützung für rootless Port-Forwarding, die auch die korrekte Quell-IP für Container in eigenen Netzwerken erhält.
Auch die Quadlets haben ein Upgrade erhalten. Die systemd-Einheiten zur deklarativen Container-Verwaltung unterstützen jetzt eine REST-API, verbessertes Datei-Tracking und zusätzliche Suchpfade für Distributionspakete. Wer bereits mit Quadlets arbeitet, um Container ohne Docker-typischen Daemon-Zugriff zu betreiben, profitiert direkt von der saubereren Verwaltung.
Wie ordnet sich das in die Container-Landschaft ein?
Rootless und daemonless Architekturen sind kein Nischentrend, sondern eine direkte Antwort auf jahrelange Sicherheitsvorfälle rund um exponierte Docker-Daemons. Ungeschützte Docker-Sockets im Internet zählen seit Jahren zu den häufigsten Fehlkonfigurationen in Cloud-Umgebungen, weil ein Zugriff auf den Socket faktisch Root-Zugriff auf den gesamten Host bedeutet. Podman, ursprünglich von Red Hat für RHEL entwickelt, hat sich zum bekanntesten Gegenentwurf etabliert und findet zunehmend Einsatz in Kubernetes-nahen Umgebungen, bei OpenShift-Kunden und bei Behörden mit hohen Sicherheitsanforderungen. Docker reagiert im Gegenzug mit verbesserter API-Kompatibilität, um Bestandsnutzer zu halten. Dieses Muster spiegelt sich auch in Podman 6.0: Die überarbeitete Docker-Kompatibilität soll den Umstieg erleichtern, ohne bestehende Skripte umschreiben zu müssen.
Der Verzicht auf einen privilegierten Daemon wird für Unternehmen mit NIS2-Pflichten zu einem Baustein in der Risikobewertung.
— Michael Dobler, Herausgeber Dr. Web
Was bedeutet das für deutsche Unternehmen?
Für Unternehmen mit Pflichten unter BSI-Grundschutz, ISO 27001 oder branchenspezifischen KRITIS-Vorgaben ist die Audit-Tauglichkeit ein handfester Vorteil. Ein Setup ohne privilegierten Daemon erfüllt das Prinzip der geringsten Rechte direkter und reduziert Angriffsflächen für laterale Bewegungen im Netzwerk. Unter NIS2 mit seiner verschärften Nachweispflicht für technische und organisatorische Maßnahmen wird eine solche Architekturentscheidung zunehmend Teil der Dokumentation gegenüber Prüfstellen.
Konkret empfiehlt sich für IT-Leiter, bestehende Docker-Compose-Setups zunächst mit podman-compose oder generierten Quadlet-Units in einer Testumgebung parallel zu betreiben, bevor eine produktive Migration erfolgt. Die verbesserte Docker-API-Kompatibilität von Version 6.0 lässt sich nutzen, um CI/CD-Pipelines ohne Codeänderungen umzustellen.
Der Wechsel von iptables zu nftables und Netavark sollte in bestehenden Netzwerk-Policies vorab im Staging getestet werden, da ältere Netzwerk-Monitoring-Tools hier Kompatibilitätsprobleme zeigen können. Unternehmen, die Container-Workloads zusammen mit Webprojekten betreiben, sollten die Infrastrukturfrage ohnehin ganzheitlich denken.
Ein Blick auf unseren WordPress Hosting Vergleich zeigt, welche Hosting- und Infrastrukturentscheidungen sich mit rootless Container-Strategien sinnvoll kombinieren lassen. Wer die Migration jetzt plant, sollte klein anfangen: ein unkritischer Service als Pilot, saubere Dokumentation der Rechtevergabe und ein realistischer Zeitplan schlagen einen überstürzten Komplett-Umstieg zuverlässig.
