Container-Images sind heute zentrale Bausteine moderner Softwarelieferketten. Sie transportieren Applikationslogik, Bibliotheken, Laufzeitabhängigkeiten und Konfigurationen – und sind damit ein idealer Angriffspunkt. Ohne ein strukturiertes Vertrauensmodell gleicht der Umgang mit Images dem Ausführen von Binärpaketen unbekannter Herkunft. Image-Signing ist deshalb kein optionales Feature, sondern eine notwendige Stufe in der Sicherheitsarchitektur, vergleichbar mit Signaturen in Paketmanagern oder Firmware-Updates. Podman, Buildah, Skopeo und Kubernetes bewegen sich in einem gemeinsamen Ökosystem aus Signaturen, Vertrauensankern und Richtlinien, die festlegen, was akzeptiert und was strikt blockiert wird.
Ein signiertes Image beantwortet zwei Fragen:
Dabei werden nicht einzelne Dateien signiert, sondern Manifest und/oder Config der OCI-Struktur. Jede Änderung am Image macht die Signatur ungültig.
Zentrale Konzepte:
Diese Vertrauenskette funktioniert ähnlich wie TLS – nur dass sie auf Container-Registries und OCI-Objekte angewendet wird.
Das Ökosystem kennt mehrere Verfahren. Podman, Skopeo und Buildah nutzen vorrangig:
Podman kann heute in Build- und Deploy-Prozessen sowohl Simple Signing als auch Cosign/Notary-Aufbauten verwenden – je nach Sicherheitsanforderung.
Podman nutzt intern die Bibliotheken von containers/image, die sämtliche Signierungsmechanismen bereitstellen. Praktisch bedeutet das:
Beispiel (Simple Signing mit GPG):
skopeo copy --sign-by dev@example.com \
docker://example.com/app:1.0 \
docker://registry.local/app:1.0Beim späteren Pull entscheidet die Trust Policy, ob das Image akzeptiert wird.
Signaturen sind nutzlos ohne Regeln, die festlegen, welche Signaturen akzeptiert werden dürfen. Diese Regeln stehen in:
/etc/containers/policy.jsonoder nutzerspezifisch unter:
~/.config/containers/policy.jsonEin Beispiel:
{
"default": [{"type": "reject"}],
"transports": {
"docker": {
"registry.local": [
{
"type": "signedBy",
"keyType": "GPGKeys",
"keyPath": "/etc/pki/myteam.pub"
}
]
}
}
}Interpretation:
registry.local werden akzeptiert.Dies ist ein extrem starkes Sicherheitsmodell. Ohne korrekte Signatur verweigert Podman strikt den Containerstart.
Ein vereinfachter Verifikationsprozess:
Jeder Schritt ist zwingend. Ist die Signatur ungültig, fehlt oder stammt vom falschen Schlüssel, bricht Podman ab.
Jede Änderung am Image – selbst ein einzelner Byte-Unterschied – verändert den Digest. Da Signaturen den Digest signieren, bedeutet jede Abweichung:
Error: Source image rejected: signature verification failedDamit sind typische Angriffe praktisch ausgeschlossen:
Diese Zuverlässigkeit ist einer der Gründe, warum Red Hat und OpenShift strikt auf Signaturen setzen.
Ein Unternehmen benötigt typischerweise:
Die Hierarchie kann wie folgt aussehen:
Die Hostsysteme akzeptieren Images nicht aufgrund ihres Ursprungs, sondern aufgrund ihrer Signatur.
Kubernetes selbst überprüft keine Signaturen – die Nodes bzw. Runtimes tun das. CRI-O (OpenShift) und containerd (Sigstore-Plugins) können so konfiguriert werden, dass:
In OpenShift ist signiertes Pulling Standard. Cosign kann darüber hinaus im Admission Layer validiert werden.
Signaturen erzeugen, aber keine Policies setzen → Images werden trotzdem unbesehen akzeptiert.
Policies zu breit formuliert → jede gültige Signatur erkennt der Host, nicht nur interne.
Schlüssel nicht zentral verteilt → Nodes verweigern Images, Pipelines brechen.
Key Rotation ohne Re-Signing → ältere Images werden plötzlich ungültig.
Cosign keyless ohne Rekor-Integration → Signaturen können nicht langfristig auditiert werden.
Image-Signing ist kein Nice-to-have, sondern das Fundament einer vertrauenswürdigen Lieferkette. Die Kombination aus kryptografischer Signatur, klaren Trust Policies und einer durchgängigen Integration in Podman, Skopeo, Buildah und Kubernetes schafft die Grundlage, auf der produktionsnahe Architekturen sicher betrieben werden können.