24 Short-Name-Resolution und Sicherheitsimplikationen

24.1 Warum „kurze“ Image-Namen ein großes Thema sind

Wenn man podman run python:3.11 ausführt, gibt man einen unqualifizierten Image-Namen an. Die vollständige Adresse hingegen lautet eigentlich:

<registry>/<namespace>/<image>:<tag>

Fehlt der Registry-Teil, muss Podman selbst entscheiden, woher das Image stammt. Ohne klare Regeln könnte das Bild aus jeder beliebigen Registry geladen werden – öffentlich, privat, kompromittiert oder schlicht unerwartet.

Deshalb besitzt Podman eine explizite Mechanik zur Short-Name-Resolution. Sie ist sicherheitstechnisch so relevant, dass Podman den Benutzer beim ersten Auftreten eines Short-Names zur Bestätigung zwingt.


24.2 Wie die Short-Name-Resolution funktioniert

Beispiel:

podman pull python:3.11

Podman durchsucht nun die in registries.conf definierten Registries:

Ein typischer Abschnitt:

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

Die Reihenfolge ist verbindlich: Podman probiert sie der Reihe nach aus, sofern der Short-Name für die ausgewählte Registry bereits bestätigt wurde.


24.3 Warum Podman inzwischen eine Bestätigung verlangt

Früher gingen Engines stillschweigend davon aus, dass unqualifizierte Namen aus docker.io stammen. Das war bequem, aber in vielerlei Hinsicht gefährlich:

Podman löst das Problem, indem es beim ersten Auftreten eines Short-Names eine explizite Entscheidung verlangt.


24.4 Beispiel: Interaktive Auflösung

Typische Ausgabe:

$ podman pull python
? Which registry do you want to use for python?
  1. docker.io
  2. quay.io
  3. registry.internal
Enter choice:

Die Entscheidung wird anschließend persistiert in:

Beim nächsten Pull ist die Zuordnung bereits klar.


24.5 Sicherheitsimplikationen

Short-Name-Resolution ist ein potenzieller Angriffsvektor, wenn sie unkontrolliert erfolgt.

24.5.1 Lieferkettenrisiken

Unvollständige Namen erlauben:

24.5.2 Manipulierte oder unsichere Registries

Wenn in registries.conf ein unsicheres oder falsch priorisiertes Registry-Setup definiert ist, könnte Podman Images aus Quellen ziehen, die nie beabsichtigt waren.

24.5.3 Credential-Leaks

Bei unqualifizierten Namen kann der Client Anfragen an Registries senden, die nicht vorgesehen sind – inklusive Auth-Header, falls konfiguriert.


24.6 Best Practices

24.6.1 1. Short-Name-Modus bewusst konfigurieren

In registries.conf:

short-name-mode = "enforcing"

Damit erzwingt Podman eine einmalige Abstimmung für jeden Short-Namen.

Alternativ:

short-name-mode = "disabled"

→ Short-Names sind dann nicht mehr erlaubt. Für produktive Automatisierungsskripte oft sinnvoll.


24.6.2 2. In Skripten und Pipelines immer vollständige Image-Namen verwenden

Statt:

python:3.11

besser:

docker.io/library/python:3.11

oder eine interne Registry:

registry.example.com/base/python:3.11

Damit wird jede implizite Auflösung ausgeschlossen.


24.6.3 3. Eigene Namespaces konsequent nutzen

Private Images sollten niemals generische Kurzformen wiederverwenden. Statt service:latest besser:

registry.example.com/team/service:latest

24.6.4 4. Mirrors explizit definieren

Beispiel:

[[registry]]
location = "docker.io"

[[registry.mirror]]
location = "mirror.example.com"

Damit wird verhindert, dass Podman ungewollt externe Registries abfragt.


24.6.5 5. Rootless + Short-Name-Enforcement erhöht Sicherheit

Im rootless Betrieb:

Die Kombination ist besonders sicher auf Multi-User-Systemen.


24.7 Technischer Ablauf der Auflösung

Podman speichert die Auswahl, nicht das fertige Mapping. Die Reihenfolge der Suche bleibt stets in registries.conf definiert.


24.8 Short-Names wirken harmlos – sind aber sicherheitskritisch

Kurzformen wie python:3.11 sehen unproblematisch aus, entscheiden aber darüber, woher Images stammen. Podman macht diese Mechanik sichtbar und zwingt zu bewussten Entscheidungen, damit Containerimages kryptografisch, organisatorisch und infrastrukturell nachvollziehbar bleiben.

Short-Name-Resolution ist damit ein zentrales Element der Sicherheit – kein Komfortdetail.