Was ist die Signierung von Container-Images (Docker-Images)?

Die Signierung von Container-Images ist das Verfahren, einem Container-Image eine kryptografische Signatur hinzuzufügen. Dadurch kann jeder, der das Image herunterlädt, überprüfen, wer es veröffentlicht hat und bestätigen, dass es seit seiner Erstellung nicht verändert wurde. Es handelt sich um eine Codesignierung, die auf OCI-Images angewendet wird, die in Docker und Kubernetes ausgeführt werden.

Die Signierung von Container-Images fügt einem Docker- oder OCI-Image eine digitale Signatur hinzu , die mit dem Content Digest des Images verknüpft ist. So kann eine Registry oder ein Kubernetes-Cluster die Herkunft und Integrität des Images vor der Ausführung überprüfen. Die Signierung beweist, dass das Image aus Ihrer Build-Pipeline stammt und weder in der Registry noch während der Übertragung manipuliert wurde. Gängige Tools hierfür sind Sigstore Cosign und Notary v2 (Notation), die Signaturen als separate Artefakte zusammen mit dem Image in der Registry speichern.

Wichtige Erkenntnisse

• Bei der Signierung eines Container-Images wird diesem eine kryptografische Signatur hinzugefügt, die mit seinem Inhalts-Digest verknüpft ist, sodass Verbraucher überprüfen können, wer es erstellt hat und dass es nicht verändert wurde.
• Moderne Signaturverfahren betten die Signatur nicht in das Image ein. Die Signatur wird als separates Artefakt in der OCI-Registry gespeichert, das auf den Image-Digest verweist.
• Die wichtigsten Werkzeuge sind Sigstore Cosign (entwicklerfreundlich, unterstützt schlüssellose OIDC-Signatur und schlüsselbasierte Signierung) und Notary v2 / Notation (standardisiert, PKI- und Truststore-orientiert, bevorzugt für Unternehmen). Docker Content Trust (DCT) ist der ältere Ansatz und wird für offizielle Docker-Images nicht mehr verwendet.
• Signieren Sie immer den Image-Digest (die @sha256-Referenz), niemals ein veränderliches Tag wie :latest, da Tags auf unterschiedliche Inhalte umgeleitet werden können.
• Die Verifizierung wird bei der Bereitstellung durchgesetzt Kubernetes Zugriffskontrollen sorgen dafür, dass unsignierte oder nicht vertrauenswürdige Images blockiert werden, bevor sie ausgeführt werden.

Warum die Signierung von Container-Images wichtig ist

Container sind die Standardeinheit für die moderne Softwarebereitstellung. Ein Container-Image durchläuft zwischen Build und Laufzeit viele Stationen: Ein CI-System erstellt es, eine Registry speichert es, ein Orchestrator lädt es herunter und ein Knoten führt es aus. An jedem dieser Punkte kann ein Angreifer, der ein Image austauschen oder modifizieren kann, seinen Code in Ihrer Umgebung ausführen. Die Signierung von Container-Images schließt diese Sicherheitslücke, indem sie Manipulationen erkennbar macht.

Dies ist dasselbe Lieferkettenproblem, das den SolarWinds-Angriff so verheerend gemacht hat, nur eben auf Container angewendet. Eine Signatur beweist zwei Dinge, die eine Registry allein nicht leisten kann: Herkunft, d. h., dass das Image tatsächlich aus Ihrer Pipeline stammt, und Integrität, d. h., dass die signierten Bytes exakt mit den ausgeführten Bytes übereinstimmen. Ohne Signatur zeigt Ihnen eine Registry lediglich an, dass ein Image existiert, nicht aber, dass es das richtige ist.

Wie die Signierung von Container-Images funktioniert

Die Signierung von Containern folgt dem gleichen Public-Key-Muster wie jede andere Codesignierung , angepasst an die Art und Weise, wie Container-Registries Daten speichern.

1. Aufbauen und vorantreiben durch Verdauen: Ihre Pipeline erstellt das Image und lädt es in eine Registry hoch. Das Image wird durch einen unveränderlichen Inhalts-Digest (einen SHA256-Hash seines Inhalts) identifiziert, nicht nur durch ein veränderliches Tag.
2. Unterschreiben Sie den Verfasserbericht: Ein Signaturtool berechnet einen Hashwert des Bildmanifests und signiert diesen mit einem privaten Schlüssel. Dadurch entsteht eine Signatur, die exakt an diesen Hashwert gebunden ist. Es ist wichtig, den Hashwert und nicht das Tag zu signieren, da Tags später auf andere Inhalte verweisen können.
3. Speichern Sie die Signatur in der Registrierung: Die Signatur wird in dieselbe Registry hochgeladen wie ein separates OCI-Artefakt, das auf den Image-Digest verweist. Die Signatur befindet sich neben dem Image, nicht darin.
4. Vor dem Ausführen überprüfen: Beim Deployment ruft ein Prüfprogramm die Signatur ab, vergleicht sie mit dem vertrauenswürdigen öffentlichen Schlüssel oder der Identität und bestätigt die Übereinstimmung des Hashwerts. Schlägt die Verifizierung fehl, wird das Image abgelehnt.

Ein entscheidender Punkt: Da die Signatur an den Digest gebunden ist, schützt sie den exakten Bildinhalt. Ändert sich auch nur ein Byte des Bildes, ändert sich der Digest, und die Signatur stimmt nicht mehr überein. Dadurch wird eine Manipulation erkennbar.

Die wichtigsten Container-Signaturwerkzeuge

Drei Ansätze sind vorherrschend, und wer weiß, welcher welcher ist, vermeidet viel Verwirrung.

Sigstore Cosign

Cosign, Teil des Sigstore-Projekts der Linux Foundation, ist das am weitesten verbreitete Tool zum Signieren von Containern. Es unterstützt zwei Modi. Die schlüsselbasierte Signierung verwendet einen von Ihnen verwalteten privaten Schlüssel, der in einer Datei, einem Cloud-KMS oder einem HSM gespeichert sein kann, auf das über PKCS#11 zugegriffen wird.

Die schlüssellose Signierung verwendet kurzlebige Zertifikate, die von der Fulcio-Zertifizierungsstelle von Sigstore auf Basis einer OIDC-Identität (z. B. eines GitHub-, Google- oder Microsoft-Kontos) ausgestellt werden. Der Signierungsvorgang wird im öffentlichen Transparenzprotokoll von Rekor protokolliert. Cosign speichert Signaturen zusammen mit dem Image in der OCI-Registry und lässt sich nahtlos in CI-Systeme und die Kubernetes-Zugriffskontrolle integrieren.

Notar v2 (Notation)

Notation ist die Befehlszeilenschnittstelle (CLI) für Notary v2, ein CNCF-Projekt. Sie legt Wert auf ein standardisiertes Signaturformat und ein PKI- und Truststore-Modell, in dem Administratoren über eine Vertrauensrichtlinie definieren, welchen Signaturidentitäten vertraut wird. Dieses Design ist besonders für Unternehmen interessant, die bereits eigene Zertifizierungsstellen betreiben und eine herstellergestützte, spezifikationsbasierte Signatur wünschen. Notation wird in den Managed-Kubernetes-Richtlinien von Microsoft (AKS) und Amazon (EKS) empfohlen.

Docker Content Trust (Legacy)

Docker Content Trust (DCT), basierend auf dem Update Framework und 2015 veröffentlicht, wurde zum Notary v1-Projekt weiterentwickelt. Es ist der ursprüngliche Mechanismus zur Containersignatur, gilt aber mittlerweile als veraltet. Docker hat angekündigt, DCT für offizielle Docker-Images einzustellen und empfiehlt Herausgebern, auf ein neueres System wie Sigstore oder Notation umzusteigen. Registry-Plattformen ziehen nach; beispielsweise hat Harbor die Unterstützung für Notary v1 in Version 2.9 eingestellt und verwendet stattdessen Cosign oder Notation. Neue Bereitstellungen sollten nicht standardmäßig auf DCT setzen.

Werkzeug	Vertrauensmodell	Optimale Bildschirmwahl
Cosign (Sigstore)	Keyless OIDC über Fulcio und Rekor oder selbstverwaltete Schlüssel	Entwicklerfreundliche Signierung, CI/CD, Open Source, umfassende Registry-Unterstützung
Notar (Notar v2)	PKI und Truststore, standardisiertes Signaturformat	Unternehmen mit bestehender PKI; AKS- und EKS-Leitfaden
Docker Content Trust (Notary v1)	TUF-basierte, tagspezifische Schlüssel	Nur für Altbestände; bei Ruhestand ist eine Planmigration möglich.

Bewährte Verfahren für die Signierung von Container-Images

• Unterschreiben Sie den Digest, nicht das Tag: Signaturen werden an den unveränderlichen SHA256-Digest gebunden. Ein Tag wie :latest kann auf unterschiedliche Inhalte verweisen, daher beweist die Signierung eines Tags praktisch nichts.
• Schutz der Signaturschlüssel in Hardware: Langlebige Signaturschlüssel sollten in einem HSM oder einem hardwaregestützten KMS gespeichert werden, nicht auf dem Laptop eines Entwicklers oder der Festplatte eines CI-Runners, damit ein kompromittierter Build-Host sie nicht stehlen kann.
• Überprüfung bei der Zulassung durchsetzen: Verwenden Sie einen Kubernetes Admission-Controller oder eine Policy-Engine, um unsignierte oder nicht vertrauenswürdige Images bereits beim Deployment zu blockieren, damit die Signierung nicht nur eine Empfehlung ist.
• Identität prüfen, nicht nur Anwesenheit: Prüfen Sie, ob ein Bild von einer vertrauenswürdigen Person signiert wurde und nicht nur, ob überhaupt eine Signatur existiert. Eine Signatur mit einem unbekannten Schlüssel ist nicht vertrauenswürdig.
• Herkunftsnachweise und SBOMs beifügen: Moderne Werkzeuge können Herkunftsnachweise und ein Software-Stückliste zum gleichen Zweck, wodurch die Beweiskette gestärkt wird.
• Zentralisierung von Schlüsseln und Auditierung: Nutzen Sie einen zentralen Signaturdienst, damit jeder Signaturvorgang authentifiziert, protokolliert und nachvollziehbar ist, anstatt auf verschiedene Teams mit jeweils eigenen Schlüsseln verteilt zu sein.

Die Unternehmenslücke: Schlüsselmanagement

Die Signaturwerkzeuge lösen das Problem der Erstellung und Überprüfung einer Signatur. Sie allein lösen jedoch nicht das Schlüsselmanagement im Unternehmen. In der Praxis entscheidet sich hier der Erfolg oder Misserfolg von Container-Signaturprogrammen.

Wenn Signaturschlüssel auf Entwicklerrechnern oder CI-Runnern gespeichert sind, sind sie genau dem Risiko von Lieferkettenkompromittierungen ausgesetzt, das durch die Signatur eigentlich verhindert werden soll. Verwaltet jedes Team seine eigenen Schlüssel, gibt es keine zentrale Nachverfolgung, wer was signiert hat, keine einheitlichen Richtlinien und keine einfache Möglichkeit, Schlüssel nach einem Vorfall zu rotieren oder zu widerrufen. Die schlüssellose Signatur verlagert das Vertrauen auf einen Identitätsanbieter und ein öffentliches Transparenzprotokoll. Dies eignet sich zwar für Open-Source-Projekte, erfüllt aber nicht die Compliance- und Datenschutzanforderungen jedes Unternehmens.

Die Unternehmensanforderung besteht darin, Container-Signaturschlüssel in Hardware zu speichern, durchzusetzen, wer signieren darf, und jeden Vorgang zu protokollieren, ohne die Entwickler auszubremsen.

Wie Verschlüsselungsberatung hilft

CodeSign Secure von Encryption Consulting integriert Enterprise-Schlüsselmanagement in die Signierung von Container-Images. Die Signaturschlüssel werden in einem FIPS 140-2 Level 2 HSM anstatt auf Entwicklerrechnern oder CI-Runnern gespeichert. Die Lösung ist in den Workflow der Containersignierung integriert, sodass Images mit hardwaregeschützten Schlüsseln signiert werden. Zudem wird die Berechtigung zum Signieren streng kontrolliert und jeder Vorgang zu Prüfzwecken protokolliert.

Da CodeSign Secure die Signierung über alle Artefakttypen hinweg zentralisiert, steuert dieselbe Plattform, die Ihre Windows-, Java- und Firmware-Signaturen schützt, auch Ihre Container-Images. Dadurch erhalten Sicherheitsteams eine einheitliche Richtlinie und einen lückenlosen Prüfpfad anstelle eines separaten, unkontrollierten Prozesses für Container. Unterstützt durch ISO/IEC 27001:2022- und SOC 2-zertifizierte Verfahren.

Häufig gestellte Fragen

Was ist die Signierung von Container-Images?

Die Signierung von Container-Images (OCI) fügt einem Container-Image eine kryptografische Signatur hinzu, sodass jeder, der es herunterlädt, überprüfen kann, wer es veröffentlicht hat und ob es seit seiner Erstellung verändert wurde. Die Signatur ist an den Inhalts-Digest des Images gebunden und wird als separates Artefakt in der Registry gespeichert. Sie entspricht der Codesignierung in der Containerwelt und schützt die Software-Lieferkette zwischen Erstellung und Bereitstellung.

Worin besteht der Unterschied zwischen Cosign, Notation und Docker Content Trust?

Cosign, ein Bestandteil von Sigstore, ist ein entwicklerfreundliches Tool, das sowohl schlüsselloses OIDC-Signieren als auch selbstverwaltete Schlüssel unterstützt und in CI/CD-Umgebungen weit verbreitet ist. Notation, die CLI für Notary v2, ist ein CNCF-Projekt mit einem standardisierten Signaturformat und einem PKI-Truststore-Modell, das von Unternehmen bevorzugt und für AKS und EKS empfohlen wird. Docker Content Trust (Notary v1) ist der ursprüngliche, TUF-basierte Mechanismus aus dem Jahr 2015; er gilt mittlerweile als veraltet und wird für offizielle Docker-Images nicht mehr unterstützt.

Soll ich das Bild-Tag oder den Digest signieren?

Signieren Sie immer den Digest, die unveränderliche @sha256-Referenz, niemals ein veränderliches Tag wie :latest. Tags sind Zeiger, die jederzeit auf andere Inhalte verweisen können. Daher sagt eine Signatur auf einem Tag praktisch nichts darüber aus, was tatsächlich ausgeführt wird. Eine an den Digest gebundene Signatur schützt die exakten Bildbytes: Ändert sich ein Byte, ändert sich der Digest, und die Signatur ist nicht mehr gültig. Genau das macht Manipulationen erkennbar.

Ist Docker Content Trust weiterhin empfehlenswert?

Nein. Docker Content Trust (DCT), basierend auf Notary v1, ist veraltet. Docker hat angekündigt, DCT für offizielle Docker-Images einzustellen und empfiehlt Herausgebern, auf eine neuere Signatur- und Verifizierungslösung wie Sigstore oder Notation umzusteigen. Registry-Plattformen folgen diesem Beispiel; Harbor hat Notary v1 beispielsweise in Version 2.9 als veraltet markiert. Bestehende DCT-Nutzer sollten eine Migration planen, und neue Implementierungen sollten stattdessen Cosign oder Notation standardisieren.

Wie wird ein signiertes Container-Image bei der Bereitstellung verifiziert?

Die Verifizierung wird üblicherweise von einem Kubernetes-Zugangscontroller oder einer Richtlinien-Engine durchgeführt, die Image-Bereitstellungen abfängt. Bei der Planung eines Pods ruft der Controller die Signatur des Images aus der Registry ab, prüft sie anhand des vertrauenswürdigen öffentlichen Schlüssels oder der Identität und bestätigt, dass die Signatur mit dem Image-Digest übereinstimmt. Ist das Image unsigniert oder mit einer nicht vertrauenswürdigen Identität signiert, lehnt der Controller es ab, sodass im Cluster nur verifizierte Images ausgeführt werden.

Wo sollten Container-Signaturschlüssel gespeichert werden?

Langlebige Container-Signaturschlüssel sollten in einem Hardware-Sicherheitsmodul (HSM) oder einem hardwarebasierten Schlüsselverwaltungsdienst gespeichert werden, nicht auf Entwickler-Laptops oder CI-Runner-Festplatten – genau den Systemen, die Angreifer angreifen würden. Die Speicherung der Schlüssel in Hardware verhindert, dass ein kompromittierter Build-Host den privaten Schlüssel exfiltriert. Unternehmen nutzen typischerweise einen zentralen Signaturdienst, der die Schlüssel in einem HSM speichert, die Signierberechtigung festlegt und ein Audit-Log jedes Signiervorgangs erstellt.

Integrieren Sie Enterprise Key Management in Ihre Containersignatur

Signaturwerkzeuge erzeugen Signaturen. Unternehmen benötigen diese Signaturen mit hardwaregeschützten Schlüsseln, durchgesetzten Richtlinien und einem vollständigen Prüfprotokoll. Entdecken Sie CodeSign Secure , um Ihre Container-Images mit HSM-geschützten Schlüsseln, zentralisierten Richtlinien und Prüfprotokollen zu signieren – parallel zu Ihrer übrigen Codesignierung.