Kubernetes-Secrets sind für die Mehrheit der Kubernetes-Nutzer:innen eine Notwendigkeit. Die meisten Anwendungen benötigen Secrets. Ein Kubernetes-Secret speichert sensible Daten wie Kennwörter, OAuth-Tokens und SSH-Schlüssel. Die Sicherung dieser Daten und die Gewährleistung ihrer Integrität sind von entscheidender Bedeutung. In diesem Blogartikel klären wir, wie Admins diese Secrets sicher und zuverlässig verwalten können. Du erfährst, welche Methoden es gibt, um Deine Kubernetes-Secrets in einer Produktionsumgebung sicher zu schützen und wie man externe Secrets mit Kubernetes-Clustern synchronisiert.
Kubernetes-Secrets – Die aktuelle Situation
In der Regel werden standardmäßig mit base64 kodierte Dateien verwendet, was keine sichere Verschlüsselungsmethode ist. Die Secrets liegen zwar nicht im Klartext vor, können jedoch leicht entschlüsselt werden. Jeder der Zugang zu den Dateien hat, hat auch Zugriff auf Secrets wie beispielsweise Repositories. Ein weiteres Problem besteht darin, dass Kubernetes-Secrets standardmäßig unverschlüsselt im k8s-Datenspeicher etcd gespeichert werden. Jeder Anwendende mit Zugriff auf den etcd-Cluster kann auf die Secrets zugreifen. Darüber hinaus können auch Anwender:innen, die einen Pod erstellen können, auf ein Secret zugreifen. Gleiches gilt für Personen mit API-Zugang. Angesichts der Tatsache, dass viele Entwickler:innen und Administrator:innen in einem Kubernetes-Cluster Zugang zur API haben und somit potenziell auf Secrets zugreifen und dies ändern können, stellt dies ein Problem dar.
Sicherung von Secrets
Eine empfehlenswerte Methode zur Sicherung von Secrets in Kubernetes ist die Zugriffskontrolle mittels RBAC (Role-based Access Control). RBAC ist ein Mechanismus, der auf Rollen und Berechtigungen basiert. Mit RBAC kann man genau festlegen, wer auf welche Ressourcen in Kubernetes zugreifen darf und welche Aktionen durchgeführt werden dürfen. So lässt sich sicherzustellen, dass nur autorisierte Benutzer:innen auf Secrets zugreifen können. Durch RBAC kann man eine Least-Privilege-Zugriffskontrolle implementieren, bei der Benutzer:innen nur die minimal erforderlichen Berechtigungen erhalten, um ihre Aufgaben auszuführen. Erfahrungen zeigen, dass aus Gründen der Einfachheit oft jeder beteiligten Person ein generelles Cluster-Admin-Recht zugewiesen wird. Dies geschieht auch, wenn das Admin-Recht vom Anwender:innen eigentlich nicht benötigt wird.
Eine weitere Möglichkeit, Secrets in Kubernetes zu sichern, besteht darin, den Zugriff auf bestimmte Container zu beschränken. Kubernetes unterstützt die Definition von Pod-spezifischen Service Accounts. Diese werden verwendet, um Pods zu authentifizieren und ihnen Zugriff auf andere Ressourcen im Kubernetes-Cluster zu gewähren. Durch die Zuweisung von Service Accounts auf Container-Ebene kann der Zugriff auf Secrets eingeschränkt werden, so dass nur bestimmte Container Zugriff auf bestimmte Secrets erhalten.
Es ist von Bedeutung eine Verschlüsselung bei der Speicherung der Secrets in etcd zu verwenden. Durch die Verschlüsselung bei der Speicherung kann sichergestellt werden, dass Secrets vor unbefugtem Zugriff geschützt sind. Kubernetes bietet eine integrierte Verschlüsselungsfunktion für etcd an, die auf dem Advanced Encryption Standard (AES) basiert.
Zudem kann man einen externen Secret-Speicher verwenden, um Secrets in Kubernetes zu speichern. Ein externer Secret-Speicher kann ein sicherer Speicherort außerhalb des Kubernetes-Clusters sein, der nur über eine sichere Verbindung zugänglich ist. Durch die Verwendung eines externen Secret-Speichers lässt sich sicherstellen, dass Secrets vor potenziellen Bedrohungen wie Malware und Hackerangriffen geschützt sind.
Möglichkeiten zur Verwaltung von Secrets
Bei der Verwaltung von Kubernetes-Secrets kann in zwei generische Möglichkeiten unterschieden werden.
Speichern des verschlüsselten Secrets und die Entschlüsselung mit Sealed Secret in Kubernetes (Kube-seal).
Dies ist noch nicht die perfekte Variante, stellt jedoch im Vergleich zum Speicher des unverschlüsselten Secrets in Git eine deutliche Verbesserung dar. Mozilla SOPS ist ein Open-Source-Tool, das es ermöglicht, Secrets in Git zu verschlüsseln. Es kann verschiedene Arten von Secrets verschlüsseln, einschließlich YAML-, JSON- und INI-Dateien. Mit SOPS können Entwickler:innen das Secret verschlüsseln, bevor es in Git hochgeladen wird, und es automatisch bei der Bereitstellung entschlüsseln lassen. Eine Alternative dazu ist Bitnami Sealed Secrets. Es handelt sich um eine Lösung, die wie Mozilla SOPS auf dem Open-Source-Tool Kube-seal basiert. Es kann auch nahtlos in CI/CD-Pipelines integriert werden, um eine sichere und automatisierte Bereitstellung von Secrets zu gewährleisten. Allerdings muss bei dieser Variante ein weiterer Schlüssel verwendet werden. Dieser wird von Bitnami benötigt, um die Secrets zu entschlüsseln. Auch wenn dies aufwändig erscheint, ist es im Vergleich zur Speicherung als base64 ein deutlicher Gewinn an Sicherheit.
Ausschließlich die Referenz zu dem tatsächlichen Secret wird in Git gespeichert.
Durch das Speichern der Referenz in Git ist diese leicht zu verwalten. Das Secret selbst wird im Kubernetes Cluster erstellt. Die Werte des Secrets werden von einem externen Secret-Speicher bezogen. Für das externe Speichern der Secrets gibt es mehrere Möglichkeiten.
Externe Secrets und Key Management Systeme (KMS)
Verwendest Du Hyperscaler, kannst Du die Vendor-Tools verwenden. Beispiel ist AWS KMS, bei Google Cloud ist es vergleichbar Cloud KMS GKE und bei Azure ist es Azure Key Vault. Eine Alternative zu den Tools der Hyperscaler ist Hashicrop Vault. Die Verwendung von Hashicorp ist on-prem möglich und das Setup ist überschaubar.
Das im KMS System gespeicherte Secret muss nun mit dem Kubernetes Cluster selbst synchronisiert werden. Auch hierfür gibt es verschiedene Tools wie Vault Agent Sidecar injecter, Argocd Vault Plugin, External Secrets Operator oder Secrets Store CSI Driver. Alle dieser Tools funktionieren und haben Vor- und Nachteile. Welche Kombination aus KMS und Synchronisation für Dich vorteilhaft sind, ist von individuellen Faktoren abhängig.
Die Möglichkeiten, Kubernetes-Secret zu verwalten und zu sichern sind vielfältig. Die Tool-Landschaft dafür wächst und ist überwiegend Open Source. Mehr Details zu dieser Übersicht findest Du im Vortrag von unserem SysEleven Kubernetes Cloud Consultant Simon Pearce. Du hast Fragen dazu oder benötigst eine individuelle Beratung, kontaktiere uns jetzt.
