Secrets in Kubernetes sicher verwalten

Ein Datenbankpasswort in einem Helm-Chart, ein API-Token in der CI-Pipeline und ein Cloud-Schlüssel als Umgebungsvariable: So beginnen viele Sicherheitsprobleme in Kubernetes. Secrets in Kubernetes verwalten heißt deshalb nicht, Werte lediglich in ein Kubernetes-Objekt zu schreiben. Es ist eine Betriebsaufgabe, die Zugriffsrechte, Deployment-Prozesse, Rotation, Auditierbarkeit und die Reaktion auf Vorfälle verbindet.

Für mittelständische Unternehmen ist das keine akademische Sicherheitsfrage. Gelangen Zugangsdaten in ein Git-Repository oder erhalten zu viele Workloads Zugriff auf produktive Schlüssel, entstehen konkrete Risiken: unautorisierte Datenzugriffe, blockierte Releases, teure Incident Response und im schlimmsten Fall ein meldepflichtiger Sicherheitsvorfall. Eine tragfähige Lösung muss Teams schneller ausliefern lassen, ohne dabei Sicherheit an manuelle Einzelschritte zu delegieren.

Was Kubernetes Secrets leisten - und was nicht

Ein Kubernetes Secret speichert sensible Konfigurationswerte wie Passwörter, Zertifikate, Tokens oder private Schlüssel. Pods können diese Werte als Datei einbinden oder als Umgebungsvariable erhalten. Das ist praktisch, schafft aber noch keine sichere Geheimnisverwaltung.

Der entscheidende Punkt: Base64 ist keine Verschlüsselung. Ein Standard-Secret ist lediglich kodiert. Wer Zugriff auf die Kubernetes-API, ein Backup oder eine Manifest-Datei mit diesem Inhalt hat, kann den Wert ohne nennenswerten Aufwand auslesen. Auch die Verschlüsselung im etcd-Speicher muss explizit konfiguriert werden. Ohne Encryption at Rest liegen Secrets dort unter Umständen im Klartext vor.

Kubernetes Secrets sind damit ein sinnvoller Übergabemechanismus an Anwendungen, aber selten der richtige alleinige Tresor für langfristige, hochkritische Zugangsdaten. Welche Architektur sinnvoll ist, hängt vom Schutzbedarf, der Cloud-Umgebung, bestehenden Identity-Systemen und der Anzahl der Teams ab. Für einen kleinen, klar abgegrenzten Cluster können sauber verschlüsselte Kubernetes Secrets ausreichen. Bei mehreren Umgebungen, häufigen Rotationen oder regulatorischen Anforderungen ist ein dedizierter Secret Manager meist die belastbarere Wahl.

Secrets in Kubernetes verwalten: die Sicherheitsbasis

Die Grundlage besteht aus wenigen Maßnahmen, die gemeinsam wirken müssen. Einzelne Einstellungen lösen das Problem nicht.

Zunächst sollten Secrets im Cluster verschlüsselt gespeichert werden. Dazu gehört eine Encryption-at-Rest-Konfiguration für die Kubernetes-Control-Plane sowie ein sauber verwalteter Schlüssel für die Verschlüsselung. In Managed-Kubernetes-Angeboten sind Teile davon häufig vorkonfiguriert. Dennoch muss geprüft werden, welcher Schlüssel verwendet wird, wer ihn administrieren darf und ob auch bestehende Secrets nach Aktivierung der Funktion neu verschlüsselt wurden.

Ebenso zentral ist RBAC. Der Zugriff auf Secrets darf nicht pauschal an Entwicklergruppen, CI-Systeme oder Service Accounts vergeben werden. Ein Namespace allein ist keine Sicherheitsgrenze, wenn Rollen zu breit definiert sind. Ein Deployment benötigt typischerweise Zugriff auf genau die Secrets seines Service Accounts - nicht auf alle Secrets eines Namespace und erst recht nicht clusterweit.

Besondere Aufmerksamkeit verdienen Zugriffsrechte wie `list` und `watch`. Sie wirken auf den ersten Blick harmloser als `get`, können aber Metadaten und in manchen Konstellationen mehr Informationen preisgeben, als für den Betrieb nötig ist. Rechte sollten auf konkrete Ressourcen, Namespaces und Workloads begrenzt sein. Regelmäßige Prüfungen verhindern, dass historische Ausnahmen zu dauerhaften Risiken werden.

Auch Logs und Diagnosewerkzeuge gehören in das Sicherheitsmodell. Debug-Ausgaben, fehlgeschlagene Pipeline-Schritte oder Support-Bundles dürfen keine Secret-Werte enthalten. Das betrifft nicht nur Kubernetes selbst, sondern auch Anwendungen, Sidecars und Observability-Agenten. Ein Token in einem zentralen Log-System ist praktisch genauso problematisch wie ein Token im Repository.

Keine Klartext-Secrets in Git

GitOps schafft reproduzierbare Deployments, aber ein Git-Repository ist kein Geheimnisspeicher. Ein einmal eingechecktes Passwort bleibt häufig in Commits, Forks, lokalen Klonen und Backups erhalten - selbst wenn die Datei später gelöscht wird. Das gilt auch für interne Repositories.

Für deklarative Deployments gibt es zwei etablierte Wege. Der erste Ansatz verschlüsselt Secret-Manifeste vor dem Commit. Werkzeuge wie SOPS oder Sealed Secrets erlauben es, verschlüsselte Werte versionskontrolliert abzulegen, die erst im Zielcluster entschlüsselt werden. Das ist für Teams sinnvoll, die Git als zentrale Quelle für Infrastrukturänderungen nutzen und überschaubare Mengen an Secrets verwalten.

Der zweite Ansatz referenziert externe Secrets aus dem Deployment. Ein Controller liest die Werte zur Laufzeit aus einem dedizierten Secret Manager und erstellt oder aktualisiert die benötigten Kubernetes Secrets. Damit bleiben die eigentlichen Werte außerhalb von Git und häufig auch außerhalb der täglichen Kubernetes-Administration.

Beide Modelle haben ihren Platz. Verschlüsselte Manifeste sind transparent und gut nachvollziehbar, erfordern aber einen verlässlichen Prozess für Schlüsselverwaltung und Rotation. Externe Secret Manager reduzieren die Verbreitung sensibler Werte und unterstützen dynamische Credentials, bringen jedoch eine zusätzliche Abhängigkeit in die Plattform. Entscheidend ist, dass der gewählte Weg automatisiert, dokumentiert und im Störungsfall beherrschbar bleibt.

Identitäten statt langlebiger Zugangsdaten

Der stärkste Hebel liegt oft nicht in der besseren Ablage eines Passworts, sondern darin, Passwörter zu vermeiden. Anwendungen, die auf Cloud-Ressourcen zugreifen, sollten nach Möglichkeit über Workload Identities authentifiziert werden. Dabei erhält ein Kubernetes Service Account eine klar definierte Cloud-Identität. Die Anwendung kann beispielsweise auf Object Storage, Messaging oder einen Datenbankdienst zugreifen, ohne einen langlebigen Cloud-Schlüssel im Container zu führen.

Das reduziert die Anzahl kritischer Secrets deutlich. Außerdem lassen sich Berechtigungen präziser an Workloads binden und zentral widerrufen. Für produktive Plattformen ist das meist sicherer und betrieblich einfacher als ein geteilter API-Key, der über Jahre unverändert in mehreren Deployments liegt.

Bei Datenbanken ist die Abwägung differenzierter. Nicht jeder Dienst unterstützt kurzlebige oder identitätsbasierte Zugangsdaten. Wo dynamische Datenbank-Credentials möglich sind, sollten sie bevorzugt werden. Andernfalls braucht es eine nachvollziehbare Rotation, bei der Anwendung und Datenbank kontrolliert auf neue Werte wechseln können. Ein Passwort alle 90 Tage manuell zu tauschen klingt nach Compliance, erzeugt aber Ausfälle, wenn die Umstellung nicht automatisiert ist.

Rotation muss ein geplanter Betriebsprozess sein

Ein Secret zu rotieren ist mehr als einen Wert im Secret Manager zu ändern. Anwendungen lesen Umgebungsvariablen nur beim Start ein. Wird ein Secret auf diesem Weg bereitgestellt, benötigt der Pod in der Regel einen Neustart, damit der neue Wert greift. Als Datei gemountete Secrets können aktualisiert werden, doch auch dann muss die Anwendung Änderungen erkennen und ihre Verbindung sauber neu aufbauen können.

Für geschäftskritische Systeme sollte die Rotation deshalb getestet werden wie ein Deployment. Dazu gehören ein definierter Verantwortlicher, ein automatisierter Ablauf, Monitoring auf Authentifizierungsfehler und ein Rückfallplan. Bei Datenbanken kann eine Übergangsphase mit zwei gültigen Credentials nötig sein: Das neue Passwort wird ausgerollt, die Anwendung wechselt, danach wird das alte Passwort deaktiviert.

Zertifikate verdienen eine eigene Betrachtung. Ihre Laufzeiten und Erneuerungen müssen überwacht werden, weil ein abgelaufenes Zertifikat häufig erst dann auffällt, wenn eine Verbindung fehlschlägt. Automatisierte Ausstellung und Erneuerung senken dieses Risiko erheblich, ersetzen aber nicht die Überwachung des tatsächlichen Zustands.

CI/CD-Pipelines als Teil der Angriffsfläche

Die Pipeline erhält oft weitreichendere Rechte als ein einzelner Entwickler. Sie baut Images, deployed in Cluster und greift auf Artefakte oder Cloud-Ressourcen zu. Ein kompromittierter Pipeline-Token kann daher einen großen Teil der Plattform gefährden.

Die Pipeline sollte kurzlebige Identitäten nutzen, nicht mit dauerhaft hinterlegten Cluster-Admin-Zugangsdaten arbeiten und nur in die vorgesehenen Umgebungen deployen können. Produktionsfreigaben können zusätzliche Kontrollen benötigen, doch manuelle Copy-and-Paste-Prozesse sind keine Sicherheitsarchitektur. Besser sind nachvollziehbare Freigaben im Deployment-Workflow und getrennte Berechtigungen für Build, Test und Produktion.

Auch Container-Images dürfen keine Secrets enthalten. Das klingt selbstverständlich, passiert aber über Build-Argumente, Konfigurationsdateien und mehrstufige Builds regelmäßig. Ein Image-Scan hilft, ersetzt aber keine klare Regel: Sensible Werte werden zur Laufzeit injiziert und nie in Images, Artefakten oder Testdaten abgelegt.

Prüfen, üben, nachsteuern

Eine funktionierende Secret-Strategie ist messbar. Teams sollten regelmäßig prüfen, welche Secrets existieren, wer sie lesen darf, wann sie zuletzt rotiert wurden und ob ungenutzte Werte entfernt werden können. Audit-Logs der Kubernetes-API und des Secret Managers machen Zugriffe nachvollziehbar. Diese Daten sind besonders wertvoll, wenn ein Mitarbeiter ausscheidet, ein Token versehentlich offengelegt wurde oder ein Sicherheitsvorfall untersucht wird.

Ein realistisches Incident-Szenario gehört ebenfalls dazu: Wie wird ein kompromittiertes Secret identifiziert, widerrufen, ersetzt und auf betroffene Systeme geprüft? Wer diese Abläufe einmal unter kontrollierten Bedingungen testet, vermeidet hektische Entscheidungen im Ernstfall. devRocks verbindet solche Sicherheitsmechanismen mit CI/CD, Observability und dem laufenden Plattformbetrieb, damit Schutzmaßnahmen Releases nicht ausbremsen.

Gute Secret-Verwaltung zeigt sich nicht daran, dass niemand mehr Passwörter sieht. Sie zeigt sich daran, dass Anwendungen kontrolliert auf genau die Ressourcen zugreifen, die sie benötigen - und dass ein kompromittierter Wert ohne lange Betriebsunterbrechung ersetzt werden kann.