Vault, External Secrets & CSI: Der ultimative Guide zum Secret Management in K8s

„Base64 ist keine Verschlüsselung." Dieser Satz sollte über jedem Platform-Engineering-Team hängen. Standardmäßige Kubernetes-Secrets werden lediglich kodiert, nicht verschlüsselt. Wer Zugriff auf die API oder das etcd-Backend hat, kann Passwörter, API-Keys und Zertifikate im Klartext lesen.

Im Jahr 2026 ist ein professionelles Secret Management die Grundvoraussetzung, um Compliance -Vorgaben zu erfüllen und das Risiko von Datendiebstahl durch „Lateral Movement" im Cluster zu minimieren. Wir schauen uns an, wie Sie sensible Daten sicher verwalten, ohne den Workflow Ihrer Entwickler zu stören.

Das Problem: Secrets in Git (GitOps Dilemma)

Wenn Sie GitOps (z. B. mit ArgoCD) nutzen, stehen Sie vor einem Problem: Sie wollen den gesamten Cluster-Zustand in Git speichern, aber Passwörter dürfen dort niemals landen.

Es gibt drei bewährte Lösungswege, um dieses Problem zu lösen:

1. External Secrets Operator (ESO): Die Brücke zur Cloud

Der External Secrets Operator ist aktuell die beliebteste Lösung im Mittelstand. Er fungiert als Synchronisations-Layer.

• Wie es funktioniert: Die eigentlichen Secrets liegen in einem externen Tresor (AWS Secrets Manager, Azure Key Vault, Google Secret Manager oder HashiCorp Vault).
• Der Vorteil: Entwickler legen im Git nur eine Referenz (ExternalSecret) an. Der Operator holt den Wert sicher aus dem Tresor und erstellt ein lokales K8s-Secret.
• Einsatzgebiet: Ideal, wenn Sie ohnehin schon stark in einem Cloud-Provider verwurzelt sind.

2. HashiCorp Vault: Der Goldstandard

Vault ist die mächtigste Lösung auf dem Markt. Sie ist plattformunabhängig und bietet Features, die weit über das einfache Speichern hinausgehen.

• Dynamic Secrets: Vault kann Passwörter „on the fly" generieren, die nach kurzer Zeit automatisch ablaufen. So hat eine Applikation niemals ein statisches Datenbank-Passwort.
• Injection via Sidecar: Über einen Agent-Injector werden Secrets direkt in das Dateisystem des Pods (Shared Memory) injiziert, ohne jemals als Kubernetes-Secret-Objekt aufzutauchen.
• Einsatzgebiet: Komplexe Umgebungen mit hohen Sicherheitsanforderungen (Finanzsektor, KRITIS).

3. Secrets Store CSI Driver: Direkter Mount

Dieser Ansatz nutzt das Container Storage Interface, um Secrets wie ein Laufwerk einzubinden.

• Wie es funktioniert: Das Secret existiert nicht in der Kubernetes-Datenbank. Es wird beim Start des Pods direkt vom Provider (z. B. Azure Key Vault) in ein Volume gemountet.
• Der Vorteil: Da kein K8s-Secret-Objekt erstellt wird, können die Daten auch nicht versehentlich per kubectl get secrets ausgespäht werden.

Vergleich der Strategien

Warum Secret Management über Ihre Security entscheidet

Ein modernes Secret Management bietet zwei entscheidende Vorteile für den Mittelstand:

1. Zentralisierung: Wenn ein Mitarbeiter das Unternehmen verlässt oder ein API-Key kompromittiert wird, müssen Sie den Key nur an einer Stelle (im Vault) rotieren. Alle betroffenen Apps im Cluster erhalten automatisch den neuen Wert.
2. Audit-Log: Sie sehen genau, welcher Pod und welcher Service wann auf welches Secret zugegriffen hat. Das ist Gold wert bei forensischen Untersuchungen.

Fazit: Weg mit den Klartext-Secrets

Die Einführung von Tools wie dem External Secrets Operator oder HashiCorp Vault ist ein einmaliger Aufwand, der die Sicherheit Ihrer Plattform auf ein neues Level hebt. Wer 2026 noch Passwörter manuell in YAML-Files kodiert, handelt grob fahrlässig. Die Tools sind reif – nutzen Sie sie.

Technical FAQ: Secret Management

Sollten wir Bitnami Sealed Secrets nutzen? Sealed Secrets sind ein guter Einstieg, da sie verschlüsselte Secrets in Git erlauben. Allerdings bieten sie kein zentrales Management und keine Anbindung an moderne Cloud-Tresore. Im Jahr 2026 empfehlen wir eher den Umstieg auf den External Secrets Operator.

Was passiert, wenn der Vault oder Cloud-Tresor nicht erreichbar ist? Beim ESO bleiben die lokalen K8s-Secrets erhalten, sodass Apps weiterlaufen. Beim CSI-Driver oder Vault-Injection schlägt der Start neuer Pods fehl. Hochverfügbarkeit (HA) des Secret-Stores ist daher essenziell.

Wie sicher ist die Verbindung zwischen K8s und dem Vault? Diese wird über Service-Accounts und IAM-Rollen (IRSA bei AWS, Workload Identity bei Azure/GCP) abgesichert. Es müssen also keine “Master-Passwörter” mehr manuell im Cluster hinterlegt werden.