Container-Images sind längst Teil kritischer Lieferketten. Sie transportieren Betriebssystembibliotheken, Laufzeitumgebungen, Unternehmenssoftware und gelegentlich vertrauliche Konfigurationen. In diesem Kontext ist das Vertrauen in ein Image ein sicherheitsentscheidender Faktor. Es geht nicht nur darum, ob ein Image technisch gültig ist, sondern ob es wirklich von der Stelle stammt, die es behauptet. Signieren und Verifizieren sind deshalb kein „Security Add-on“, sondern ein verbindlicher Bestandteil moderner Produktionspipelines.
Eine Signatur belegt die Herkunft eines Images. Technisch betrachtet wird ein Digest – also der unveränderliche Hash eines Manifests – mit einem kryptografischen Schlüssel signiert. Daraus entsteht eine Vertrauenskette: „Dieser Digest wurde von diesem Signaturgeber bestätigt.“ Ein Deployment, das auf dieser Grundlage arbeitet, kann mit hoher Sicherheit feststellen, ob ein Image modifiziert oder manipuliert wurde.
Das Grundprinzip entspricht Code Signing oder Package Signing in Linux-Distributionen. Ein Image ist damit nicht bloß ein Blob aus Layern, sondern eine überprüfbare Einheit in einer überprüfbaren Lieferkette.
Podman implementiert das OCI-Framework zur Image-Signierung. Dabei spielen drei Komponenten eine Rolle:
Podman unterscheidet zwischen einfachen lokalen Signaturen (klassisches signing) und moderneren, dezentrale Trust-Modellen wie cosign (sigstore), die zunehmend in produktionsnahen Szenarien dominieren.
Der technische Kern ist jedoch immer gleich: Signaturen sind nicht Teil des Images selbst, sondern werden separat abgelegt – entweder in der Registry oder lokal.
Das Image bleibt unverändert, nur der Verweis auf die Signatur wird veröffentlicht.
Ein Signiervorgang besteht aus zwei Phasen: Erzeugen der Signatur und Ablegen der Signatur.
Podman ermittelt den Digest automatisch. Er repräsentiert das Manifest und indirekt dessen Layer. Ein wichtiger Punkt: selbst kleine Änderungen an einem Layer erzeugen einen vollständig neuen Digest. Signaturen sind daher streng Build-spezifisch.
Die Signatur erfolgt über ein Schlüsselpaar. In der Praxis sind zwei Modelle verbreitet:
Keyless Signing hat den Vorteil, dass keine privaten Schlüssel verwaltet werden müssen. Die Identität wird über kurzlebige Zertifikate bestätigt, die wiederum über Transparenzlogs abgesichert sind.
Registries wie Harbor, Quay oder GitLab unterstützen das Ablegen von Signaturen an dedizierten Orten im Repository. Podman lädt diese Signatur separat hoch. Die meisten modernen Registries erkennen Signaturen automatisch und können Verifizierungsanforderungen erzwingen.
Die Signatur allein schützt nichts. Erst die Validierungsrichtlinie
entscheidet, ob ein Image akzeptiert wird. Podman nutzt dafür
policy.json. Dieses File beschreibt, was erlaubt ist:
Das Policy-System wird bei jedem Pull und jedem Deploy angewendet. Selbst wenn ein Entwickler versucht, ein unsigniertes Image zu laden, blockiert die Policy diesen Vorgang zuverlässig.
Es ist dabei möglich, unterschiedliche Vertrauensstufen zu definieren. Eine interne Registry kann strikt signaturpflichtig sein, während externe Images nur mit manueller Freigabe akzeptiert werden.
Die naheliegende Vermutung ist, dass Signieren kompliziert sei. In der Realität lässt sich der Vorgang vollständig in Pipelines automatisieren. Moderne Build-Systeme integrieren Signaturwerkzeuge bereits standardmäßig.
Der typische Ablauf lautet:
Ein kritischer Hinweis für Teams: der Signiervorgang muss deterministisch und automatisiert sein. Jede manuelle Signatur stellt ein Risiko dar. Genau wie bei Infrastructure as Code gilt: manuell erzeugte Artefakte sind nicht auditierbar.
Mit sigstore hat sich ein neues Modell etabliert: Signieren ohne private Schlüssel. Der Identitätsnachweis erfolgt über einen Identity Provider (GitHub, Google, Azure AD). Die Plattform erstellt ein kurzlebiges Zertifikat, signiert den Digest und trägt die Signatur in ein öffentlich einsehbares Transparenzlog ein.
Das hat zwei wesentliche Vorteile:
Für Unternehmen mit strengen Regularien ist dieser Ansatz hoch attraktiv, da er sich gut in Zero-Trust-Architekturen einfügt.
Ein komplexeres Szenario entsteht, wenn ein Tag nicht auf ein einzelnes Image verweist, sondern auf eine Manifestliste. Hier gilt: jede Variante (amd64, arm64) muss separat signiert werden, da jeweils ein eigener Digest existiert.
Das Manifest selbst kann ebenfalls signiert werden, doch das ersetzt nicht die Signatur der Einzel-Images. In produktionsnahen Umgebungen setzt man üblicherweise auf:
Damit entsteht eine doppelte, aber robuste Vertrauenskette.
Verifizierung ist nicht nur ein CI-Thema, sondern ein laufender Prozess. Systeme wie Kubernetes oder ArgoCD können Signaturprüfungen in Admission Controller integrieren. Dadurch wird sichergestellt, dass nur signierte Images in Pods landen.
Beispiel:
Admission Controller verweigert ein Deployment, wenn: – Signatur fehlt – Signatur falsch ist – Signaturgeber nicht zugelassen ist – Registry nicht vertrauenswürdig ist
Für Cluster mit starkem Compliance-Fokus ist das die einzig tragfähige Variante.
Zwei Probleme tauchen in der Praxis immer wieder auf:
Ein Tag wird neu gesetzt, die Signatur bezieht sich aber noch auf den alten Digest. Der Effekt: die Registry zeigt ein Image, für das keine gültige Signatur mehr existiert.
Lösung: Tags nie manuell setzen, sondern ausschließlich durch Pipelines.
Nicht jede Registry kann Signaturen speichern oder Signaturvalidierung erzwingen. Das führt zu Fragmentierung: Signaturen liegen lokal, aber nicht zentral. Teams müssen hier bewusst Registries wählen, die das vollständige OCI-Signaturmodell unterstützen.