Podman – Docker einmal neu gemacht!

Podman ist ein Tool zum Erstellen und Betreiben von Containern. Durch das Absetzen von kurzen Befehlen sind Anwendungen schnell virtualisiert und in Containern hochgefahren. Ebenso schnell können sie wieder gestoppt und entfernt werden. Aber was ist daran neu? Worin liegen die Unterschiede und evtl. Vorteile zu Docker? – Damit möchten wir uns in diesem Blog-Artikel befassen.  

Während die Virtualisierung und Containerisierung immer mehr im Trend ist, wird auch an den Management-Tools der Container gearbeitet. Docker hat sich schnell die Position als das Steckenpferd zum Management von Containern erarbeitet, wobei Docker neben vielen Vorteilen und vor allem dem schnell wachsenden Repertoire an Images auch Nachteile und mögliche Sicherheitsrisiken aufweist. Dass Container im Gegensatz zu virtuellen Systemen keinen eigenen Kernel benötigen, wird meist als einer der großen Vorteile gesehen, wobei es bei Docker ein großes Sicherheitsrisiko darstellt, denn Docker-Container können nur mit root-Rechten ausgeführt werden. Dadurch können in den Containern ausgeführte Prozesse mit root-Rechten auf den Kernel zugreifen und so das Host-System angreifen (https://opensource.com/business/14/7/docker-security-selinux).

Podman soll hierbei Abhilfe schaffen. Das erst kürzlich veröffentlichte Container-Management-Tool verspricht, die Funktionen von Docker abdecken zu können und kommt ohne root-Rechte aus. Die Anfänge findet Podman bei Red Hat, wo die Entwicklung eines Debugging-Tools in ein umfangreiches Werkzeug für das Container-Management ausartete. Zu finden ist Podman in den gängigen Linux-Distributionen von Red Hat in den Haupt-Repositories und beispielsweise bei Fedora 31 bereits vorinstalliert (https://podman.io/getting-started/installation.html). Bei Debian Distributionen sieht die Installation etwas komplizierter aus aber für alle gängigen Distributionen gibt es auf der offiziellen Webseite podman.io Anleitungen (https://podman.io/getting-started/installation).

Podman ist OCI-friendly – was heißt, dass Podman den Standards der Open Container Initiative entspricht.

Exkurs: Die Open Container Initiative (OCI) ist ein im Jahr 2015 von der Linux Foundation ins Leben gerufener Standard für die Virtualisierung auf Betriebssystemebene. Die OCI definiert zwei Spezifikationen besonders: Zum einen die Laufzeitspezifikation (runtime-spec) und zum anderen die Buildspezifikation (image-spec).

Gerade die Kompatibilität zu Docker wird von den Podman-Entwicklern beworben; neben den Funktionen sollen die identischen Befehle die Migration von Docker zu Podman vereinfachen. Während für den Anwender auf den ersten Blick kein großer Unterschied zu sehen ist, unterscheiden sich die beiden Management-Tools jedoch stark:

Die erste Unterscheidung fällt bei der ersten Verwendung auf. Während bei Docker zuerst der Docker-Daemon gestartet werden muss, kann ein Podman Container direkt von der Kommandozeile gestartet werden. Es gibt also keinen Hintergrundprozess und die Anwendung wird nur ausgeführt, wenn sie auch gebraucht wird. Aus der Sicherheitsperspektive ist das gut, denn Podman bietet weniger Angriffsfläche, wenn der Daemon nicht rund um die Uhr mit Superuser-Berechtigungen laufen muss. Dass bei Podman kein Hintergrundprozess benötigt wird, liegt an der Architektur, die sich gegenüber Docker grundlegend unterscheidet. Während Docker dem Client-Server-Modell folgt, bei dem der Docker-Client über eine API mit dem Docker-Daemon kommuniziert, folgt Podman dem Fork-Exec-Modell. Dabei läuft jeder Container als Kind-Prozess von Podman.

An einem Beispiel erstellen wir einen Container mit dem Alpine-Image und lassen darin den Befehl top laufen:

$ podman run --name testcontainer --rm -d alpine top
68da2012cdfbc7ff55af7cc6eca64daa078d225733a0c7cc5ca2eec736d74b65 

Mit dem nächsten Befehl gehen wir in den vorher erstellten Container und überprüfen, welcher Benutzer den Befehl top ausführt:

$ podman exec testcontainer ps -ef | grep top
    1 root      0:00 top 

Die Ausgabe zeigt, dass der Befehl von dem Nutzer root ausgeführt wird. Während Podman damit wirbt, dass die Prozesse auf dem Host nicht als root ausgeführt werden, überprüfen wir das im nächsten Schritt:

$ ps -ef | grep top
user1         1573    1567  0 19:39 ?        00:00:00 top 

$ docker run --name testcontainer --rm -d alpine top
68da2012cdfbc7ff55af7cc6eca64daa078d225733a0c7cc5ca2eec736d74b65

$ docker exec testcontainer ps -ef | grep top
    1 root      0:00 top
$ ps -ef | grep top
root         1573    1567  0 19:39 ?        00:00:00 top 

Das Stichwort heißt Namespace. Wenn Podman mit normalen Benutzerrechten ausgeführt wird, wird bei erster Verwendung ein User-Namespace erstellt. In dem User-Namespace läuft Podman dann mit root-Rechten und hat die Rechte, Dateisysteme zu mounten und Container zu erstellen. Der Podman-Container hat entsprechend nur die Rechte, die der ausführende Nutzer hat. Was mit der Verwendung von User-Namespaces einhergeht, ist, dass jeder Nutzer seine eigenen Container erstellen und verwalten kann, diese jedoch für andere Nutzer und  für den Superuser nicht ersichtlich sind.

Dadurch, dass Podman unabhängig von Docker betrieben wird, haben die Entwickler großen Spielraum und können auf Wünsche der Community eingehen. Interessante Erweiterungen bei Podman sind zum Beispiel der Befehl mount/unmount und die Systemd-Integration.

Mit dem Befehl mount/unmount kann der Host das Dateisystem des Containers mounten, um bspw. auf Dateien zuzugreifen oder diese zu verändern und anschließend wieder un-mounten.
Gerade die Systemd-Integration wird bei vielen Systemintegratoren auf offene Wunden treffen und diese schließen. Allgemein ist Systemd aus dem Alltag zeitgemäßer IT-Systeme nicht mehr wegzudenken und doch ließen die Container-Management-Tools bisher auf sich warten. Während aufgrund des Daemons bei Docker die Überwachung der Container mittels Systemd nicht funktioniert und auch die Verwendung von Systemd innerhalb von Container problematisch ist, ist Systemd bei Podman mit an Bord. Mit Podman lassen sich Container über Systemd starten, überwachen und auch neu starten. Zusätzlich liefert Podman den Befehl podman generate systemd, welcher für den jeweiligen Container einen entsprechenden Systemd-Service generiert und dem Anwender damit die Erstellung der Systemd-Services abnimmt. Damit ist die Integration auf dem Host-System vorhanden. Und wie sieht es innerhalb der Container aus?

Auch innerhalb von Containern haben die Entwickler von Podman eine Systemd-Integration möglich gemacht. Mit der Option –-system=true werden dafür bestimmte Mount-Points gesetzt. Innerhalb des Containers können dann gewohnte Systemd-Kommandos abgesetzt werden, um die Services zu steuern und zu überwachen. (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/managing_containers/running_containers_as_systemd_services_with_podman)

Fazit

Podman zeigt sich als mächtiges und umfangreiches Container-Management-Tool und setzt seinen Fokus dabei auf Sicherheit. Damit ist Podman definitiv eine Docker-Alternative bzw. kann Docker in den meisten Fällen ersetzen. Neben den Funktionen, die Docker schon bietet, bietet Podman noch einige weitere interessante Features, wie die Systemd-Integration und das einfache Mounten des Container-Dateisystems. Damit steht dem produktiven Einsatz von Podman nichts im Wege.