22 Registry-Integration und Authentifizierung

22.1 Container-Registries als zentrales Versorgungsnetz

Container-Registries sind die zentrale Bezugsquelle für Images und bilden das Fundament verteilter Build- und Deployment-Prozesse. Sie entsprechen funktional den Paketquellen klassischer Linux-Distributionen: Sie liefern die Basisartefakte, die anschließend lokal ausgeführt, weiterverarbeitet oder in automatisierten Pipelines integriert werden.

Podman nutzt für den Zugriff auf Registries ausschließlich standardisierte Mechanismen aus der OCI Distribution Specification. Es existiert kein Daemon, der Registry-Operationen kapselt oder abstrahiert. Alle Vorgänge – Pull, Push, Authentifizierung, Signaturprüfung – laufen sichtbar und nachvollziehbar über definierte Konfigurationsdateien und Bibliotheken.

22.2 Anlaufstelle: registries.conf

Zentrale Steuerdatei für Registry-Verhalten:

/etc/containers/registries.conf

Sie definiert:

Beispiel:

unqualified-search-registries = ["docker.io", "quay.io"]

[[registry]]
location = "registry.example.com"
insecure = true

Die Transparenz dieser Konfiguration erleichtert Debugging und erlaubt exakte Kontrolle darüber, wohin Images gezogen oder gepusht werden.

22.3 Authentifizierung: Explizite Logins statt Daemon-Verwaltung

Podman speichert Anmeldedaten nicht in einem Dienst, sondern in JSON-Dateien, die direkt vom Benutzer erzeugt und verwaltet werden.

Login:

podman login quay.io

Speicherorte:

$XDG_RUNTIME_DIR/containers/auth.json     # temporär, sessionbezogen
$HOME/.config/containers/auth.json        # persistent

Format: Docker-kompatibel.

Beispiel:

{
  "auths": {
    "quay.io": {
      "auth": "dXNlcjpwYXNz"
    }
  }
}

Da Podman denselben Standard wie Buildah, Skopeo und CRI-O verwendet, lassen sich dieselben Credentials systemweit nutzen.

22.4 Authentifizierungsmechanismen

22.4.1 Username/Password

Standardfall, sowohl interaktiv als auch automatisiert nutzbar.

22.4.2 Token-basierte Zugriffe

Zahlreiche Registries ersetzen Kennwörter durch Tokens. Podman unterscheidet technisch nicht – das Token wird wie ein Passwort verarbeitet.

22.4.3 Service- oder Robot-Accounts

Automatisierte Pipelines nutzen dedizierte Maschinenkonten. Deren Credentials können in CI/CD-Umgebungen generiert und in Auth-Dateien eingebunden werden.

22.4.4 OIDC-/OAuth-basierte Registries

Bei Cloud-basierten Registries wird ein ID-Token generiert und als Zugangsschlüssel verwendet. Podman selbst abstrahiert den Token-Prozess nicht, sondern verarbeitet das Resultat.

22.5 Push und Pull: Transport, Signaturen und Sicherheit

Standardbefehle:

podman pull registry.example.com/app:1.0
podman push registry.example.com/app:1.0

22.5.1 TLS und „insecure registries“

TLS ist Standard. Nicht signierte oder selbstsignierte Registries benötigen explizite Freischaltung:

[[registry]]
location = "registry.example.com"
insecure = true

22.5.2 Signaturen prüfen

Podman unterstützt die Prüfung von Image-Signaturen. Grundlage ist policy.json:

podman pull --signature-policy /etc/containers/policy.json image

22.5.3 Skopeo: Image-Transport ohne lokale Speicherung

Skopeo kopiert Images direkt zwischen Registries:

skopeo copy docker://quay.io/app:1.0 \
            docker://registry.example.com/app:1.0

Der Vorgang spart lokalen Speicher und verkürzt Transportwege.

22.6 Private Registries: Zertifikate und Vertrauensketten

Für interne Registries sind folgende Punkte relevant:

22.6.1 Zertifikate

CA-Zertifikate werden unter folgendem Pfad abgelegt:

/etc/containers/certs.d/<registry>/ca.crt

Damit lässt sich auch eine vollständig interne PKI abbilden.

22.6.2 Self-signed Certificates

Werden akzeptiert, sobald sie explizit im Registry-spezifischen Zertifikatspfad liegen.

22.6.3 Credential-Verteilung

Automatisierungstools (Ansible, Secret-Management-Lösungen, CI-Umgebungen) können Auth-Dateien erzeugen oder verteilen.

22.7 Tagging-Strategien und Varianten

Eine konsistente Tagging-Strategie ist entscheidend, um Varianten eines Images verwaltbar zu halten:

Podman erzwingt kein Schema, unterstützt jedoch sämtliche Konventionen vollständig.

22.8 Multi-Registry-Szenarien

Registries werden oft in Stufen betrieben:

22.8.1 Entwicklungs- → Produktionsregistry

skopeo copy docker://dev-registry/app:v1 \
            docker://prod-registry/app:v1

22.8.2 Geografisch getrennte Installationen

Mehrere Registries können Last verteilen oder Standorte bedienen.

22.8.3 Air-Gap-Umgebungen

Offline-Verteilung:

podman save app:latest > app.tar
podman load < app.tar

22.9 Interaktion mit Kubernetes

Podman verwendet dieselben Registry-Credentials wie die meisten Kubernetes-Distributionen. Auth-Dateien können direkt in Kubernetes-Secrets überführt werden:

kubectl create secret generic regcred \
  --from-file=.dockerconfigjson=$HOME/.config/containers/auth.json \
  --type=kubernetes.io/dockerconfigjson

Damit entsteht eine durchgehende Linie:

Podman → Registry → Orchestrator.

22.10 Registry-Integration als Teil der Infrastruktur

Registry-Zugriffe sind eine grundlegende Funktion der Container-Infrastruktur. Podman behandelt sie transparent und standardkonform. Jede Operation – Authentifizierung, Transport, Signaturprüfung, Zertifikatsvalidierung – erfolgt ohne versteckte Komponenten. Diese Einfachheit erleichtert Debugging, Automatisierung und die Integration in unterschiedlichste Deployment-Umgebungen.