Kubernetes Secrets Management: External Secrets Operator & Vault

In vielen Kubernetes-Clustern, die wir im Rahmen von Audits sehen, ist das Secrets Management der schwächste Punkt der gesamten Sicherheitsarchitektur. Nicht weil die Teams nachlässig sind — sondern weil Kubernetes Secrets von Haus aus nur Base64-kodiert im etcd gespeichert werden. Wer das nicht adressiert, hat eine offene Flanke, auch wenn Pod Security und RBAC sauber konfiguriert sind.

Dieser Artikel zeigt, welche Ansätze sich in der Praxis bewähren, was die Kompromisse sind und wann welches Tool sinnvoll ist.

Das Grundproblem: Base64 ist keine Verschlüsselung

Ein kubectl get secret my-secret -o yaml gibt den Inhalt im Klartext zurück — für jeden, der die entsprechenden RBAC-Rechte hat. Viele Teams merken das erst, wenn sie anfangen, Audit-Logs auszuwerten oder einen Penetrationstest beauftragen.

Dazu kommt: Secrets landen häufig versehentlich in Git. Wer helm install mit Werten aus einer values.yaml ausführt, die Datenbankpasswörter enthält, hat diese im Repository-History — oft auch noch nach Jahren.

Es gibt drei Antworten auf dieses Problem, die sich in der Praxis etabliert haben:

• Sealed Secrets — verschlüsselte Secrets, die sicher in Git versioniert werden können
• External Secrets Operator (ESO) — Secrets werden aus einem externen Secret Store (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault) in den Cluster synchronisiert
• HashiCorp Vault + Agent/CSI — Vault als zentraler Secret Store, Secrets werden direkt in Pods gemountet oder als Umgebungsvariablen injiziert

Sealed Secrets: Einfach, aber begrenzt

Sealed Secrets von Bitnami ist die pragmatischste Lösung für Teams, die Secrets in GitOps-Workflows versionieren möchten. Ein Controller im Cluster hält den privaten Schlüssel; mit dem zugehörigen Public Key werden Secrets clientseitig verschlüsselt und als SealedSecret-Objekte in Git gespeichert.

Der Vorteil: minimaler operativer Aufwand, keine externe Abhängigkeit, funktioniert gut mit FluxCD und ArgoCD. Der Nachteil: Secret Rotation ist aufwändig. Wer einen Secret rotieren muss, erstellt ein neues SealedSecret, committed es, wartet auf den Sync. Für viele Mittelstandsteams reicht das — bis zum ersten Incident.

External Secrets Operator: Der pragmatische Standard

Der External Secrets Operator ist heute die meistgenutzte Lösung für Produktions-Cluster im DACH-Raum. Er synchronisiert Secrets aus externen Stores in native Kubernetes Secret-Objekte. Das Ergebnis: Applikationen müssen nichts von ESO wissen — sie lesen weiterhin aus env oder Volume Mounts.

Die Konfiguration erfolgt über zwei Custom Resources:

• SecretStore (namespace-scoped) oder ClusterSecretStore (cluster-scoped) — definiert die Verbindung zum Secret Store und die Authentifizierung
• ExternalSecret — definiert, welche Secrets aus dem Store gelesen und wie sie als Kubernetes Secret abgebildet werden

Ein typisches Setup für AWS Secrets Manager sieht so aus:

apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: aws-secretsmanager
spec:
  provider:
    aws:
      service: SecretsManager
      region: eu-central-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa
            namespace: external-secrets
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secretsmanager
    kind: ClusterSecretStore
  target:
    name: database-credentials
    creationPolicy: Owner
  data:
    - secretKey: password
      remoteRef:
        key: prod/myapp/database
        property: password

ESO unterstützt neben AWS auch Azure Key Vault, GCP Secret Manager, HashiCorp Vault, 1Password, Doppler und weitere Provider. Für Unternehmen, die bereits einen Cloud Secret Store nutzen, ist ESO der natürliche nächste Schritt.

HashiCorp Vault: Maximale Kontrolle, maximaler Aufwand

Vault ist die mächtigste Lösung — und die aufwändigste zu betreiben. Neben statischen Secrets unterstützt Vault dynamische Secrets (z. B. temporäre Datenbankzugänge, die nach 1 Stunde ablaufen), PKI-Infrastruktur, Transit Encryption und detailliertes Audit Logging.

Für Kubernetes gibt es zwei Integrationswege:

• Vault Agent Injector: Ein Sidecar-Container wird per Mutating Webhook in den Pod injiziert und schreibt Secrets als Dateien in ein gemeinsames Volume. Vorteil: kein Neustart des Pods bei Secret Rotation. Nachteil: jeder Pod bekommt einen Sidecar — erhöhter Ressourcenverbrauch.
• Vault CSI Provider: Secrets werden über das Secrets Store CSI Driver Interface direkt als Volumes gemountet. Schlanker als der Injector, aber weniger flexibel bei der Transformation.

In der Praxis empfehlen wir Vault für Unternehmen mit strengen Compliance- Anforderungen (z. B. BSI IT-Grundschutz, SOC 2) oder für Setups, in denen dynamische Secrets einen echten Sicherheitsgewinn bringen — etwa bei Datenbankzugängen, die mehrere Teams teilen.

Encryption at Rest: etcd absichern

Unabhängig vom gewählten Secrets-Management-Ansatz sollte Encryption at Rest für etcd aktiviert sein. In managed Kubernetes-Diensten (EKS, AKS, GKE) ist das in der Regel standardmäßig aktiv — aber es lohnt sich, das zu verifizieren.

Für selbstverwaltete Cluster (z. B. auf Hetzner mit kubeadm oder Cluster API) muss EncryptionConfiguration explizit konfiguriert werden:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}

Nach dem Aktivieren müssen bestehende Secrets neu geschrieben werden:kubectl get secrets --all-namespaces -o json | kubectl replace -f -

Secret Rotation: Der oft vergessene Teil

Das Erstellen eines sicheren Secrets ist gelöst. Die eigentliche Herausforderung ist Rotation. Viele Teams rotieren Secrets manuell — wenn überhaupt. Das ist akzeptabel für Low-Risk-Umgebungen, aber nicht für Produktionssysteme mit Kundendaten.

ESO macht Rotation einfacher: Der refreshInterval steuert, wie oft der Operator den externen Store abfragt. Ändert sich der Wert im Store, wird das Kubernetes Secret automatisch aktualisiert. Pods, die Secrets als Umgebungsvariablen einlesen, benötigen dennoch einen Neustart — wer das vermeiden möchte, sollte Secrets als Volume Mounts verwenden, die live aktualisiert werden.

Welche Lösung für welches Szenario?

Eine Entscheidungshilfe für die Praxis:

• Team < 5 Engineers, kein dedizierter Platform Engineer: Sealed Secrets als Start, ESO sobald ein Cloud Secret Store vorhanden ist
• AWS/Azure/GCP-natives Setup: ESO mit dem nativen Secret Store des Cloud-Providers — minimaler Zusatzaufwand, maximale Integration
• Compliance-Anforderungen (BSI, ISO 27001, SOC 2): ESO oder Vault, kombiniert mit Audit Logging und Secret Inventory
• Multi-Cloud oder On-Prem + Cloud: Vault als zentraler Store, ESO als Synchronisierungsschicht in einzelne Cluster

Was wir in Audits häufig sehen

In Kubernetes-Audits treffen wir regelmäßig auf diese Muster:

• Secrets in ConfigMaps statt in Secrets — aus historischen Gründen oder Bequemlichkeit
• Wildcard-RBAC-Regeln (resources: ["*"]), die den Zugriff auf alle Secrets im Namespace erlauben
• Keine Encryption at Rest auf selbstverwalteten Clustern
• Secrets in Helm values.yaml-Dateien, die in Git eingecheckt sind
• Keine Secret-Rotation seit dem initialen Setup — Credentials, die seit Jahren unverändert sind

Keines dieser Probleme ist schwer zu lösen. Aber sie müssen erst sichtbar gemacht werden.

Secrets Management ist kein einmaliges Setup-Thema — es ist ein laufender Betriebsprozess. Wer das strukturiert angehen möchte, ohne internen Aufwand zu unterschätzen, profitiert von einem externen Blick auf den aktuellen Stand.

Mehr erfahren: Kubernetes-Beratung oder direkt einen Audit buchen — wir zeigen, wo Ihr Cluster heute steht.