External Secrets Operator vs. Sealed Secrets: Kubernetes Secrets Management im Vergleich 2026

Kubernetes Secrets sind standardmäßig nur base64-kodiert — nicht verschlüsselt. Das stellt Teams vor die Frage: Wie verwaltet man Secrets sicher in GitOps-Workflows? Zwei Lösungen dominieren 2026 den Markt: External Secrets Operator (ESO) und Sealed Secrets von Bitnami (jetzt CNCF). Dieser Vergleich erklärt, wann welche Lösung besser passt.

Das Problem: Kubernetes Secrets sind nicht GitOps-fähig

Ein Standard-Kubernetes Secret enthält nur base64-kodierte Werte — das ist keine Verschlüsselung:

echo -n "mein-passwort" | base64
# bWVpbi1wYXNzd29ydA==  ← trivial dekodierbar

Solche Secrets dürfen nie in Git eingecheckt werden. Aber GitOps erfordert, dass der gesamte Cluster-Zustand im Git-Repository liegt. Wie löst man diesen Widerspruch?

Lösung 1: Sealed Secrets

Sealed Secrets (Bitnami, CNCF Sandbox) löst das Problem durch asymmetrische Verschlüsselung. Ein SealedSecret ist ein Kubernetes Custom Resource, das verschlüsselte Daten enthält — sicher zum Einchecken in Git.

# SealedSecret (sicher in Git einchecken)
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  encryptedData:
    DB_PASSWORD: AgA7kXmR2Bh... # RSA-verschlüsselt, nur Cluster-Controller kann entschlüsseln
    DB_USER: AgB3nPqW1Cm...

Der Sealed Secrets Controller im Cluster hält den privaten Schlüssel und entschlüsselt SealedSecrets zu regulären Kubernetes Secrets.

# Secret versiegeln mit kubeseal
kubectl create secret generic database-credentials   --from-literal=DB_PASSWORD=super-secret   --from-literal=DB_USER=postgres   --dry-run=client -o yaml |   kubeseal --format yaml > database-credentials-sealed.yaml

# Resultat in Git einchecken
git add database-credentials-sealed.yaml
git commit -m "feat: add sealed database credentials"

Sealed Secrets: Stärken und Schwächen

Stärken:

  • Einfaches Konzept: Secrets existieren vollständig in Git
  • Keine externe Abhängigkeit: Alles läuft im Cluster
  • Perfekt für air-gapped Umgebungen
  • Nahtlose ArgoCD/Flux-Integration

Schwächen:

  • Rotation ist aufwändig: Bei Key-Rotation müssen alle SealedSecrets neu verschlüsselt werden
  • Kein zentrales Audit-Log: Wer hat was wann genutzt?
  • Secret-Wert im Git: Auch wenn verschlüsselt, liegt der verschlüsselte Wert im Git-History
  • Cluster-gebunden: SealedSecrets sind an den Cluster-Key gebunden, kein einfaches Multi-Cluster-Sharing

Lösung 2: External Secrets Operator

External Secrets Operator (ESO) verfolgt einen anderen Ansatz: Secrets werden in einem externen Secret Store (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault, 1Password, Doppler, ...) gespeichert. ESO liest sie und erstellt daraus reguläre Kubernetes Secrets.

# ExternalSecret: Definiert, woher das Secret kommt
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: database-credentials  # Name des resultierenden K8s-Secrets
    creationPolicy: Owner
  data:
    - secretKey: DB_PASSWORD
      remoteRef:
        key: production/database
        property: password
    - secretKey: DB_USER
      remoteRef:
        key: production/database
        property: username

Das ExternalSecret-Manifest enthält keine Geheimniswerte — nur Referenzen. Es ist sicher in Git einzuchecken.

# SecretStore: Verbindung zu AWS Secrets Manager
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secrets-manager
  namespace: production
spec:
  provider:
    aws:
      service: SecretsManager
      region: eu-central-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa

External Secrets Operator: Stärken und Schwächen

Stärken:

  • Kein Geheimnis in Git: Nur Referenzen, niemals Werte
  • Zentrales Secret-Management: Ein Vault für alle Cluster und Dienste
  • Automatische Rotation: ESO lädt Secrets regelmäßig neu (refreshInterval)
  • Audit-Trail: Secret-Store-Zugriffe sind zentralisiert auditierbar
  • Multi-Cluster: Dasselbe Secret in mehreren Clustern nutzbar

Schwächen:

  • Externe Abhängigkeit: Cluster ist auf den Secret Store angewiesen (Availability-Risiko)
  • Komplexere Einrichtung: Secret Store muss konfiguriert und gesichert werden
  • Kosten: AWS Secrets Manager, Vault etc. kosten Geld oder erfordern eigene Infrastruktur
  • Kein vollständiger GitOps-State: Secret-Werte leben außerhalb von Git

Direkter Vergleich

Aspekt Sealed Secrets External Secrets Operator
Secret-Wert in Git Verschlüsselt (SealedSecret) Nein (nur Referenzen)
Externe Abhängigkeit Keine Secret Store (Vault, AWS, etc.)
Rotation Aufwändig Automatisch (refreshInterval)
Audit-Trail Keiner Im Secret Store
Multi-Cluster Schwierig Einfach
Air-Gap-fähig Ja Nur mit Self-Hosted Vault
CNCF-Status Sandbox Incubating
Lernkurve Niedrig Mittel–Hoch
Provider-Support — 30+ Provider

Wann Sealed Secrets?

  • Kleine Teams ohne dedizierten Secret Store
  • Air-gapped Umgebungen ohne Internetzugang
  • Einfache GitOps-Setups mit ArgoCD oder Flux
  • Single-Cluster-Szenarien ohne Multi-Cluster-Anforderungen

Wann External Secrets Operator?

  • Enterprise-Umgebungen mit bestehenden Secret Stores (Vault, AWS Secrets Manager)
  • Compliance-Anforderungen mit zentralem Audit-Log
  • Multi-Cluster-Setups mit gemeinsamem Secret Management
  • Dynamische Secrets (z.B. kurzlebige Datenbank-Credentials via Vault)

Kombination möglich

Viele Teams nutzen beide Tools: Sealed Secrets für cluster-interne Secrets (Zertifikate, Bootstrap-Credentials), ESO für Anwendungs-Secrets aus dem zentralen Vault. Das gibt maximale Flexibilität.

Fazit

Sealed Secrets ist die einfachere, elegantere Lösung für Teams, die echtes GitOps ohne externe Abhängigkeiten wollen. Das Konzept ist klar und die Integration in ArgoCD oder Flux funktioniert reibungslos.

External Secrets Operator ist die Enterprise-Lösung für Teams mit bestehenden Secret Stores, Compliance-Anforderungen und Multi-Cluster-Setups. Die automatische Rotation und das zentrale Audit-Log sind in Produktionsumgebungen entscheidende Vorteile.

Wer bei null anfängt: Mit Sealed Secrets starten — und zu ESO wechseln, wenn Skalierungsanforderungen es erfordern.

Weiterführende Artikel

Verwandte Technologien im Techradar