# Podman: Container ohne Root-Rechte und ohne Dämon

TL;DR / Management Summary Während Docker die Container-Welt berühmt gemacht hat, adressiert Podman (Pod Manager) zwei architektonische Schwächen: Den zentralen Dämon (Single Point of Failure) und den Root-Zwang. Podman läuft daemonless und ermöglicht es jedem Benutzer, eigene Container zu starten (Rootless), ohne die Sicherheit des Gesamtsystems zu gefährden. Für sicherheitskritische Enterprise-Umgebungen ist Podman die moderne Wahl.

# 1. Einführung & Architektur

Warum Podman anders ist.

Docker benötigt einen Hintergrundprozess (dockerd), der als Root läuft. Wenn der Dämon stirbt, sterben alle Container. Podman hingegen ist ein einfaches Tool, das den Container-Prozess direkt forkt (wie ein normaler Linux-Befehl).

# Architektur-Vergleich (Mermaid)

graph TD
    subgraph "Docker Architecture"
        A[Docker CLI] -->|Rest API| B[Docker Daemon (Root)]
        B --> C[Container 1]
        B --> D[Container 2]
    end
    subgraph "Podman Architecture"
        E[Podman CLI (User)] --> F[Container 1]
        E --> G[Container 2]
        F --- H[Kernel Namespaces]
        G --- H
    end

# 2. Rootless Containers: Der Sicherheitsgewinn

Angriffsfläche minimieren.

In Podman kann ein normaler User einen Webserver auf Port 8080 starten. Innerhalb des Containers denkt die Applikation, sie sei Root (UID 0), aber auf dem Host-System läuft der Prozess unter der UID des Users (z.B. 1000).

# Einrichtung (Rootless Prerequisites)

Ubuntu/Debian benötigen slirp4netns für das User-Networking.

sudo apt update
sudo apt install podman slirp4netns uidmap

# 3. Nutzung: Von Docker zu Podman

Ein sanfter Umstieg.

Das CLI von Podman ist zu 99% identisch mit Docker. Viele Admins nutzen einen Alias: alias docker=podman.

# Image ziehen (Podman fragt nach der Registry, z.B. docker.io)
podman pull nginx

# Container starten
podman run -d --name myweb -p 8080:80 nginx

# Pods erstellen (K8s Konzept: Mehrere Container teilen ein Netz)
podman pod create --name mystack
podman run -d --pod mystack --name db mariadb
podman run -d --pod mystack --name app node-app

# 4. Day-2 Operations: Systemd-Integration

Container als echte System-Dienste.

Da Podman keinen Dämon hat, nutzen wir das bewährte Systemd, um Container beim Booten zu starten und zu überwachen.

# Generiere ein Unit-File für einen laufenden Container
podman generate systemd --name myweb --files --new

# Verschiebe es in den User-Space (oder global)
mv container-myweb.service ~/.config/systemd/user/
systemctl --user daemon-reload
systemctl --user enable --now container-myweb.service

# 5. Troubleshooting & “War Stories”

Die Tücken des Daemonless-Ansatzes.

# Story 1: “Der User-Namespace Albtraum”

Symptom: Ein Volume-Mount schlägt mit “Permission Denied” fehl, obwohl der User auf dem Host die Rechte hat. Ursache: Durch das User-Mapping (UID 1000 -> UID 0 im Container) passen die Dateiberechtigungen nicht mehr zusammen. Lösung: Nutzen Sie das Flag --userns=keep-id, damit die UIDs im Container identisch mit dem Host-User bleiben.

# Story 2: “Privilegierte Ports (< 1024)”

Symptom: Rootless Podman kann Port 80 oder 443 nicht binden. Ursache: Linux erlaubt nur Root das Binden von Ports unter 1024. Lösung: Entweder Port > 1024 nutzen (Empfohlen) oder den Kernel-Parameter anpassen: echo "net.ipv4.ip_unprivileged_port_start=80" >> /etc/sysctl.conf.

# 6. Fazit & Empfehlung

• Sicherheit: Podman ist Docker haushoch überlegen, wenn es um Mandantenfähigkeit und Privilege Escalation geht.
• Workflow: Wenn Sie Kubernetes nutzen, ist Podman ideal, da es das Konzept von Pods nativ unterstützt.
• Wahl: Nutzen Sie Podman auf Workstations und in gehärteten Umgebungen. Docker bleibt oft der Standard für CI/CD Pipelines mit massivem Tooling-Support.

# Anhang: Cheatsheet