GitOps und Kubernetes – Sicherer Umgang mit Secrets

Gerade in lange etablierten Unternehmen kann es sein, dass sich ein Umgang mit Secrets etabliert hat, der zwar bequem, aber nicht notwendigerweise die sicherste Lösung ist. Ein Beispiel dafür ist die Speicherung von Secrets direkt im CI-Server. Die Nutzung eines Key Management Systems (KMS) zur Speicherung von Secrets ist eine sicherere Lösung, verursacht aber initial erstmal Aufwand bei der Umstellung. Deswegen werden KMS aktuell im Umfeld von Kubernetes noch nicht immer benutzt. GitOps mit seinem deklarativen Ansatz erzwingt ein Umdenken im Umgang mit Secrets.

Kubernetes und Secrets

Mit Kubernetes werden Secrets grundsätzlich unverschlüsselt in dem API Server zugrundeliegenden Datenspeicher (etcd) gespeichert. Das bedeutet, dass jeder, der Zugriff auf etcd hat, auch Secrets erfahren oder verändern kann. Deswegen sollten mindestens diese Maßnahmen getroffen werden:

• Aktivierung der Verschlüsselung von Secrets mittels Encryption at Rest,
• Implementierung eines least-privilege Ansatzes für Secrets durch Konfiguration von RBAC Regeln,
• Zugriff auf Secrets auf bestimmte Container beschränken, indem Secrets nur in Containern gemountet werden, in denen sie auch benötigt werden,
• einen Weg finden, wie Secrets in den Cluster kommen (beispielsweise mit dem CI-Server) und
• die Benutzung eines externen Anbieters zur Speicherung von Secrets (KMS) evaluiert werden.

Das zeigt, dass auch schon ohne GitOps der sichere und angemessene Umgang mit Secrets in Kubernetes nicht trivial ist. Durch den deklarativen Ansatz von GitOps wird das noch verstärkt, da auch Secrets außerhalb des Clusters, nämlich im Sourcecode Management gespeichert oder zumindest referenziert werden müssen. Dadurch wird ein sicherer Umgang mit Secrets erzwungen. Die meisten der im Folgenden beschriebenen Lösungen sind nicht nur ausschließlich mit GitOps anwendbar, sondern sind grundsätzlich beim Einsatz von Kubernetes anwendbar.

GitOps erzwingt anderen Umgang mit Secrets

Mit GitOps wird der Zustand eines Projekts deklarativ in der Sourcecode-Verwaltung beschrieben und die Deployment-Umgebung synchronisiert sich kontinuierlich mit Git. Der CI Server wird nur noch für den Build benutzt, das Deployment übernimmt der GitOps Operator. Dieses Vorgehen erlaubt es, die Automatisierung auf ein neues Level zu heben, führt aber auch dazu, dass ein neuer Umgang mit Secrets gefunden werden muss. Durch das Speichern des gesamten Zustands in Git muss unweigerlich ein Weg gefunden werden, Secrets auf Sichere Art in Git abzulegen, denn direkt und unverschlüsselt im Git gespeichert bietet eine große Angriffsfläche. Für die Sichere Handhabung von Secrets gibt es grundsätzlich zwei Ansätze:

• Verschlüsselte Speicherung der Secrets in Git
• Speicherung der Secrets in einem Key Management Systems (KMS) und Referenzierung im Git.

Verschlüsselte Speicherung in Git

Sealed Secrets (Operator)

Eine Option, die einfach mit GitOps zusammen funktioniert, ist der Operator Sealed Secrets von Bitnami. Mit ihm verschlüsselte Secrets können nur von innerhalb des Clusters laufenden Operator entschlüsselt werden, nicht einmal vom ursprünglichen Autor. Für die Verschlüsselung existiert ein CLI (und ein Web-UI eines Drittanbieters), das eine Verbindung zum Cluster benötigt. Nachteil hieran ist, dass das Schlüsselmaterial im Cluster gespeichert ist, die Secrets an den Cluster gebunden sind und man sich um Backups und den Betrieb kümmern muss.

Benutzung von Key Management System (KMS)

Bei der Nutzung eines KMS ist der erste Schritt ein passendes Tool auszuwählen. Da die großen Betreiber von public Clouds wie Google, Microsoft, Amazon, usw. in der Regel ein KMS anbieten, dass einfach genutzt werden kann und sich Hashicorp Vault als Lösung für on-premises betriebene Cluster hat etabliert hat, ist der erste Schritt schnell abgeschlossen. Der zweite Schritt ist dann die Integration des KMS in den Cluster. Dafür gibt es mehrere Möglichkeiten:

1. Betreiben eines speziellen Operators
2. Mounten von Secrets in das File-System mittels Container Storage Interface (CSI)
3. Einfügen (injecten) eines Side cars in Pods
4. GitOps Operator mit entweder nativen Support für KMS oder via Plugin

External Secrets (Operator)

External Secrets ist ein Operator, der externe KMS wie Hashicorp Vault oder die der großen Cloud Provider integriert. Er liest Secrets aus den externen APIs und injiziert sie in Kubernetes Secrets. Der Operator ist eine Neuimplementierung nach dem Zusammenschluss von ähnlichen Projekten von GoDaddy und ContainerSolutions.

Secrets Store CSI Driver

Das Mounten von Secrets in das Dateisystem von Pods ist ein anderer spannender Weg, da der CSI Driver ein offizieller Teil von Kubernetes ist. Er wird von der Kubernetes Special Interest Group entwickelt und ist damit potentiell sehr langlebig. Der CSI Driver bietet für die gängigen Anbieter Provider, die wiederum von den Anbietern selbst entwickelt werden.

Hashicorp Vault k8s (Sidecar Injector)

Hashicorp Vault k8s ist ein Operator, der über einen mutierenden Webhook Pods verändert, um über Sidecars (zusätzliche Container) eine Verbindung zwischen Vault und Pod herzustellen, um Secrets bereitzustellen. Diese hat den großen Vorteil, dass hier keine Secret-Objekte in Kubernetes erzeugt werden. Nachteil ist, dass dieser Weg nur mit Vault funktioniert.

SOPS

Das schon aus der Zeit vor Kubernetes bekannte Mozilla Secret Ops (SOPS) bietet noch mehr Optionen – zulasten einer aufwendigeren Konfiguration. Hier kann das Schlüsselmaterial aus den Key-Management-Systemen (KMS) der großen Cloud-Anbieter, einem eigenen HashiCorp Vault oder aus selbst verwalteten PGP-Schlüsseln kommen. Da es nicht Kubernetes-nativ ist, enthält SOPS keinen Operator, es gibt aber verschiedene Varianten, es mit GitOps zu verwenden.

• Flux v2 bietet native Unterstützung.
• ArgoCD unterstützt SOPS mit dem vault Plugin
• Außerdem gibt es das Plugin helm secrets, das sich mit manueller Konfiguration auch in ArgoCD verwenden lässt.
• Auch steht ein Operator sops-secrets von einem Drittanbieter bereit.

Beispiel: Hashicorp Vault mit External Secrets Operator im GitOps Playground

Das Management von Secrets mit Hashicorp Vault und der Synchronisierung in den Cluster mittels External Secrets Operator kannst du dir im GitOps Playground anschauen und ausprobieren. Der GitOps Playground ist ein Open-Source-Projekt zum Ausprobieren von GitOps inkl. einer Beispiel-Anwendung. Zum GitOps Playground auf GitHub

Fazit

Der deklarative Ansatz von GitOps führt dazu, dass der Umgang mit Secrets neu gedacht werden muss. Fluch und Segen ist, dass es viele Möglichkeiten gibt die einen sicheren Umgang mit Secrets ermöglichen. Dank der unterschiedlichen Ansätze gibt es passende Operatoren für unterschiedliche Anforderungen. Wir würden uns freuen wenn du Fragen, Feedback oder Vorschläge für andere Operatoren, zum GitOps Playground oder GitOps allgemein in unserer GitOps Community postest.