GitOps behandelt ein Git-Repository als zentrale Quelle für Infrastruktur- und Anwendungskonfiguration. Zugangsdaten gehören jedoch nicht unverschlüsselt in diese Historie. Ein einmal veröffentlichter Schlüssel kann in alten Commits, Forks oder Backups weiterleben, selbst wenn die aktuelle Datei später gelöscht wird. Die Kubernetes-Dokumentation zu Secrets weist deshalb ausdrücklich auf die Grenzen der Standardressource hin.
Verschlüsseln oder auslagern
Zwei Grundmuster sind in GitOps üblich. Beim ersten liegen verschlüsselte Secret-Dateien im Repository und werden erst im Zielsystem entschlüsselt. Beim zweiten enthält Git nur eine Referenz auf einen externen Secret-Speicher. Die Wahl hängt davon ab, welche Rollen Repository, CI-System, GitOps-Operator und Cluster kennen dürfen. Die Verschlüsselung allein beseitigt keine Berechtigungsprobleme, wenn Schlüssel und verschlüsselte Daten im selben Prozess frei zugänglich sind.
SOPS ist ein verbreitetes Werkzeug für die dateibasierte Verschlüsselung. Das offizielle SOPS-Repository beschreibt die Unterstützung für KMS-Dienste, PGP und weitere Schlüsselquellen. In Kubernetes-Umgebungen können Operatoren wie Sealed Secrets verschlüsselte Werte erst im Cluster in eine Secret-Ressource umwandeln.
Argo CD und Flux brauchen klare Zuständigkeiten
Argo CD kann externe Werkzeuge und Plugins in den Auslieferungsprozess einbinden. Die Argo-CD-Dokumentation zur Secret-Verwaltung nennt unter anderem externe Secret-Systeme und Entschlüsselungs-Workflows. Flux arbeitet ebenfalls mit Referenzen und Integrationen, die Secret-Daten vom normalen Konfigurationsbestand trennen können. Entscheidend ist, an welcher Stelle Klartext entsteht und welche Identität diesen Schritt ausführen darf.
Vault für getrennte Zugriffspfade
Wenn weder Entwickler noch GitOps-Operator die vollständigen Zugangsdaten kennen sollen, bietet sich ein zentraler Secret-Speicher an. HashiCorp Vault stellt dafür Richtlinien, kurzlebige Zugangsdaten und Auditierbarkeit bereit. Der zusätzliche Betriebsaufwand lohnt sich vor allem bei Teams, die viele Umgebungen, externe Dienste oder regelmäßig rotierende Schlüssel verwalten.
Rotation und Prüfung gehören zum Workflow
Ein Secret-Konzept ist erst belastbar, wenn Rotation, Widerruf und Notfallzugriff dokumentiert sind. Repository-Scans sollten Commits und Pull Requests auf versehentlich veröffentlichte Schlüssel prüfen. Bei einem Fund reicht es nicht, die Datei zu entfernen: Der Schlüssel muss beim Anbieter widerrufen und neu ausgestellt werden. Für Build- und Testsysteme sollten zudem getrennte Identitäten und möglichst kurze Laufzeiten verwendet werden.