Geheimniskrämerei
Kubernetes-Secrets verschlüsselt in Git speichern
So wirklich verdient haben Kubernetes-Secrets ihren Namen nicht: Ihr Inhalt ist Base64-kodiert, liegt aber als Klartext im Cluster und in YAML-Dateien. Das ist frustrierend für Fans von GitOps, denn sie können Secrets nicht einfach in Git-Repositories ablegen, ohne ihre Geheimnisse allen zugänglich zu machen. Das Werkzeug Sealed Secrets und asynchrone Verschlüsselung schaffen Abhilfe.
Es gibt viele gute Gründe, die YAML-Definitionen für Kubernetes-Ressourcen nicht auf den Rechnern von Admins herumliegen zu lassen und per Hand mit dem Befehl kubectl apply in ein oder mehrere Cluster zu transportieren. Über kurz oder lang kommt es zu Abweichungen zwischen dem Inhalt der lokalen YAML-Dateien und den Clustern. Stattdessen spricht viel dafür, die Definitionen mit einem Paketmanager wie Helm [1] zu verpacken und einem Continuous-Deployment-Werkzeug wie Argo CD die Aufgabe zu überlassen, diese Pakete im Cluster aktuell zu halten. Den sogenannten GitOps-Ansatz haben wir bereits ausführlich beschrieben [2].
Alle Kubernetes-Objekte, die in Ihrem Cluster laufen sollen, liegen bei dieser Strategie in Git-Repositories und Änderungen können Sie und Ihre Kollegen elegant nachvollziehen. Alle Objekte? Nein, ein Typ bleibt außen vor: Kubernetes-Secrets sollten Sie definitiv nicht als YAML in ein Git-Repository legen, weil sie sonst nicht mehr wirklich geheim wären. Zu solchen Secrets gehören API-Schlüssel für externe Anwendungen, Datenbankkennwörter oder Admin-Zugangsdaten.