Cosign und External Secrets Operator: eine Kubernetes-Supply-Chain-Baseline für MSPs

Dieser Leitfaden verbindet zwei Open-Source-Kontrollen, die MSPs in einer verwalteten Kubernetes-Flotte einsetzen können: das Signieren und Verifizieren von Container-Images mit Sigstore Cosign sowie das Heraushalten von Zugangsdaten aus Git mit dem External Secrets Operator. Gemeinsam schließen sie zwei der häufigsten Lücken in einer Kubernetes-Supply-Chain — nicht verifizierte Images und fest codierte Secrets in Manifesten — ohne eine neue Plattform oder Anbieterbindung.

Signieren beim Build, verifizieren beim Deploy

Cosign, Teil des Open-Source-Projekts Sigstore, signiert und verifiziert Container-Images, damit ein Kubernetes-Cluster bestätigen kann, dass ein Image tatsächlich aus einer freigegebenen Build-Pipeline stammt, bevor es ausgeführt wird. Für MSPs zählt ein einfaches Muster: jedes Image beim Build signieren, die Signatur dann bei Admission oder Deploy verifizieren und alles ablehnen, was nicht besteht.

Signiert werden kann mit langlebigen Schlüsseln, die ein Sicherheitsteam verwaltet, oder über den keylosen Ablauf von Sigstore, bei dem Fulcio ein kurzlebiges Zertifikat ausstellt, das einen temporären Schlüssel an eine verifizierte OpenID-Connect-Identität bindet — ein CI-System oder eine Person —, während das Transparenzprotokoll Rekor das Ereignis mit einem Zeitstempel versieht. Die Verifizierung erfolgt dort, wo ein Image ausgeführt werden soll: Ein Admission Controller oder ein Deploy-Gate prüft die Signatur gegen eine freigegebene Identität oder einen Schlüssel und blockiert alles Unsignierte oder nicht Vertrauenswürdige, bevor es einen verwalteten Cluster erreicht.

Was eine Signatur nicht ersetzt

Eine Signatur belegt Herkunft — dass ein bestimmter Digest aus einer bestimmten Pipeline oder Identität stammt —, sagt aber nichts darüber aus, ob dieser Digest bekannte Schwachstellen enthält. Cosign soll neben einem Image-Scanner wie Trivy oder Grype stehen, nicht an dessen Stelle: Der Scanner beurteilt, was im Image steckt, die Signatur belegt, woher es kommt. Wer "signiert" mit "sicher" gleichsetzt, lässt die halbe Kontrolle aus.

Secrets mit External Secrets Operator aus Git heraushalten

Der External Secrets Operator ist ein Kubernetes-Controller, der externe Secret-Manager — darunter AWS Secrets Manager, HashiCorp Vault und Azure Key Vault — mit nativen Kubernetes-Secrets verbindet, sodass Zugangsdaten nicht mehr in einem Git-Repository oder einem Helm-Chart liegen müssen. Er beobachtet eine SecretStore- oder ClusterSecretStore-Ressource und synchronisiert Werte nach einem Zeitplan in native Kubernetes-Secrets, ohne dass der Operator selbst den Klartext protokollieren muss.

Wird jedes ExternalSecret auf den Namespace und die Workload beschränkt, die es tatsächlich benötigt, verringert das den Schaden, falls ein Pod kompromittiert wird. Der Operator hängt weiterhin von den Zugriffskontrollen und der Rotationspolitik des zugrunde liegenden Secret-Managers ab: Er verlagert Zugangsdaten aus der Versionskontrolle, ersetzt aber nicht dessen Sicherheitsniveau.

Warum die Kombination für MSPs zählt

Verwaltete Kubernetes-Flotten sammeln beide Probleme meist gleichzeitig an: fest codierte Secrets aus Bequemlichkeit und Images aus einer Registry ohne Signaturprüfung. Die Einbindung von External Secrets in den Deploy-Pfad nimmt die Ausrede, Zugangsdaten in Manifesten zu speichern, während eine Cosign-Admission-Policy einem MSP ein einziges, auditierbares Gate dafür gibt, ob ein Image aus der eigenen Pipeline stammt.

Keines der beiden Werkzeuge ist für sich genommen ein vollständiges Sicherheitsprogramm. Die Verifizierung durch Cosign ist nur so belastbar wie das Schlüsselmanagement und das Vertrauen in die dahinterstehenden Aussteller, und Least Privilege, Netzwerksegmentierung sowie Incident Response bleiben eigene Aufgaben. Zusammen bilden die beiden Kontrollen jedoch eine wiederholbare Baseline, die sich pro Tenant anwenden lässt, mit einem dokumentierten Ausnahmeprozess für alles, was noch nicht konform ist.

MSPs, die belegen müssen, dass diese Kontrollen einem Audit standhalten, können auf die Cybersecurity-Services von Altovar zurückgreifen, die Penetrationstests, Schwachstellenanalysen, Incident Response und NIS2-/DORA-/GDPR-Konformität abdecken.

Was zu tun ist

• Jedes Image beim Build signieren und die Signatur bei Admission oder Deploy erneut verifizieren; einer Signatur aus dem Build-Schritt allein sollte nicht vertraut werden.
• Zuerst den Fehlerpfad testen: bestätigen, dass ein unsigniertes oder manipuliertes Image tatsächlich abgelehnt wird, bevor das Gate in der Produktion Vertrauen verdient.
• Cosign mit einem Schwachstellen-Scanner wie Trivy oder Grype kombinieren, denn eine gültige Signatur ersetzt keinen sauberen Scan.
• Jede Zugangsdaten aus Manifesten und Helm-Charts in einen von External Secrets Operator verwalteten SecretStore verlagern.
• Jedes ExternalSecret auf den benötigten Namespace und die benötigte Workload beschränken und Schlüssel oder Zugangsdaten nach einem festen Zeitplan rotieren.
• Den Ausnahmeprozess für noch nicht konforme Fälle dokumentieren und Policy-Änderungen zuerst in einem Nicht-Produktionscluster validieren, bevor sie auf die gesamte Flotte ausgerollt werden.

Quellen: GitHub — sigstore/cosign, Sigstore-Dokumentation, External Secrets Operator auf GitHub.