SOPS und Sealed Secrets: Klartext aus Git für MSP-Kubernetes fernhalten

Zwei etablierte Open-Source-Projekte, getsops/sops und bitnami/sealed-secrets, decken eine häufige Lücke in GitOps-Pipelines ab: Secret-Werte aus dem Klartext in der Versionsverwaltung herauszuhalten, während der richtige Cluster sie dennoch automatisch entschlüsseln kann.

Was jedes Tool leistet

SOPS mit rund 22.000 GitHub-Sternen verschlüsselt Konfigurations- und Secret-Dateien, bevor sie committet werden, und nutzt dafür age, PGP oder Cloud-KMS-ähnliche Backends. Der Entschlüsselungszugriff wird darüber gesteuert, wer den Schlüssel besitzt, unabhängig davon, wer Lesezugriff auf das Repository hat. Sealed Secrets mit rund 9.000 Sternen verfolgt einen clustergebundenen Ansatz: Ein clientseitiges Tool verschlüsselt ein Kubernetes-Secret mit dem öffentlichen Schlüssel des Zielclusters und erzeugt eine SealedSecret-Custom-Resource, die sicher in Git gespeichert werden kann. Nur der In-Cluster-Controller, der den passenden privaten Schlüssel besitzt, kann daraus wieder ein nutzbares Secret machen.

Wo sie passen und was sie nicht ersetzen

Gemeinsam eingesetzt decken die beiden Tools komplementäre Hälften desselben Problems ab: SOPS schützt beliebige Dateien, bevor sie Git erreichen, und Sealed Secrets schützt den speziellen Fall eines Kubernetes-Secrets, das an einen Cluster gebunden ist. Keines der beiden ersetzt Credential-Rotation, rollenbasierte Zugriffskontrolle oder Netzwerkisolation – ein SealedSecret kann sicher committet werden, ist aber weiterhin Chiffretext für eine bestimmte Entschlüsselungsgrenze und kein Ersatz für Least-Privilege-Zugriff. Praktische Hygiene ist hier wichtig: Der Kreis derjenigen, die in der CI einen Entschlüsselungsvorgang ausführen dürfen, sollte eingeschränkt werden; entschlüsselte Werte sollten niemals in Build-Logs ausgegeben werden; der Zustand des Sealed-Secrets-Controllers und der Rotationsplan seiner Sealing-Keys sollten überwacht werden. Jede Änderung an einer der beiden Pipelines sollte in einem Nicht-Produktionscluster validiert werden, bevor sie ausgerollt wird.

Die lohnenswerte Gewohnheit

Der Wert jedes dieser Tools liegt in der Kontrolle, die es durchsetzt – ein Build, der fehlschlägt, wenn sich ein Klartext-Secret in einen Commit einschleicht, oder eine Entschlüsselungsgrenze, die nur ein Cluster überschreiten kann – und nicht im Namen des Tools auf einer Folie. Versionen sollten gepinnt werden, die verschlüsselten Dateien sollten in Pull Requests überprüfbar bleiben, und die Schlüsselrotation sollte als geplante Aufgabe und nicht als Incident Response behandelt werden.

Quellen: getsops/sops, bitnami/sealed-secrets.