Als ich über Podman las, habe ich mir immer die Frage gestellt, wieso hat Redhat ihr eigenes Projekt gestartet, das im Grunde wie Docker ist, anstatt Pull Requests mit Verbesserungen an das Docker Projekt zu schicken? Die Antwort erhielt ich mit der Geschichte von Skopeo.
Skopeo :
Skopeo ist die Inspiration und der Anfang von Podman. Skopeo bedeutet “Remote-Suchen” in der griechischen Sprache. Das Redhat-Team hat sich gefragt, wieso zuerst ein Image mit hunderten von MB von der Registery heruntergeladen werden muss, um nachschauen zu können, ob man das gewollte Image hat? Wenn ja, behält man es und wenn nein, schmeißt man es weg. Aufgrund dessen hat Redhat ein Pull Request an das Docker-Project geschickt. Das Docker-Team sich geweigert die Pull Request anzunehmen und hat gemeint, das schadet der API und dem CLI von Docker. Deshalb hat das Redhat-Team sein eigenes Tool entwickelt. So kamen Skopeo und die nachträglichen Gedanken vom Podman-Project zur Welt. Skopeo bot am Anfang die Möglichkeit die JSON Datei von einem Image herunterzuladen. Scopeo kann mittlerweile folgendes: Images pullen, pushen, kopieren zwischen Registeries ohne dazwischen lokal pullen zu müssen. Alles passiert ohne Root-Rechte.
$ mkdir fedora-24 $ skopeo copy docker://fedora:24 dir:fedora-24 $ tree fedora-24 fedora-24 ├── 7c91a140e7a1025c3bc3aace4c80c0d9933ac4ee24b8630a6b0b5d8b9ce6b9d4.tar ├── f9873d530588316311ac1d3d15e95487b947f5d8b560e72bdd6eb73a7831b2c4.tar └── manifest.json |
Woher kommt der Name
Der Name Podman ist ein Kürzel für Pod Manager. Die Container-Orchestrierung Kubernetes hat den Begriff Pod geprägt. Er beschreibt eine Gruppe von Containern, die sich bestimmte Ressourcen teilen und nicht völlig isoliert voneinander laufen. Während Docker Pods nur indirekt über Kubernetes unterstützt wird, sind sie ein integraler Bestandteil von Podman. Eine Gruppe von – bedeutet “pod”, deshalb hat sich Redhat für drei Robben als Logo für Podman entschieden.
Ein Infra-Container verrichtet keine Arbeit, sorgt aber dafür, dass bestimmte Ressourcen des Pods wie Namespaces, CGroups und Netzwerk-Ports am Leben bleiben. Obwohl Podman dem Fork-Exec-Modell folgt und damit nicht als Server läuft, benötigen wir dennoch einen Prozess, der Container überwacht, um etwa Logs- und Exit-Codes zu sichern. Dies ist die Aufgabe von Conmon, ein kleines, in C geschriebenes Monitoring-Werkzeug, dass jedem Container angehängt wird. Neben dem Monitoring hält Conmon das Terminal des Containers offen, um per podman exec zu einem späteren Zeitpunkt das Terminal verwenden zu können.
Aus der Grafik ist ebenfalls die runc zu entnehmen. Runc ist für die Ausführung eines Container-Prozesses zuständig und implementiert die Runtime-Spezifikation der OCI (Open Containers Initiative). Redhat, IBM, Google, Microsoft, Docker und andere Unternehmen haben sich 2015 ausgetauscht und definiert ” was ein Image eines Containers bedeutet und wie dies ausschauen soll”. Den Konsens haben sie als Standards für den Image-Aufbau für die Industrie genommen und OCI (Open Containers Initiative) genannt.
# yum install podman |
$ sudo podman pod create --name podtest $ sudo podman pod ps $ sudo podman create --pod podtest -d fedora sleep 600 $ sudo podman create --pod podtest -d fedora sleep 600 $ sudo podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES $ sudo podman pod start podtest $ sudo podman ps -ap CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD 5f41beccf4d7 docker.io/library/fedora:latest sleep 600 3 minutes ago Up 34 seconds ago awesome_sinoussi 74b9151c37cc 657ce4a71207 docker.io/library/fedora:latest sleep 600 3 minutes ago Up 34 seconds ago romantic_bell 74b9151c37cc f0d8ce498347 k8s.gcr.io/pause:3.1 3 minutes ago Up 3 minutes ago 74b9151c37cc-infra 74b9151c37cc ## Löschen $ sudo podman stop Container1 Container2 ..... $ sudo podman rm Container1 Container2 ..... $ sudo podman rm podtest |
Wie unterscheidet sich Podman von Docker ?
01- Mehr Sicherheit mit rootless-Feature:
Der Container kann ohne root-Rechte ausgeführt werden, allerdings werden Befehle innerhalb des Containers vom root-Benutzer gesteuert. Das heißt im Endeffekt, einem Benutzer bzw. Entwickler müssen keine root-Rechte vergeben werden,um ein Container starten oder ein Image aufbauen zu können. Das schützt den Host vor Angriffen. Ohne dies können Angriffe durch Ausführen der Container-Images gelingen. Es könnte aus dem Container ausgebrochen und beliebiger Code auf dem Host als Root-Benutzer ausgeführt werden.
$ sudo podman pull docker.io/library/alpine:latest
$ sudo podman run -d alpine top
$ sudo podman exec b53c74f9d2d7 ps -ef
PID USER TIME COMMAND
1 root 0:00 top
35 root 0:00 ps -ef
|
$ ps -ef | grep top root 3859 3850 0 10:05 ? 00:00:00 top training 4514 3551 0 10:30 pts/0 00:00:00 grep --color=auto top |
02- Podman folgt dem Ausführenden einer Aktion nach dem Fork-Exec-Modell ,Docker jedoch nicht
Bei Podman bleibt die UID das Gleiche auch innerhalb des Containers. Dies ermöglicht dem Benutzer zu folgen.
[training@agent ~]$ cat /proc/self/loginuid 1000 [training@agent ~]$ sudo -i [root@agent ~]# cat /proc/self/loginuid 1000 [training@agent ~]$ sudo podman run -ti fedora bash -c "cat /proc/self/loginuid; echo" 1000 [training@agent ~]$ sudo docker run -ti fedora bash -c "cat /proc/self/loginuid; echo" 4294967295 [training@agent ~]$ sudo auditctl -w /etc/shadow [training@agent ~]$ sudo podman run --privileged -v /:/host fedora touch /host/etc/shadow [training@agent ~]$ sudo ausearch -m path -ts recent -i | grep touch | grep --color=auto 'auid=[^ ]*' type=SYSCALL msg=audit(05/23/2019 08:46:33.174:1189) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffd3963ef3a a2=O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK a3=0x1b6 items=2 ppid=15917 pid=15926 auid=training uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=21 comm=touch exe=/usr/bin/touch subj=unconfined_u:system_r:spc_t:s0 key=(null) [training@agent ~]$ sudo docker run --privileged -v /:/host fedora touch /host/etc/shadow [training@agent ~]$ sudo ausearch -m path -ts recent -i | grep touch | grep --color=auto 'auid=[^ ]*' type=SYSCALL msg=audit(05/23/2019 08:55:51.905:1224) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffe3699ef56 a2=O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK a3=0x1b6 items=2 ppid=16023 pid=16036 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=touch exe=/usr/bin/touch subj=system_u:system_r:spc_t:s0 key=(null) |
Fazit: Wenn ein Benutzer mit Sudo-Rechten irgendetwas auf dem System macht, wird dies vom auditd-System aufgezeichnet. Mit einem Zugang zu Docker-Socket, ist dies nicht der Fall.
03- Steuerung und Struktur:
Auf der Docker-Seite: In der Tat wird alles von daemon gemanaged z.B registries, images, containers, und kernel. Das Docker command-line interface (CLI) schickt die Befehle zum daemon zur Bearbeitung und bekommt eine Antwort zurück.
Von dem Modell können wir entnehmen, dass wenn ein Fehler den Daemon trifft, funktioniert Docker nicht mehr plus es wird verwaiste Prozesse hinterlassen.
Von Podman Seite: Alles wird von runc gesteuert anstatt vom daemon, welcher oben schon erklärt ist
04 – Integration mit systemd
- Podman kann Sytemd innerhalb des Containers zum laufen bringen
- Unterstützt sd_notify
- Socket aktivation
Remote Api für Podman
- Unterstützt Varlink
- Socket aktivation für den podman-API
[Unit] Description=Podman Remote Api Service Requires=io.podman.socket After=io.podman.socket Documentation=man:podman-varlink(1) [Service] Type=simple ExecStart=/usr/bin/podman varlink unix:/run/podman/io.podman [Install] WantedBy=multi-user.target Also=io.podman.socket |
0 Comments