Blog
Kubernetes-Secret-Management in großem Maßstab (I): Von fest codierten Secrets zu versiegelten Secrets
1. Das Problem: Fest codierte Geheimnisse
Das hier beschriebene Problem tritt sehr häufig in Unternehmen auf, die seit langem Code-Repositorys zur Verwaltung ihres Codes nutzen: Es kommt der Zeitpunkt, an dem sie mit sensiblen Daten wie Passwörtern, Zugriffstoken, privaten Schlüsseln usw. umgehen müssen. Das eigentliche Problem besteht darin, wo diese Informationen auf sichere Weise gespeichert werden sollen.
In unserem Fall stellten wir fest, dass die frühen Phasen des Projekts zu einer Zeit stattfanden, als es noch keine unternehmensweiten Vorgaben zum Umgang mit dieser Art von Daten gab, was zudem damit einherging, dass wir eine Version von GitHub Enterprise Server nutzten, die auf unseren eigenen Servern gehostet wurde. Dies hatte dazu geführt, dass jedes Team diese geheimen Daten direkt in seinen GitHub-Repositorys speicherte, wo sie von jedem gelesen werden konnten, der über Lesezugriff auf das Repository verfügte.
Da die Anzahl der Repositorien zunahm und damit auch die Zahl der Personen, die Zugriff darauf hatten, entwickelte sich daraus ein echtes Sicherheitsproblem, da wir nicht kontrollieren konnten, wer diese sensiblen Informationen einsehen konnte. Und vergessen wir nicht, dass es sich obendrein um einen forschungsorientierten Bereich handelt, was bedeutet, dass die offengelegten Informationen aus unternehmerischer Sicht ein Risiko darstellten.
Hinzu kommt der „Nachteil“, dass das DevOps-Entwicklerteam die GITOPS-Philosophie übernommen hat, wonach die Informationen in Repositorys und externen Tools die einzige verlässliche Quelle für bereitgestellte Anwendungen darstellen. Da unsere Anwendungsbereitstellungsplattform aus Azure-AKS-Clustern besteht, bedeutete dies, dass die Erstellung von Secrets direkt innerhalb der Cluster kein idealer Ansatz war, sofern eine Alternative bestand, da dies zu Datenverlusten führen könnte, wenn Tools wie ArgoCD manuell erstellte Komponenten als nicht mit der einzigen Quelle der Wahrheit synchronisiert interpretierten.
Wir standen vor zwei Problemen, die es zu lösen galt:
- Wir wollten, dass unsere Geheimnisse an einem Ort außerhalb der Cluster gespeichert werden und dass ihre Werte innerhalb der Produktionsumgebung auf irgendeine Weise synchronisiert werden.
- Die geheimen Werte durften der breiten Öffentlichkeit, die zwar Lesezugriff auf die Code-Repositorys hatte, nicht zugänglich sein; das Anzeigen und Ändern dieser Werte musste auf eine ausgewählte Gruppe von Personen mit höheren Berechtigungen beschränkt bleiben.
2. Erste Option: „Sealed Secrets“
Die gewählte Option war der Einsatz des SealedSecrets-Operators. SealedSecrets ist ein Tool, das darauf ausgelegt ist, Geheimnisse so zu verschleiern, dass sie nur an dem Zielort entschlüsselt werden können, an dem sie versiegelt wurden. Beispielsweise ist das Tool in einem Kubernetes-Cluster installiert. Mithilfe eines Clients (kubeseal) können wir den verschleierten Wert für ein bestimmtes Geheimnis speziell für diesen Cluster und sogar für einen bestimmten Namespace generieren.
Von diesem Zeitpunkt an kann dieser versiegelte Wert unverändert in einem beliebigen Repository gespeichert werden, da der Wert selbst für Dritte keine aussagekräftigen Informationen enthält. Erst wenn dieses „SealedSecret“ im Ziel-Kubernetes-Cluster bereitgestellt wird, entschlüsselt das Tool es erneut und erstellt ein reguläres „Secret“, das von einer in einem Pod ausgeführten Anwendung genutzt werden kann.
3. Unsere erste Verbesserung
Das Verfahren zum Erstellen eines Secrets im Cluster sieht nun wie folgt aus:
- Ein Benutzer mit Zugriffsrechten auf den Cluster verwendet `kubeseal` von einem beliebigen Gerät aus, auf dem dieser Client ausgeführt werden kann, um einen geheimen Wert zu verschlüsseln. Dieses verschlüsselte Geheimnis kann nur mit dem auf dem AKS-Cluster installierten Tool entschlüsselt werden.
- Der verschlüsselte Wert wird in einer Datei innerhalb des GitHub-Repositorys gespeichert. Dieser Wert – entweder direkt in einem Manifest oder über ein Bereitstellungstool wie Helm – wird verwendet, um ein „SealedSecret“-Objekt im AKS-Cluster zu erstellen.
- Der Controller des Tools erkennt das „SealedSecret“ im Cluster und entschlüsselt es mithilfe der eigenen installierten Zertifikate, um ein Kubernetes-Secret-Objekt zu erstellen.
- Der Wert steht nun den „Pods“ der Anwendung zur Verfügung, die ihn je nach Bedarf für die entsprechenden Konfigurationen nutzen werden.
Nun haben wir die beiden Probleme behoben, die zuvor aufgetreten waren:
- Wir können unsere Konfiguration in Git speichern, ohne die tatsächlichen geheimen Werte offenzulegen, und die Informationen werden im Rahmen eines automatisierten Prozesses mit dem Cluster synchronisiert.
- Nur Personen mit entsprechenden Berechtigungen können „kubeseal“, das mit dem AKS-Cluster verbunden ist, verwenden, um Werte zu verschlüsseln, die nach der Bereitstellung wieder entschlüsselt werden.
4. Doch nun haben wir andere Probleme
Was anfangs eine große Hilfe war, führte im weiteren Verlauf zu anderen Problemen, die alle hauptsächlich mit der geheimen Erneuerung und Rotation zusammenhingen:
- Der Kubeseal-Client funktioniert unter Windows nicht einwandfrei und stand in starkem Konflikt mit unseren Sicherheitskontrollen. In Verbindung mit der Notwendigkeit, direkten Zugriff auf den Cluster zu haben, führte dies zu einem deutlichen Engpass bei der Rotation oder Erneuerung von Geheimnissen, da nur Personen mit hohen Berechtigungen die Änderungen vornehmen konnten.
- Als der Zugriff auf die Cluster weiter eingeschränkt wurde, sodass er nur noch aus dem internen Netzwerk des Unternehmens möglich war, verringerte sich die Zahl der Personen, die Geheimnisse aktualisieren konnten, noch weiter. In einigen Fällen wurden sogar Ad-hoc-Tools entwickelt, um die versiegelten Werte aus Pods zu generieren, die innerhalb des Clusters selbst eingebunden waren; der Zugriff blieb jedoch aufwendig und stark eingeschränkt.
- Code-Review-Bots meldeten „SealedSecrets“ häufig als offengelegte Geheimnisse in GitHub-Repositorys, was im Widerspruch zu den bestehenden Sicherheitsrichtlinien stand.
5. Wie geht es nun weiter?
Nachdem wir nun das eigentliche Problem gelöst haben – nämlich die Sicherheitslücke, die dadurch entstand, dass Geheimnisse im Klartext direkt im Repository gespeichert wurden –, müssen wir die Art und Weise, wie wir unsere Geheimnisse synchronisieren, überdenken. Die mit dem neuen Ansatz verbundenen Probleme haben zwar keine Auswirkungen auf die Sicherheit, führen jedoch zu einer erheblichen Komplexität bei der Pflege und Rotation von Geheimnissen.
Da nun keine Dringlichkeit mehr besteht, überprüfen wir unseren Ansatz erneut und müssen eine Lösung finden, die:
- Ermöglicht eine möglichst zentralisierte Verwaltung von Geheimnissen mithilfe von Tools, die kein bestimmtes Betriebssystem erfordern.
- Die Verwaltung vertraulicher Daten darf ausschließlich von Mitarbeitern mit höheren Zugriffsrechten durchgeführt werden.
- Ermöglicht eine möglichst umfassende Automatisierung der Prozesse zur Erstellung und Rotation von Geheimnissen in der Produktionsumgebung.
- Es werden keine vertraulichen Informationen – auch nicht in verschlüsselter Form – in den Repositories offengelegt, um die Validierung des veröffentlichten Codes zu erleichtern.
Fortsetzung folgt…
Verfasst von
Contact