Container-Management mit Podman

Gleiche Maße, anderes Innenleben

Podman ist ein Tool für das Management von Containern, das vor Kurzem in der Version 1.3 veröffentlicht wurde. Im Gegensatz zu Docker kommt die Container-Engine ganz ohne Daemon im Hintergrund aus und lässt sich auch in einem Non-Root-Modus betreiben. Grund genug, sich den Umgang mit Podman einmal genauer anzusehen.
Kommerzielle Software von der Stange oder quelloffene Produkte, die lizenzkostenfrei und flexibler sind, dafür aber oft entsprechendes Know-how voraussetzen? ... (mehr)

Wenn von Containern die Rede ist, denken die meisten fast automatisch an die bekannte Docker-Engine. Seit einiger Zeit allerdings existiert mit Podman [1] eine ernstzunehmende Alternative. Das Projekt wurde zusammen mit CRI-O, einer Implementation des Kubernetes Container Runtime Interfaces (CRI), entwickelt. Podman ist allerdings nicht auf den Einsatz innerhalb einer Kubernetes-Umgebung beschränkt, sondern lässt sich auch für den Betrieb von einzelnen Containern nutzen. Dabei ist es sogar möglich, das von Kubernetes bekannte Konzept der Pods, also einer Ansammlung von Containern, die gewisse Ressourcen miteinander teilen, auch unabhängig von Kubernetes zu verwenden.

Ganz ohne Daemon

Auch wenn die Entwickler von Podman darauf geachtet haben, dass der Einsatz des Kommandozeilentools nahezu identisch mit dem von Docker ist, unterscheiden sich die beiden Container-Engines in ihrer Architektur doch grundlegend voneinander. Während in der Docker-Welt alles auf einem Client-Server-Prinzip basiert, setzt Podman auf das Fork-Exec-Modell: Wird bei Docker mit Hilfe des Kommandozeilentools docker ein neuer Container gestartet, so gelangt diese Anweisung an einen im Hintergrund laufenden Daemon, der den Befehl zum Starten des Containers wiederum an containerd, einen weiteren Daemon des Docker-Frameworks, weiterleitet. Podman hingegen kommt komplett ohne einen Daemon aus und erzeugt alle Container als Kind-Prozesse des eigentlichen Podman-Prozesses.

Aktivitäten durch UID gezielt zuordnen

Diese Architektur erlaubt es, dass das audit-Subsystem des Linux-Kernels Aktivitäten, die innerhalb eines Containers stattfinden, auch eindeutig dem Benutzer zuordnen kann, der den Container gestartet hat. Bekannterweise erhält jeder Benutzer, der sich an einem System anmeldet, eine eindeutige UID zugewiesen. Diese lässt sich aus der Datei "/proc/self/ loginuid" auslesen:

cat /proc/self/loginuid
 
1000

Die loginuid ändert sich nicht, selbst wenn Prozesse unter einer anderen ID gestartet werden. Im folgenden Beispiel erfolgt der Aufruf der Datei nun beispielsweise als root-Benutzer – trotzdem ändert sich die loginuid des Benutzers nicht:

sudo cat /proc/self/loginuid
 
1000

Alle Prozesse, die der Benutzer nun startet, erben automatisch diese loginuid. Dies gilt natürlich auch für Container und Prozesse, die in diesen Containern ablaufen. Das folgende Beispiel liest die Datei "/proc/self/loginuid" nun innerhalb eines Fedora-Containers aus:

sudo podman run --rm fedora cat /proc/self/loginuid
 
1000

Es ist zu erkennen, dass die UID immer noch 1000 lautet. Diesen Umstand können Sie sich nun für das Auditieren von Prozessen innerhalb von Containern zu Nutze machen. In den Logdateien des auditd wird die loginuid im Feld "auid" aufgeführt:

sudo ausearch -k watch-passwd
time->Tue May 28 19:52:15 2019
type=CONFIG_CHANGE msg=audit (1559065935.923:2447): auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=add_rule key="watch-passwd" list=4 res=1

Somit lässt sich sehr leicht nachvollziehen, welche Prozesse von welchem Benutzer auch innerhalb eines Containers ausgeführt wurden. Bei Docker sieht dies ein wenig anders aus. Hier ist ein Daemon für den Start von Containern zuständig, von daher lautet die loginuid immer 4294967295. Das ist die ID, die jeder vom init-System gestartete Prozess vererbt bekommt. Somit ist es nicht mehr möglich, Aktivitäten innerhalb eines Containers einem bestimmten Benutzer zuzuordnen.

Nicht nur die Steuerung der Container ist bei Podman anders als bei Docker. Auch die Verwaltung der Container-Images und der Zugriff auf Container-Registries unterscheidet sich intern erheblich zwischen den beiden Engines. Während bei Docker erneut alles über den zentralen Docker-Daemon läuft, greift Podman hierfür auf Bibliotheken aus dem Container-Repository zurück und ist somit unabhängig von einem Daemon. Für den Endanwender sind diese Unterschiede allerdings vollkommen transparent.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019