alexle135 Animiertes Logo
9 Min. Lesezeit

Podman statt Docker? Daemonless Container für mehr Security

Docker-Alternative ohne Root-Rechte: Wie Podman Container sicherer macht und warum viele Admins 2025 wechseln. Praktischer Vergleich für Einsteiger.

Podman statt Docker? Daemonless Container für mehr Security

Podman statt Docker? Daemonless Container für mehr Security

Docker kennst du. Aber hast du schon von Podman gehört?

Podman ist eine sichere Docker-Alternative – ohne Root-Rechte, ohne Daemon. Und 2025 nutzen es immer mehr Admins produktiv.

Hier zeige ich dir, warum.

Das Problem mit Docker (das keiner ausspricht)

Docker ist großartig. Aber es hat ein fundamentales Security-Problem:

Docker braucht Root-Rechte.

# Docker-Daemon läuft immer als root
ps aux | grep dockerd
# root     1234  ... /usr/bin/dockerd

# Jeder Docker-Befehl kommuniziert mit diesem root-Daemon
docker run nginx
# → Läuft über root-Socket: /var/run/docker.sock

Warum ist das problematic?

Problem 1: Container Escape = Root-Zugriff Wenn jemand aus dem Container ausbricht → direkt root auf dem Host.

Problem 2: Docker-Socket als Angriffspunkt Wer /var/run/docker.sock mounten kann → voller root-Zugriff.

Problem 3: Multi-User-Umgebungen Mehrere Entwickler? Alle brauchen Docker-Zugriff = alle können root-Container starten.

Beispiel: Docker-Socket als Security-Risiko

# "Harmloser" Container mit Docker-Socket
docker run -v /var/run/docker.sock:/var/run/docker.sock \
  -it ubuntu bash

# Innerhalb des Containers:
apt update && apt install -y docker.io
docker run -v /etc:/host/etc alpine sh
# → Voller Zugriff auf Host-System

Das geht mit Podman nicht.


Was ist Podman?

Podman = Pod Manager

Entwickelt von Red Hat, jetzt Open Source (Apache 2.0).

Hauptunterschied: Daemonless

Docker:

CLI → Docker-Daemon (root) → runc (Container)

Podman:

CLI → direkt runc (Container)

Kein Daemon = kein permanenter root-Prozess.

CLI-Kompatibilität

Podman nutzt exakt die gleichen Befehle wie Docker:

# Docker
docker run nginx
docker ps
docker build -t myapp .

# Podman (identisch!)
podman run nginx
podman ps
podman build -t myapp .

Du kannst sogar einen Alias setzen:

alias docker=podman
# Jetzt funktionieren alle Docker-Befehle mit Podman

Rootless Container: Das Killer-Feature

Podman kann Container ohne Root-Rechte starten.

Beispiel:

# Als normaler User (nicht root!)
whoami
# alexander

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

# Prüfen
podman ps
# Läuft als User "alexander", nicht als root

Warum das wichtig ist:

Security: Container-Escape bleibt auf User-Level

Multi-Tenant: Jeder Entwickler kann eigene Container, ohne root

Compliance: Weniger privilegierte Prozesse = besser für Audits

Performance-Impact?

Fast identisch zu Docker.

Laut Benchmarks: <5% Unterschied in den meisten Workloads.


Podman vs. Docker: Direkter Vergleich

FeatureDockerPodman
DaemonJa (root)Nein
Root nötigJa (Standard)Nein (rootless mode)
CLI-Kompatibilität-100% Docker-CLI
Docker-ComposeNativevia podman-compose
Kubernetes YAMLNeinJa (native)
Systemd-IntegrationEingeschränktNativ
Image-FormatOCIOCI
RegistryDocker HubDocker Hub + Quay
Desktop-GUIDocker DesktopPodman Desktop

Wann Podman statt Docker?

✅ Nutze Podman wenn:

1. Security wichtig ist

  • Produktionsserver
  • Multi-User-Umgebungen
  • Compliance-Anforderungen

2. Rootless wichtig ist

  • Shared Hosting
  • HPC-Umgebungen
  • Firmen-Richtlinien (kein root für Devs)

3. Systemd-Integration

  • Container als systemd-Services
  • Automatischer Start beim Boot
  • Besser als Docker-Compose für Production

4. Kubernetes-YAML nutzen

  • Du schreibst K8s-Manifests
  • Willst sie lokal testen
  • Podman kann K8s YAML direkt lesen

❌ Bleib bei Docker wenn:

1. Docker-Desktop GUI essentiell

  • Podman Desktop ist noch weniger ausgereift

2. Docker-Compose stark genutzt

  • podman-compose funktioniert, aber nicht 100% kompatibel

3. Unternehmens-Standard ist Docker

  • Teamwork > Sicherheit (kurzfristig)

4. Windows/Mac als Haupt-OS

  • Podman Desktop funktioniert, aber Docker Desktop ist ausgereifter

Podman installieren & nutzen

Installation Ubuntu/Debian

# Repository hinzufügen
sudo apt update
sudo apt install -y podman

# Version prüfen
podman --version
# podman version 4.9.3

Erster Container (rootless!)

# Ohne sudo!
podman run -d \
  --name webserver \
  -p 8080:80 \
  nginx:latest

# Prüfen
podman ps

# Testen
curl http://localhost:8080
# → Nginx Default Page

# Logs
podman logs webserver

# Stoppen & entfernen
podman stop webserver
podman rm webserver

Das war’s. Kein root nötig.


Docker-Compose → Podman-Compose

Docker-Compose File (wie gewohnt)

version: '3'
services:
  web:
    image: nginx
    ports:
      - "8080:80"
  db:
    image: postgres:13
    environment:
      POSTGRES_PASSWORD: secret

Mit Podman nutzen

Option 1: podman-compose

# Installation
pip3 install podman-compose

# Nutzen (wie docker-compose)
podman-compose up -d
podman-compose ps
podman-compose down

Option 2: Podman Pods (Kubernetes-Style)

# YAML zu Pod konvertieren
podman play kube docker-compose.yml

# Oder direkt Kubernetes-YAML nutzen
podman play kube k8s-deployment.yaml

Systemd-Integration: Container als Service

Docker: Kompliziert via Docker-Compose + Systemd

Podman: Native Systemd-Units generieren

Container als Systemd-Service

# Container erstellen
podman run -d \
  --name myapp \
  -p 8080:80 \
  nginx

# Systemd-Unit generieren
podman generate systemd --new --name myapp > ~/.config/systemd/user/myapp.service

# Aktivieren
systemctl --user daemon-reload
systemctl --user enable --now myapp

# Container startet jetzt automatisch beim Boot!

Vorteile:

  • ✅ Auto-Start beim Boot
  • ✅ Service-Management wie andere Systemd-Services
  • ✅ Logs via journalctl
  • ✅ Kein Docker-Daemon nötig

Podman Pods: Kubernetes-Style lokal

Besonderheit von Podman: Native Pod-Unterstützung

Was ist ein Pod?

Pod = Gruppe von Containern die zusammengehören (wie in Kubernetes)

Beispiel: Web + DB in einem Pod

# Pod erstellen
podman pod create --name myapp -p 8080:80

# Web-Container zum Pod hinzufügen
podman run -d \
  --pod myapp \
  --name web \
  nginx

# DB-Container zum Pod hinzufügen
podman run -d \
  --pod myapp \
  --name db \
  postgres:13

# Alle Container im Pod teilen:
# - Network Namespace (localhost-Kommunikation)
# - IPC
# - Optional: PID, UTS

# Pod-Status
podman pod ps

# Kubernetes-YAML generieren
podman generate kube myapp > myapp-pod.yaml
# → Deploybar auf echtem Kubernetes!

Use-Case: Lokale Entwicklung mit K8s-Kompatibilität.


Migration von Docker zu Podman

Schritt 1: Alias setzen (Quick-Start)

# In ~/.bashrc oder ~/.zshrc
alias docker=podman
alias docker-compose=podman-compose

# Reload
source ~/.bashrc

# Jetzt: Alle docker-Befehle nutzen Podman
docker run nginx
docker ps

Funktioniert für 95% der Befehle.

Schritt 2: Bilder migrieren

Option A: Von Docker-Daemon importieren

# Docker-Image speichern
docker save nginx > nginx.tar

# In Podman importieren
podman load < nginx.tar

Option B: Registry nutzen

# Pull von Docker Hub (funktioniert identisch)
podman pull nginx
podman pull postgres:13

Schritt 3: Docker-Compose Files anpassen

Meistens: Keine Änderung nötig

Falls Probleme:

# podman-compose statt docker-compose
podman-compose up -d

# Oder: Zu Podman Pods konvertieren
podman play kube docker-compose.yml

Schritt 4: Rootless testen

# Sicherstellen: Kein sudo nötig
podman run hello-world
# Funktioniert? → Rootless aktiv!

# Falls nicht:
podman system migrate
podman info | grep -i rootless

Troubleshooting: Häufige Probleme

Problem 1: Permission Denied bei Ports <1024

Ursache: Rootless-Container können keine privilegierten Ports binden.

Lösung:

# Port-Mapping >1024 nutzen
podman run -p 8080:80 nginx  # ✅ Funktioniert

# Oder: sysctl anpassen
sudo sysctl net.ipv4.ip_unprivileged_port_start=80

Problem 2: “command not found: docker-compose”

Ursache: Docker-Compose ist nicht installiert.

Lösung:

# podman-compose installieren
pip3 install podman-compose

# Oder: Docker-Compose via pip
pip3 install docker-compose

# Dann: Alias setzen
alias docker-compose=podman-compose

Problem 3: Volumes funktionieren anders

Docker: Volumes in /var/lib/docker/volumes/

Podman (rootless): Volumes in ~/.local/share/containers/storage/volumes/

Lösung:

# Podman-Volumes anzeigen
podman volume ls

# Volume erstellen
podman volume create mydata

# Nutzen
podman run -v mydata:/data nginx

Performance-Vergleich: Docker vs. Podman

Benchmark-Ergebnisse (2025):

MetrikDockerPodmanDiff
Container-Start1,2s1,3s+8%
Image-Build45s46s+2%
Runtime CPU100%98%-2%
Memory Overhead150MB (Daemon)0MB-100%

Fazit: Fast identisch, aber Podman spart RAM (kein Daemon).


Wer nutzt Podman produktiv?

Red Hat / IBM (Entwickler von Podman)

  • Rootless Container in OpenShift

Sysdig (Security-Firma)

  • Compliance-Anforderungen

GitLab (CI/CD)

  • Rootless Runners

Viele HPC-Umgebungen

  • Universitäten, Forschung (kein root für Nutzer)

Meine Erfahrung als Umschüler

Background: 5 Monate FISI-Umschulung, Docker-Grundlagen vorhanden.

Was ich getestet habe:

Rootless Container für private Projekte → Funktioniert perfekt, kein sudo nötig

Podman-Compose für Docker-Compose Files → 90% funktioniert, manche Edge-Cases brechen

Systemd-Integration für Homelab-Services → Besser als Docker-Compose + restart policies

Docker Desktop GUI fehlt mir manchmal → Podman Desktop ist okay, aber weniger poliert

Mein Setup:

# Server (Production): Podman
# Warum: Rootless, besser für Systemd

# Laptop (Dev): Docker
# Warum: Docker Desktop GUI, bessere IDE-Integration

# Langfristig: Wechsel zu Podman Desktop

Fazit: Podman ist ready for production. Lernkurve: fast null (wenn du Docker kannst).


Fazit: Docker oder Podman?

Podman, wenn:

✅ Security wichtig ist (rootless!) ✅ Systemd-Integration gewünscht ✅ Multi-User-Umgebung ✅ Kubernetes-YAML lokal testen

Docker, wenn:

✅ Docker Desktop GUI essentiell ✅ Team nutzt Docker (Konsistenz) ✅ Windows/Mac-Hauptsystem ✅ “Es funktioniert, warum ändern?”

Meine Empfehlung:

Einsteiger: Lern Docker zuerst

  • Mehr Tutorials, größere Community
  • Bessere GUI-Tools
  • Später zu Podman wechseln ist easy

Fortgeschrittene: Podman ausprobieren

  • Security-Vorteil ist real
  • Rootless für Production besser
  • Docker-Kompatibilität zu 95%

Production: Podman (wenn möglich)

  • Kein root-Daemon = weniger Angriffsfläche
  • Systemd-Integration nativ
  • OCI-Standard, kein Vendor-Lock-in

Nächste Schritte

Diese Woche:

  1. Podman installieren (apt install podman)
  2. Ersten rootless Container starten
  3. Docker-Alias testen (alias docker=podman)

Dieser Monat:

  1. Docker-Compose File mit podman-compose testen
  2. Systemd-Service für Container erstellen
  3. Rootless Production-Setup evaluieren

Langfristig:

  1. Migration-Plan für bestehende Docker-Setups
  2. Podman für neue Projekte nutzen
  3. Kubernetes-YAML lokal mit Podman testen

Quellen & Weiterführendes


Nutzt du schon Podman oder noch Docker? Welche Erfahrungen hast du gemacht? Schreib mir: schneider@alexle135.de

Das könnte dich auch interessieren

← Zurück zur Übersicht