Best Practices für die Verwaltung von Kubernetes-Secrets
16. November 2022
0 Min. LesezeitKubernetes verwendet Secret-Objekte, sogenannte Secrets, um OAuth-Tokens, Secure-Shell-(SSH-)Schlüssel, Passwörter und andere geheime Daten zu speichern. Mit Kubernetes-Secrets können wir vertrauliche Daten von unserem Anwendungscode trennen, indem wir sie separat von Pods erstellen. Diese Trennung sowie eine korrekt konfigurierte rollenbasierte Zugriffskontrolle (RBAC) verringern das Risiko, dass ein Secret bei der Interaktion mit Pods offengelegt und möglicherweise ausgenutzt wird, und erhöhen so die Sicherheit.
Kubernetes-Secrets helfen zwar dabei, eine versehentliche Offenlegung von Daten zu verhindern, schützen die Daten des Clusters jedoch möglicherweise nicht vor böswilligen Cyberangriffen. So kann beispielsweise ein nicht autorisierter Benutzer mit Zugriffsberechtigungen auf unseren etcd-Cluster auf alle unsere Kubernetes-Secrets zugreifen. Deshalb müssen wir Kubernetes-Secrets sorgfältig verwalten, um ihre Sicherheit zu gewährleisten.
In diesem Artikel stellen wir Best Practices für die Verwaltung von Kubernetes-Secrets vor. Weitere Sicherheitsrisiken und Best Practices finden Sie in unserem Artikel zur Kubernetes-Sicherheit.
So funktionieren Kubernetes-Secrets
Mit Kubernetes-Secrets können Benutzer Daten in einem Secret-Objekt speichern, auf das Kubernetes-Clients anschließend zugreifen oder das sie ändern können. Ein Secret ist ein Schlüssel-Wert-Paar, das eine Secret-ID und Authentifizierungsinformationen enthält. Kubelet verwendet die Secret-ID, um die Anmeldedaten zu ermitteln, die einem Anwendungscontainer beim Erstellen eines Pods bereitgestellt werden müssen.
Kubelet wird auf jedem Knoten eines Clusters ausgeführt und verwaltet Pods und deren Container. Auf Secrets können Pods nur zugreifen, wenn sie explizit Teil eines eingebundenen Volumes sind oder wenn kubelet ein Image zur Verwendung in einem Pod abruft.
Der Kubernetes-API-Server speichert Kubernetes-Secrets. Auf sie können nur bestimmte Benutzer mit Berechtigung für den Zugriff auf den Kubernetes-API-Server zugreifen. Der Kubernetes-API-Server ist ein Single Point of Failure für unsere Anwendung. Deshalb müssen wir unsere Daten sicher schützen.
Kubernetes-Secrets:
Bieten eine sichere Möglichkeit, Konfigurationsdaten zwischen einem Controller und seinen Workern auszutauschen, zum Beispiel zwischen einem kubelet und einem Pod
Bieten eine alternative Möglichkeit, sensible Daten im Kubernetes-Cluster zu speichern, etwa Anmeldedaten für den Zugriff auf externe Anwendungen
Bieten eine praktische Möglichkeit, neue Ressourcen in unserem Kubernetes-Cluster zu erstellen, etwa neue Deployments oder Namespaces
Best Practices für Kubernetes-Secrets
Secrets wie Schlüssel, Passwörter, Tokens und andere Konfigurationswerte müssen korrekt gespeichert werden. Wird unser Kubernetes-Cluster kompromittiert, müssen die Secrets weiterhin geschützt sein. Angreifer sollten Secrets nicht ausnutzen können, um sensible Daten zu kompromittieren, ein Botnetz aufzubauen oder Command-and-Control-(C2-)Server zu betreiben.
Mit den folgenden Methoden können wir Kubernetes-Secrets schützen:
Verschlüsselung ruhender Daten aktivieren
RBAC-Regeln konfigurieren
etcd-Daten verschlüsseln
Zur einfachen Verwaltung einen zentralen Secrets-Speicher verwenden
Verschlüsselung ruhender Daten aktivieren
Kubernetes-Secret-Daten werden im Base64-Format kodiert und in etcd als Klartext gespeichert. etcd ist ein Schlüssel-Wert-Speicher, der als Backing Store für den Zustand des Kubernetes-Clusters und dessen Konfigurationsdaten dient. Secrets in etcd als Klartext zu speichern, ist riskant, da Angreifer sie leicht kompromittieren und für den Zugriff auf Systeme verwenden können.
Die etcd-Datenbank ist standardmäßig nicht verschlüsselt. Deshalb müssen wir Secret-Daten im Ruhezustand verschlüsseln, damit die darin enthaltenen sensiblen Informationen nicht in die Hände von Angreifern gelangen. Angreifer mit Zugriff auf das Dateisystem können Secrets aus der Datei auslesen.
Außerdem bietet Kubernetes eine Funktion zur Verschlüsselung ruhender Daten, mit der wir Secrets über die Kubernetes-API verschlüsseln können, bevor sie in etcd gespeichert werden. Zum Schutz ruhender Secrets können wir auch Verschlüsselungsanbieter wie KMSConfiguration, IdentityConfiguration, SecretboxConfiguration und AESConfiguration verwenden.
Ein Kubernetes-Cluster umfasst mehrere Knoten, von denen jeder über eigene Anmeldedaten für Ver- und Entschlüsselungsvorgänge verfügt. Das Objekt EncryptionConfiguration legt das Schlüsselmaterial für Ver- und Entschlüsselungsvorgänge auf Knotenebene fest. Die Konfiguration dieser Verschlüsselungsanbieter befindet sich im Objekt EncryptionConfiguration. Damit können Secrets lokal mit einem lokal verwalteten Schlüssel verschlüsselt werden.
RBAC-Regeln konfigurieren
Kubernetes-Secrets im Ruhezustand zu verschlüsseln, ist nur ein Teil der erforderlichen Maßnahmen, um Secrets zu schützen. Außerdem sollten wir den Zugriff auf Secrets mithilfe von RBAC-Regeln für Kubernetes kontrollieren. Die Sicherheitsrichtlinie zur Autorisierung des Secret-Zugriffs kann aufgaben-, zeit- oder rollenbasiert sein.
Kubernetes-Secrets und RBAC-Regeln ergänzen sich: Einer der Hauptgründe für Kubernetes-Secret-Objekte ist, andere RBAC-Zugriffsrechte zu gewähren als bei einer ConfigMap.
Mit dem Objekt ClusterRoles können wir festlegen, welche Aktionen Benutzer in einem Cluster ausführen dürfen. Eine Rolle definiert, welche Aktionen Benutzer in einem Namespace ausführen dürfen. RBAC beschränkt das Erstellen, Löschen und Ändern von Secrets auf bestimmte Benutzer. So können wir beispielsweise eine Richtlinie festlegen, die Entwicklern untersagt, Secrets für einen bestimmten Namespace, nicht aber für andere, zu erstellen.
Das integrierte RBAC-Framework von Kubernetes ermöglicht es uns, das Prinzip der geringsten Berechtigungen (PoLP) durchzusetzen. Damit beschränken wir den Zugriff von Benutzern oder Programmen auf die Ressourcen und Informationen, die sie für ihre Aufgaben oder den ordnungsgemäßen Betrieb benötigen. So stellen wir sicher, dass nur Konten und Container mit privilegierten Berechtigungen auf Secrets zugreifen können. Kompromittieren Angreifer eine Komponente, verhindert das PoLP, dass sie ihre Berechtigungen ausweiten und weitere Komponenten kompromittieren.
etcd-Daten verschlüsseln
Da für den Zugriff auf Secrets lediglich eine Berechtigung für den etcd-Cluster erforderlich ist, müssen wir sensible Daten sorgfältig schützen. Dazu gehören beispielsweise eine automatische Schlüsselrotation, Einblicke in das Alter von Schlüsseln und Audit-Logs. Am besten machen wir diese Daten in etcd unzugänglich. Der Standard-Speichertreiber für etcd ist lokal, und die Verschlüsselungsschlüssel werden lokal in der Konfigurationsdatei gespeichert. Dadurch sind sie anfällig für Malware und andere böswillige Bedrohungen.
Eine Möglichkeit, die Sicherheit von etcd-Daten zu erhöhen, besteht darin, Secrets vor dem Speichern zu verschlüsseln. Zum Speichern unserer Schlüssel und Secrets sollten wir einen Verschlüsselungsanbieter wie einen Key Management Service (KMS) verwenden. Die meisten verwalteten Kubernetes-Anbieter verschlüsseln den etcd-Secret-Speicher standardmäßig, wenn ein Cluster erstellt wird. Das schützt unsere etcd-Daten zusätzlich.
Eine weitere Sicherheitsmaßnahme besteht darin, den Zugriff auf etcd auf den API-Server zu beschränken. Nur Knoten, die Zugriff benötigen, sollten etcd-Cluster verwenden dürfen. Wir können den Zugriff auf etcd über den Kubernetes-API-Server gewähren und Lese- und Schreibberechtigungen auf bestimmte Benutzer oder Gruppen beschränken.
Zur einfachen Verwaltung einen zentralen Secrets-Speicher verwenden
Kubernetes-Secrets sind für den Betrieb unserer Anwendung entscheidend und können an mehreren Orten gespeichert werden. Je mehr Speicherorte wir für Secrets nutzen, desto schwieriger wird es, sie zu schützen – besonders, wenn wir Secrets in mehreren Clustern verwalten oder private und öffentliche Schlüsselpaare kombinieren. Ohne ein zentrales Secrets-Management-System sind Secrets über verschiedene Speicherorte verstreut. Das vergrößert die Angriffsfläche für nicht autorisierte Benutzer.
Die zentrale Verwaltung von Secrets bietet viele Vorteile, insbesondere wenn sie in mehreren Instanzen verwendet werden. Eine zentrale Verwaltungslösung bietet einen einheitlichen Überblick über die Sicherheitslandschaft von Kubernetes. Wir können Secrets, Zugriffskontrollen und Audits einfach verwalten. Ein zentraler Audit-Trail liefert zudem Einblicke in wichtige Sicherheitsereignisse.
Drittanbieter bieten erweiterte Funktionen für die sichere Verwaltung von Kubernetes-Secrets. Im Folgenden finden Sie einige beliebte Secrets-Management-Dienste von Drittanbietern.
AWS Secrets Manager
AWS Secrets Manager bietet eine sichere und einfache Möglichkeit, Secrets zu speichern und zu rotieren. Über eine einheitliche Verwaltungskonsole können wir alle unsere Amazon Web Services (AWS)-Ressourcen verwalten. Das Tool AWS Secrets Manager ist in Kubernetes integriert und ermöglicht es uns, verschlüsselte Secrets sicher in Kubernetes zu speichern. Anschließend können wir über die Kubernetes-API zur Laufzeit auf diese Secrets zugreifen, ohne uns Gedanken über eine Offenlegung im Code machen zu müssen.
Dieser Secrets-Management-Dienst ermöglicht es, AWS-Anmeldedaten und -Secrets an einem einzigen sicheren Ort abzurufen, anzuzeigen und zu verwalten. Wir können AWS Secrets Manager mit anderen AWS-Diensten wie AWS Identity and Access Management (IAM), AWS Key Management Service (AWS KMS) und AWS Simple Storage Service (S3) verwenden.
Azure Key Vault und Azure Kubernetes Service
Microsoft Azure Key Vault ist ein Secrets-Manager, mit dem Benutzer kryptografische Schlüssel speichern und verwenden können. Wir können Vault-Objekte sichern und gelöschte Objekte wiederherstellen, Secrets protokollieren und überwachen sowie Benutzer mithilfe von Key Vaults authentifizieren.
Außerdem können wir Azure Kubernetes Service (AKS) für die Autorisierung mit Azure RBAC und Kubernetes RBAC verwenden. Mit Azure RBAC können wir den Ressourcenzugriff auch über Rollenzuweisungen steuern. Azure RBAC autorisiert zudem Gruppen und Benutzer, während Kubernetes RBAC Kubernetes-Servicekonten unterstützt.
HashiCorp Vault
HashiCorp Vault ist ein Open-Source-Tool zur Verwaltung von Secrets, mit dem sich Secrets speichern und verwalten sowie sensible Daten schützen lassen. Das Tool verwaltet den Benutzerzugriff auf sensible Daten. So können wir diese rotieren oder den Zugriff darauf widerrufen, wenn eine Sicherheitsbedrohung besteht.
Mit HashiCorp Vault können wir verschiedene Kubernetes-Sicherheitsmaßnahmen umsetzen, darunter Datenverschlüsselung, identitätsbasierten Zugriff und Secrets-Management. HashiCorp Vault verwendet TSL und AES-256-Bit-Verschlüsselung, um Daten während der Übertragung beziehungsweise im Ruhezustand zu schützen.
Fazit
Secrets authentifizieren Benutzer und Dienste und steuern den Zugriff auf Ressourcen und andere Secrets. Mit Kubernetes-Secrets können Benutzer Daten in einem Secret-Objekt speichern, auf das Kubernetes-Clients anschließend zugreifen oder das sie ändern können. Da Secrets sensible Daten wie Tokens, Schlüssel und Passwörter enthalten, müssen wir unbedingt Best Practices befolgen, um sie zu schützen.
Es gibt verschiedene Möglichkeiten, unsere Secrets zu schützen. Zunächst sollten wir die Verschlüsselung ruhender Daten aktivieren. Dadurch wird die Sicherheit unserer Secrets erhöht. Kubernetes-Secret-Objekte im Ruhezustand zu verschlüsseln, ist jedoch nur ein Teil des erforderlichen Schutzes. Außerdem sollten wir den Zugriff auf Secrets mithilfe von RBAC-Regeln kontrollieren. Das integrierte RBAC-Framework von Kubernetes ermöglicht es uns, den Zugriff von Benutzern oder Programmen einzuschränken und nur die benötigten Ressourcen oder Informationen freizugeben. Zusätzlich können wir einen Secrets-Management-Dienst eines Drittanbieters verwenden, wie die zuvor vorgestellten, um unsere Secrets zu schützen.
Für eine ordnungsgemäße Verwaltung von Secrets müssen sowohl Entwickler als auch Kubernetes-Cluster-Administratoren die Sicherheit unserer sensiblen Informationen genau überwachen. Lesen Sie zusätzlich zu den hier beschriebenen Best Practices den Leitfaden von Kubnernetes zur Verwaltung von Secrets, der sich sowohl an Entwickler als auch an Cluster-Administratoren richtet, damit Ihre Secrets sicher geschützt sind.
Der Schutz von Anmeldedaten und anderen Secrets ist nur ein Schritt auf dem Weg zu sichereren Anwendungen: Sie müssen alle Phasen des Softwareentwicklungslebenszyklus absichern. Ermitteln und beheben Sie potenzielle Schwachstellen in Ihrem Code und in den Open-Source-Projekten, die Sie verwenden – mit Snyk Code und Snyk Open Source. Nutzen Sie Snyk Container, um mit einem sichereren Basis-Image zu starten und zusätzliche Schwachstellen zu erkennen, die möglicherweise während des Build-Prozesses entstehen. Überprüfen Sie schließlich mit Snyk IaC, ob der von Ihnen bereitgestellte Code keine Sicherheitslücken enthält.
Verwandte Artikel:
Sichern Sie Ihre Infrastruktur an der Quelle
Snyk automatisiert die IaC-Sicherheit und Compliance in Workflows und erkennt abweichende sowie fehlende Ressourcen.
