GitOps-Secrets-Management für produktive Kubernetes-Umgebungen

Kubernetes Security Tooling: Data-Driven Guide to the Open-Source Ecosystem in 2026

Data-driven survey of open-source Kubernetes security tools from a 2,080-repo corpus — scanning, secrets, policy, runtime, and supply chain integrity.

GitOps verspricht eine einzige Quelle der Wahrheit (Single Source of Truth) für die Infrastruktur: die gesamte Konfiguration in Git, automatisch synchronisiert mit der Produktion. Secrets brechen dieses Versprechen. Datenbankpasswörter, API-Token und TLS-Zertifikate können nicht im Klartext in einem Git-Repository gespeichert werden, aber man kann sie auch nicht außerhalb von Git verwalten, ohne die Reproduzierbarkeit und den Audit-Trail zu verlieren, die GitOps bietet.

Dieser Artikel behandelt fünf praxiserprobte Muster für die Verwaltung von Secrets in GitOps-Workflows, sortiert nach Komplexität und Funktionsumfang.

Muster 1: Sealed Secrets (Bitnami)

Sealed Secrets ermöglichen es, Kubernetes Secrets in SealedSecret-Custom-Resources zu verschlüsseln, die sicher in Git gespeichert werden können. Nur der im Cluster laufende Controller kann diese entschlüsseln.

Funktionsweise

1. Installation des Sealed Secrets Controllers im Cluster
2. Verwendung von kubeseal, um ein Secret in ein SealedSecret zu verschlüsseln
3. Commit der SealedSecret-YAML in Git
4. ArgoCD synchronisiert das SealedSecret in den Cluster
5. Der Controller entschlüsselt es in ein reguläres Secret

Anwendung

kubeseal --format yaml < secret.yaml > sealed-secret.yaml

# Encrypt a literal value
echo -n "my-db-password" | kubeseal --raw \
  --name db-password \
  --namespace production \
  --from-file=/dev/stdin

Überlegungen für die Produktion

Muster 2: External Secrets Operator

Der External Secrets Operator synchronisiert Secrets von externen Providern (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault) in Kubernetes Secrets.

Anwendung

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: db-credentials
  data:
    - secretKey: password
      remoteRef:
        key: secret/production/database
        property: password

Muster 3: SOPS mit Age/GPG

SOPS (Secrets OPerationS) ist ein Tool zur Verschlüsselung auf Dateiebene. Sie verschlüsseln einzelne Werte in YAML-Dateien, während die Struktur lesbar bleibt:

apiVersion: v1
kind: Secret
metadata:
  name: api-credentials
type: Opaque
stringData:
  api_key: ENC[AES256_GCM,data:encrypted-base64,iv:...,tag:...]

Sops verschlüsselt spezifische Werte in Ihrem YAML, und ArgoCD-Plugins oder CI-Pipelines entschlüsseln diese während der Synchronisation. So bleibt das vollständige Secret-Manifest in Git, während sensible Werte geschützt werden.

Muster 4: HashiCorp Vault mit ArgoCD

Für Teams, die bereits Vault einsetzen, ersetzt das Vault-Plugin von ArgoCD (argocd-vault-plugin) Vault-Secrets während der Synchronisation:

apiVersion: v1
kind: Secret
metadata:
  name: app-config
  annotations:
    avp.kubernetes.io/path: "secret/data/production/app"
type: Opaque
stringData:
  db_password: <vault:secret/data/production/app#db_password>

Muster 5: CSI Secrets Store Driver

Der CSI Secrets Store Driver mountet Secrets als Volumes – niemals als Kubernetes Secrets. Dies ist das sicherste Muster, da Secrets niemals in etcd gelangen:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: vault-db
spec:
  provider: vault
  parameters:
    vaultAddress: https://vault.example.com
    roleName: app-role
    objects: |
      - objectName: db_password
        secretPath: secret/data/production/database
        secretKey: password

Das richtige Muster wählen

Für die meisten Teams zu Beginn bietet Sealed Secrets die beste Balance aus Sicherheit, Einfachheit und Git-nativem Workflow. Wenn Ihre Infrastruktur skaliert, ist die Ergänzung durch den External Secrets Operator für dynamische Secrets (rotierende Datenbankpasswörter, API-Token mit Ablaufdatum) der natürliche nächste Schritt.

Production-Checkliste

• Verschlüsselte Secrets werden in Pull Requests überprüft
• Die Secret-Rotation ist automatisiert (nicht manuell)
• Backups von Controllern/Operatoren sind getestet
• Der Zugriff auf den Verschlüsselungskey wird auditiert
• Die Cluster-Wiederherstellung umfasst die Wiederherstellung von Secrets
• Secrets sind pro Namespace und Umgebung eingegrenzt
• Synchronisation schlägt fehl, wenn Secrets nicht entschlüsselt werden können (fail secure)