Diese Seite ist auch verfügbar in:
Passwörter und Tokens sind weit verbreitet, stellen aber auch ein häufiges Risiko dar. Wenn Zugangsdaten offengelegt werden und nie geändert werden, können sie über einen langen Zeitraum missbraucht werden. Aus diesem Grund verlangen viele Unternehmen eine regelmäßige Passwortrotation sowie die Trennung von Entwicklern und Eindringlingen, um sensible Informationen zu verbergen und Redundanzen zu reduzieren, damit das Risiko einer Offenlegung so weit wie möglich begrenzt wird.
Die Herausforderung besteht nicht nur darin, das Passwort selbst zu ändern. Die eigentliche Herausforderung besteht darin, dies zu tun, ohne laufende Anwendungen zu beeinträchtigen. Darauf wird in diesem Blog eingegangen.
1 Zwei Dimensionen der Passwort-Rotation
Im Grunde genommen umfasst die regelmäßige Änderung von Passwörtern zwei verschiedene Dimensionen:
1) Wie das neue Passwort an das Zielsystem übermittelt wird
2) Wie die Anwendung dieses Passwort verwendet
Diese beiden Dimensionen werden oft miteinander vermischt, doch wenn man sie getrennt betrachtet, lassen sich Designentscheidungen besser treffen.
Erste Dimension: Transport
Hier geht es darum, die aktualisierten Anmeldedaten in Ihre Laufzeitumgebung zu übertragen. Ein Beispiel hierfür ist die Bereitstellung eines Datenbankpassworts für eine Spring-Boot-Anwendung, die in Kubernetes ausgeführt wird.
Zweite Dimension: Benutzung
Hier geht es darum, wie Ihre Anwendung die Anmeldedaten liest und verwendet. Zu den gängigen Vorgehensweisen gehören:
- Environment Variablen
- Mounted files (e.g., von Volumes)
- API Aufrufe auf externes System zur Laufzeit
Beide Dimensionen müssen Hand in Hand gehen. Ein leistungsfähiger Bereitstellungsmechanismus nützt nichts, wenn die Anwendung die Anmeldedaten nicht ordnungsgemäß aktualisieren oder neu laden kann.
2 Gängige Passwort-Anbieter
An dieser Stelle sei erwähnt, dass es mehrere weit verbreitete Tools zur Verwaltung und Rotation von Secrets gibt:
- HashiCorp Vault
Eine flexible und beliebte Lösung, die dynamische Geheimnisse und eine fein abgestufte Zugriffskontrolle unterstützt. - CyberArk (including CyberArk Conjur)
Wird häufig in Unternehmensumgebungen mit strengen Governance- und Prüfungsanforderungen eingesetzt. - Cloud Anbieter Lösungen
- Amazon Web Services (z.B., AWS Secrets Manager)
- Microsoft Azure (z.B., Azure Key Vault)
- Google Cloud (z.B., Google Secret Manager)
Diese Anbieter kümmern sich um die sichere Speicherung und die Passwortverwaltung selbst. Die Herausforderung, die mit der Passwortrotation und -bereitstellung einhergeht, wird nicht von Haus aus gelöst, sodass die Passwörter nahtlos genutzt und im Anwendungskontext Ihrer Workload aktualisiert werden können, die in der Cloud oder vor Ort auf Kubernetes ausgeführt wird.
3 Mechanismen für Passwort Überlieferung (1. Dimension)
Um die Anforderung der vorübergehenden Bereitstellung des Passworts zu erfüllen, das von einem der im obigen Abschnitt genannten Tools verwaltet wird, wollen wir das Ganze einmal genauer betrachten.
Bitnamis Sealed Secrets
Mit SealedSecrets verschlüsseln Sie ein normales Kubernetes-Secret mithilfe eines öffentlichen Schlüssels und erstellen so eine „SealedSecret“-Ressource, die in Git committet werden kann, ohne dass sensible Daten offengelegt werden. Innerhalb des Clusters verwendet der SealedSecrets-Controller seinen privaten Schlüssel, um das SealedSecret zu entschlüsseln und das ursprüngliche Secret wiederherzustellen. Dadurch wird sichergestellt, dass nur der Zielcluster die Daten entschlüsseln kann, selbst wenn die verschlüsselte Datei öffentlich zugänglich ist.
- Verschlüsseln Sie geheime Daten und speichern Sie sie sicher in Git
- Entschlüsselung erfolgt ausschließlich innerhalb des Clusters
- Gut geeignet für GitOps-Workflows
- Einschränkung: Nicht ideal für häufige Rotationen ohne Neubereitstellung
External Secrets Operator (ESO)
ESO ruft Geheimnisse aus externen Geheimnisverwaltern, wie im vorherigen Abschnitt erwähnt, in Ihren Cluster ab. Sie definieren eine „ExternalSecret“-Ressource, die angibt, wo sich das Geheimnis extern befindet und wie es einem Kubernetes-Geheimnis zugeordnet werden soll. ESO authentifiziert sich beim externen Anbieter, ruft die Werte des Geheimnisses ab und synchronisiert sie kontinuierlich mit Kubernetes. Dadurch wird die Speicherung sensibler Daten in Git vollständig vermieden, und die Geheimnisse bleiben zentral in speziellen Geheimnisverwaltungssystemen gespeichert.
- Synchronisiert Geheimnisse von externen Anbietern (wie Vault oder Conjur) mit Kubernetes-Secrets
- Lässt sich gut mit vorhandenen Tools kombinieren
- Einschränkung: Basiert weiterhin auf Kubernetes-Secrets, sodass möglicherweise ein Neustart erforderlich ist, damit die Änderungen wirksam werden
CSI Driver (Secrets Store CSI)
Der Secrets Store CSI-Treiber bindet Secrets zur Laufzeit direkt aus externen Anbietern wie Azure Key Vault oder anderen oben genannten Tools in Pods ein. Sie definieren eine SecretProviderClass, die dem Treiber mitteilt, welche Secrets abgerufen und wie sie als Dateien im Dateisystem eines Pods bereitgestellt werden sollen. Beim Start des Pods ruft der Treiber die Secrets über den Anbieter ab und bindet sie ein, ohne sie dauerhaft in Kubernetes zu speichern. Optional können sie in native Kubernetes-Secrets synchronisiert werden, doch im Hauptmodell bleiben die Secrets kurzlebig und extern.
- Bindet Secrets direkt von externen Anbietern in Pods ein
- Muss nicht als Kubernetes Secrets gespeichert werden
- Unterstützt in bestimmten Konfigurationen dynamische Aktualisierungen
- Hauptvorteil: Ermöglicht Aktualisierungen nahezu in Echtzeit, ohne dass Pods neu bereitgestellt werden müssen
4 Mechanismen für die Passwortnutzung (2. Dimension)
Sobald das Passwort bereitgestellt wurde, muss die Anwendung es verarbeiten. Genau hier scheitern viele Konfigurationen.
Environment Variablen
Umgebungsvariablen werden bereitgestellt und in den Kontext der laufenden Anwendung eingebunden, damit sie dort genutzt und angewendet werden können.
- Einfach und weit verbreitet
- Wird in vielen Frameworks wie Spring Boot standardmäßig unterstützt
- Einschränkung: Die Werte werden beim Start festgelegt → erfordert einen Neustart bei der Rotation
Datei mount
„Secret“ wird als Dateimount im Dateisystem bereitgestellt und kann von der Anwendung genutzt werden; dies ist vor allem in containerisierten Umgebungen der Fall, kommt aber auch in älteren Umgebungen vor.
- Secrets werden als Dateien im Container eingebunden
- Anwendungen können Dateien dynamisch erneut lesen (sofern dies ordnungsgemäß implementiert ist)
- Funktioniert gut mit dem CSI-Treiber
- Vorteil: Ermöglicht Aktualisierungen zur Laufzeit ohne Neustart
API-based Methode
Hier ruft die Anwendung Geheimnisse zur Laufzeit direkt über API-Aufrufe von einem externen Geheimnismanager ab, anstatt auf Injektionsmechanismen zurückzugreifen.
Vorteile:
- Ermöglicht dynamische Rotation ohne Neustart
- Detaillierte Zugriffskontrolle und Protokollierung
- Zentralisierte Verwaltung des Lebenszyklus von Geheimnissen
Nachteile:
- Die Implementierung ist im Vergleich zu Umgebungsvariablen oder Dateimounts komplexer
- Verursacht Latenz und externe Abhängigkeiten zur Laufzeit
- Erfordert Anwendungslogik oder Bibliotheken für das Abrufen und Zwischenspeichern
6 Fazit: Was funktioniert tatsächlich am besten?
Hier ein vereinfachter Vergleich:
| Anwendungs-Fall | Beste Kombi | Warum |
|---|---|---|
| Meiste Produktions-Workloads | CSI Driver + Datei Mounts | Dynamische Bereitstellung, vermeidet die Speicherung von Geheimnissen, unterstützt die Rotation |
| Einfache Apps mit geringem Speicherbedarf | ESO + Environment | Einfach zu implementieren, erfordert jedoch bei Änderungen in der Regel einen Neustart |
| GitOps-lastig, aber statische Geheimnisse | Sealed Secrets + Environment Variablen | Git-freundlich, aber ungeeignet für häufige Rotationen |
Bevorzugter Ansatz für die meisten Unternehmensanwendungen:
Die Verwendung eines CSI-Treibers in Verbindung mit Dateimounts ist in der Regel die stabilste Option in Kubernetes-/OpenShift-Umgebungen.
Warum?
- Unterstützt eine Rotation ohne Ausfallzeiten
- Ermöglicht nahtlose Passwortaktualisierungen
- Vermeidet die Speicherung von Geheimnissen in Kubernetes-Objekten
- Lässt sich gut mit Secret-Providern für Unternehmen wie Vault und Conjur kombinieren
Der Schlüssel liegt darin, Bereitstellung und Nutzung richtig aufeinander abzustimmen. Wenn Ihre App Anmeldedaten aus einer eingebundenen Datei neu laden kann und Ihr Bereitstellungsmechanismus diese Datei dynamisch aktualisiert, erhalten Sie eine saubere, zuverlässige Rotationsstrategie.
7 Konkretes Beispiel
Um dies zu veranschaulichen, habe ich ein funktionierendes Beispiel erstellt, das die durchgängige Passwortrotation für eine Spring Boot-Anwendung demonstriert, die auf einem lokalen KIND-Cluster läuft.
Die Konfiguration nutzt HashiCorp Vault als Secret-Provider in Verbindung mit dem Secrets Store CSI-Treiber. Das Ziel ist einfach: Ein Datenbankpasswort soll rotiert werden, und die Anwendung soll es automatisch übernehmen – ohne Neustart und ohne Ausfallzeiten, während k6 die Anwendung einem Lasttest unterzieht.
Die vollständige Implementierung sowie die Einrichtung der Umgebung, einschließlich Manifesten und Quellcode, finden Sie in wenigen Minuten auf GitHub:
Wie funktioniert es?
Wenn man es einmal aufschlüsselt, ist der Ablauf ganz einfach:
- Ein Trigger für die externe Rotation aktualisiert das Passwort in Vault und leert die MySQL-Anmeldedaten mithilfe von RETAIN
- Der CSI-Treiber ruft das aktualisierte Geheimnis ab und aktualisiert das im Pod eingebundene Volume
- Die Spring-Boot-Anwendung erkennt die Änderung und lädt die Konfiguration neu
- Die Datenquelle aktualisiert ihren Verbindungspool unter Verwendung des neuen Passworts
Der entscheidende Teil liegt auf der Anwendungsseite. Mithilfe von Spring-Funktionen wie @RefreshScope (oder einem Konfigurations-Watcher) kann die App die aktualisierten Anmeldedaten aus der eingebundenen Datei erneut einlesen und die Datenbankverbindungen aktualisieren, ohne neu gestartet zu werden.
Diese Konfiguration läuft vollständig innerhalb eines lokalen KIND-Clusters, einschließlich aller erforderlichen Komponenten. Ein k6-Lasttest sendet kontinuierlich einfache GET-Anfragen an eine Beispiel-Spring-Boot-Anwendung. Während des Tests aktualisiert ein externer Rotationstrigger (implementiert als Bash-Skript) …
Diese Konfiguration läuft vollständig innerhalb eines lokalen KIND-Clusters, einschließlich aller erforderlichen Komponenten. Ein k6-Lasttest sendet kontinuierlich einfache GET-Anfragen an eine Beispielanwendung von Spring Boot. Während des Tests aktualisiert ein externer Rotationsauslöser (implementiert als Bash-Skript) das Passwort.
In den Ergebnissen ist im Moment der Passwortrotation ein leichter Leistungsanstieg zu erkennen, was darauf hindeutet, dass die Anwendung die aktualisierten Anmeldedaten verarbeitet. Insgesamt zeigt sich jedoch, dass die Passwortrotation nahtlos abläuft – ohne Ausfallzeiten, Fehler oder HTTP-Antworten, die nicht vom Typ 200 sind.
Warum dieses Beispiel wichtig ist
Diese Konfiguration vereint beide entscheidenden Aspekte der Geheimnismanagement effektiv. Auf der Bereitstellungsseite sorgt HashiCorp Vault in Verbindung mit dem Secrets Store CSI-Treiber dafür, dass aktualisierte Anmeldedaten dynamisch an die Workload weitergegeben werden. Auf der Verbraucherseite ermöglicht der dateibasierte Zugriff in Verbindung mit den Aktualisierungsfunktionen von Spring der Anwendung, Änderungen zur Laufzeit zu übernehmen, ohne dass ein Neustart erforderlich ist.
Das Ergebnis ist ein robuster Mechanismus zur Passwortrotation ohne Ausfallzeiten – etwas, das in Produktionsumgebungen unverzichtbar ist, jedoch häufig falsch oder unvollständig implementiert wird. Dieser Ansatz zeigt, dass mit der richtigen Kombination aus Tools und Anwendungsdesign eine nahtlose Rotation möglich ist.
Für alle, die mit der Konfiguration experimentieren möchten, bietet das Repository alle notwendigen Komponenten, um sie lokal auszuführen und das Rotationsverhalten in der Praxis zu beobachten.
