Container-Images existieren selten nur an einem Ort. Zwischen Public Registries, internen Spiegeln, produktionsnahen Private Registries und lokalen Namespaces entsteht ein Geflecht möglicher Quellen. Podman löst diese Entscheidung nicht über Zufall, sondern über eine definierte Source-Selection-Logik. Wer Images kontrolliert ziehen möchte – ob beim lokalen Entwickeln oder in CI/CD-Pipelines – muss diese Mechanismen verstehen. Gerade in Unternehmen mit Compliance-Anforderungen entscheidet die richtige Registry-Auswahl darüber, ob Deployments reproduzierbar, sicher und auditierbar bleiben.
Die gewohnten Abkürzungen wie nginx, alpine
oder postgres erscheinen harmlos, sind aber technisch
Ambiguitäten. Ein Shortname enthält keine Registry, keinen Namespace und
keine Referenz auf eine vertrauenswürdige Quelle. Podman versucht in
solchen Fällen, die zuständige Registry gemäß Konfiguration in
registries.conf zu bestimmen.
Das Problem: die Reihenfolge der Registry-Auflösung entscheidet,
woher das Image tatsächlich gezogen wird. In einer Entwicklerumgebung
mag docker.io/library/nginx:latest akzeptabel sein, in
einer Produktionsumgebung jedoch nicht. Die Shortname-Resolution erhält
dadurch eine sicherheitskritische Komponente.
Der erste Schritt ist daher meist ein kultureller: Shortnames werden verboten, vollqualifizierte Referenzen verpflichtend. Das mag sperrig wirken, zahlt aber direkt auf Reproduzierbarkeit und Sicherheit ein.
Podman steuert die Source Selection über mehrere
Konfigurationsdateien, von denen registries.conf die
zentrale ist. Dieses File ermöglicht sowohl das Definieren erlaubter
Quellen als auch die Mirror-Kaskadierung.
Ein typisches Setup könnte so aussehen:
Intern → Mirror → Public
Pulls werden zunächst gegen interne Registries ausgeführt, dann gegen dedizierte Mirrors und erst als Fallback gegen Public Registries. Diese Kaskadierung schützt vor Netzwerkproblemen, verbessert die Performance und kontrolliert die verfügbaren Images.
Durch diese Reihenfolge wird verhindert, dass Entwickler oder automatisierte Prozesse versehentlich Images aus dem Internet ziehen, die nicht freigegeben sind.
Ein wenig bekanntes, aber hochwirksames Werkzeug ist das
Shortname-Alias-System. Damit lässt sich festlegen, dass ein Shortname
wie redis grundsätzlich zu einem bestimmten Namespace auf
einer bestimmten Registry aufgelöst wird. Das ermöglicht
unternehmensinterne Varianten von bekannten Basisimages.
Beispiel: redis verweist in der internen Organisation
auf:
registry.corp.example.com/base/redis:latest
Dadurch lassen sich gehärtete oder geprüfte Images bereitstellen, ohne dass Entwickler lange, schwer merkbare Referenzen eintippen müssen.
Ein Industrievorteil: Teams können zentrale Grundimages kuratieren und dennoch eine ergonomische CLI ermöglichen.
Registries sind Vertrauensgrenzen. Das bedeutet, dass der Ursprung eines Images seine Zuverlässigkeit bestimmt. Ein Pull aus einer ungeprüften Registry ist ein Supply-Chain-Risiko. Podman bietet daher feingranulare Einstellmöglichkeiten zur Vertrauensklassifizierung:
Diese Steuerung geschieht über policy.json und
registries.conf. Der Effekt ist direkt spürbar: selbst wenn
Entwickler Shortnames verwenden, ziehen sie Images nur aus den dafür
erlaubten Quellen.
In sicherheitsorientierten Umfeldern wird dieser Mechanismus zum zentralen Gatekeeper.
Mirrors können mehr als nur Performance beschleunigen. Sie sind Gateways zwischen inneren und äußeren Landschaften. In modernen Architekturen werden Mirrors als kontrollierte Staging-Zonen genutzt.
Manche Unternehmen pflegen einen „gescannten“ Mirror, der Images nur veröffentlicht, wenn sie automatisierte Signature-, Vulnerability- und Compliance-Prüfungen bestanden haben. Pulls innerhalb des Unternehmens landen dann ausschließlich auf diesem Mirror.
Dieser Aufbau entkoppelt Entwicklung und Produktion von der Instabilität und Unberechenbarkeit öffentlicher Registries und macht die Image-Lieferkette auditierbar.
Podman speichert Images in einem lokalen Storage, der in
rootless-Setups isoliert pro Benutzer funktioniert. Die lokale Suche
(podman images, podman search) ist nicht nur
Komfort, sondern ein relevanter Mechanismus zur
Entscheidungsfindung.
Wenn ein Image mit identischem Digest bereits lokal vorhanden ist, wird beim Pull nicht erneut übertragen. Die Registry dient in diesem Fall nur zur Validierung. Für Entwickler, die häufig zwischen Projekten wechseln, ist das ein enormer Zeitvorteil.
Ein praktischer Hinweis: wer viele CI-Pipelines lokal testet, sollte regelmäßig prüfen, welche Images sich angesammelt haben. Fehlkonfigurierte Shortname-Resolution führt sonst schnell zu einem Zoo semantisch ähnlicher, aber verschiedener Images.
podman search ermöglicht die Abfrage von
Remote-Registries. Technisch gesehen verwendet Podman die Registry-API
und wertet Metadaten wie Name, Description oder Popularität aus. Der
Wert dieser Funktion hängt stark von der Registry ab. Während Docker Hub
reich strukturierte Suchdaten liefert, bieten viele
Unternehmensregistries nur minimalistische Suchfunktionen.
Für Entwicklerteams ist das dennoch nützlich, etwa um interne Namenskonventionen oder Repositories zu entdecken, ohne lange Dokumentationslisten pflegen zu müssen.
Ein warnender Hinweis: Suchergebnisse ersetzen kein Governance-Konzept. Nur weil ein Image auffindbar ist, bedeutet das nicht, dass es für Produktion geeignet oder freigegeben ist.
Deployments müssen deterministisch sein. Daher ist es im CI/CD-Kontext unerlässlich, die Registry-Auswahl hart zu definieren. Selbst wenn Entwickler flexibel mit Shortnames arbeiten, sollten alle Pipelines explizit auf vollqualifizierte Registry-Namen verweisen.
GitOps-Systeme wie ArgoCD oder Flux arbeiten konsequent digestbasiert. Diese Praxis eliminiert Source-Selection-Probleme vollständig: selbst wenn mehrere Registries eine Image-Variante bereitstellen, entscheidet der Digest über die Identität, nicht der Name.
Für migrationsintensive Projekte mit Hybrid-Registries (z. B. Übergang von Docker Hub zu einem On-Prem-Mirror) ist dies der stabilste Ansatz.
Ephemere Entwicklungsumgebungen – etwa Testumgebungen in Kubernetes, die kurzlebige Lab-Setups simulieren – verwenden häufig lokale oder embedded Registries. Podman kann hier sowohl als Client als auch als serverseitige Engine fungieren.
Die Source Selection erfolgt dann innerhalb einer isolierten Scope: lokale Builds werden direkt in die lokale Registry gepusht, Deployments ziehen ausschließlich daraus. Diese Arbeitsweise ist besonders effektiv in isolierten Netzwerkzonen oder bei Feature-Preview-Umgebungen.