Durch eine Signatur werden zwei Eigenschaften sichergestellt: Echtheit und Integrität. Kryptografische Signaturen basieren dabei auf mathematischen Einwegfunktionen, die es erlauben einen öffentlichen und privaten Schlüssel zu besitzen, die miteinander in Beziehung stehen, jedoch aus dem öffentlichen Teil der private Teil nicht ermittelt werden kann. Zur Signatur wird eine kryptografische Prüfsumme (Hash) der zu signierenden Daten erzeugt, die mit dem privaten Schlüssel verschlüsselt wird.

Am Beispiel eines Container Images könnte z.B. eine SHA256 Prüfsumme aus der Container Datei gebildet werden. Nehmen wir an, dass die Prüfsumme 1234 ist. Diese wird nun mit dem privaten Schlüssel "verschlüsselt", wir können hier einfach annehmen, dass das Ergebnis 4567 ist. Diese Signatur wird nun dem Container Image als zusätzliche Information beigefügt.
Dazu muss entweder das Container Format oder die Registry die Möglichkeit vorsehen, dieses zusätzliche Datum bereitzustellen.

Mit cosign sieht der Prozess dann konkret folgendermaßen aus. Zunächst muss die zur Plattform passende Version von cosign installiert werden. Hier gibt es verschiedene Wege, einer ist das passende Artefakt von https://github.com/sigstore/cosign/releases herunterzuladen.

Anschließend kann cosign entweder im Keyless-Modus, mit Hardwarekryptomodulen, oder mit eigenem Schlüsselmaterial verwendet werden. Letzteres veranschaulicht am besten den oben skizzierten Prozess.

Der öffentliche Schlüssel kann durch cosign exportiert werden. Mit diesem Schlüssel lassen sich beispielsweise Konfigurationen erzeugen, um Vorgaben umzusetzen, die Sicherstellen, dass Images von genau diesem Ursprung stammen.

Bei der Signatur ist zu beachten, dass Container Images stets eine eindeutige Hash-Referenz besitzen und dazu ein eher symbolischer Name gehört. Der Name wird zum Zeitpunkt der Nutzung zu einem konkreten Image (mit eindeutigem Hash-Namen) aufgelöst. Dabei kann durch die verwendetet Architektur und natürlich in Abhängigkeit des Zeitpunkts ein jeweils anderes Image aufgelöst werden.
Es ist daher empfehlenswert, ein Image bei der Signaturerstellung über den eindeutigen Image-Hash zu referenzieren.
Alternativ löst cosign zum Zeitpunkt der Signatur den Image-Hash auf, doch dies Feature soll zukünftig sogar entfernt werden.

Durch docker image ls --digests können die Hash-Referenzen lokaler Images abgefragt werden.

Die erzeugte Signatur wird durch cosign standardmäßig direkt in die Registry des jeweiligen Images als zusätzliches Element gepusht.

Dazu wird eine definierte URL verwendet. Dadurch lässt sich für jedes Image in einer Registry auch direkt abfragen, ob eine Signatur vorliegt.

Je nach Registry kann eine Signatur durch cosign clean IMAGE auch wieder gelöscht werden.

Um den Signatur-Upload zu unterdrücken, kann mit `--upload=false das Verhalten deaktiviert werden. Die Signatur kann dann in einer lokalen Datei mit --output-signature gespeichert werden. Wird zudem auch kein Timestamp-Logserver verwendet, kann eine Signatur komplett offline erzeugt werden.

Dabei wird die Signatur, Zertifikat bzw. Payload in einer separaten Datei gespeichert. Ein Image kann auch lokal mit Signatur Attachment versehen werden. Dieser Air-Gapped Modus kommt typischerweise beim Transport von Images zum Einsatz.

Diese Daten können nun zur Validierung des Containerimage genutzt werden.

Grundsätzlich wird bei der Validierung einer Signatur folgendermaßen vorgegangen:
Zunächst wird der Hash der zu verifizierenden Daten (erneut) berechnet. Entsprechend dem obigen Beispiel wäre die Prüfsumme wieder 1234, wenn keine Daten modifiziert wurden. Nun wird die Signatur, aus dem Beispiel wäre dies 4567, mit dem öffentlichen Schlüssel entschlüsselt und das Ergebnis mit dem lokal berechneten Hash verglichen. Wenn diese übereinstimmen, dann ist die Signatur gültig.

Bei cosign wird dies im Prinzip genauso durchgeführt, dabei gibt es jedoch noch einige Erweiterungen: Das Transparency Log und der Timestamp Server, die dazu dienen, die Integrität, Authentizität und Nachvollziehbarkeit der Signaturen zu gewährleisten.

Ein Transparency Log ist eine unveränderliche, öffentliche, Datenstruktur, an die lediglich neue Informationen angefügt werden können. Im Transparency Log werden Signaturen, Zertifikate und andere Metadaten speichert und zur öffentlichen Nachvollziehbarkeit zur Verfügung stellt. Cosign verwendet dabei den Dienst Rekor, das ebenfalls Teil des Sigstore-Projekts ist, und als kostenlose öffentliche Instanz bereitsteht. Rekor kann jedoch ebenfalls in eigener Infrastruktur betrieben werden.

Mit dem Timestamp Server wird ein kryptografischer Beweis für den Zeitpunkt, zu dem eine Signatur erstellt wurde, bereitgestellt. Der Zeitstempel wird von einem vertrauenswürdigen Server erstellt und anschließend zusammen mit der Signatur in das Transparency Log eingebettet. Damit werden spezielle Arten von Angriffen, beispielsweise ein altes, signiertes, Image mit einer Sicherheitslücke als aktuelles auszugeben, abgewehrt. Neben der öffentlichen Instanz steht mit dem Timestamp-Authority Projekt eine Implementierung für den eigenen Betrieb bereit.

Ohne diese beiden Dienst ist es möglich eine Offline/Air-Gapped Validierung durchzuführen. Passend zu dem obigen Beispiel des signierten Images wird mit cosign verify dann validiert.

Im regulären Modus werden die Signatur als OCI Artifact in der Registry gespeichert und das öffentliche Rekor Transparency Log verwendet. Der Ablageort in der Registry wird vom Ort des jeweiligen Images abgeleitet und kann mit cosign triangulate auch ausgegeben werden.
Damit ist es dann möglich zu prüfen, ob für ein Image überhaupt cosign Signaturen in der Registry abgelegt sind. Als Werkzeug kann dazu crane oder ein beliebiger HTTP Client genutzt werden, mit dem die Registry API abgefragt wird.

Mit cosign gibt es ein etabliertes und verbreitetes Ökosystem, um Container Images gegen Manipulation abzusichern. Dabei ist es ratsam entsprechende Automatisierungen in der CI/CD Pipeline und regelmäßige Aktualisierungen der Images als Prozess zu nutzen. Die Validierung, ob und wie ein Image signiert ist, muss entsprechend bei der Verwendung vorgesehen werden. So kann bei der Erstellung abgeleiteter Images sichergestellt werden, dass eine aktuelle und sichere Version verwendet wird. Dasselbe gilt für den Einsatz im Cluster, auch hier muss mit geeigneten Verfahren Sorge getragen werden, dass nur aktuelle, signierte, Images von vertrauenswürdigen Herausgebern verwendet werden.

Zu den Themen Kubernetes, Docker und Cloudarchitektur bieten wir sowohl Beratung, Entwicklungsunterstützung als auch passende Schulungen an:

Auch für Ihren individuellen Bedarf können wir Workshops und Schulungen anbieten. Sprechen Sie uns gerne an.