Kubernetes Secrets Management 2026: External Secrets, Vault und Interview-Fragen

Das Kubernetes Secrets Management bleibt eine der kritischsten Sicherheitsherausforderungen in der Container-Orchestrierung. Native Kubernetes Secrets speichern sensible Daten als base64-kodierte Werte, was standardmäßig keine Verschlüsselung im Ruhezustand bietet und Sicherheitsrisiken schafft, die Interviewer bei DevOps-Einstellungsverfahren häufig ansprechen.

Warum native Kubernetes Secrets nicht ausreichen

Die eingebaute Secret-Ressource speichert Daten in etcd mit base64-Kodierung. Diese Kodierung lässt sich mit einem einzigen Befehl umkehren:

# decoding-secret.sh
# Decode any Kubernetes secret value instantly
kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d

Base64 ist keine Verschlüsselung. Jeder mit Cluster-Zugriff kann Secret-Werte lesen. Die Kubernetes-Dokumentation warnt ausdrücklich, dass Secrets "standardmäßig nicht verschlüsselt" sind und empfiehlt die Aktivierung der Verschlüsselung im Ruhezustand.

Drei primäre Einschränkungen betreffen Produktionsumgebungen:

1. Kein Audit-Trail: Native Secrets protokollieren nicht, wer wann auf welchen Wert zugegriffen hat
2. Kein Rotationsmechanismus: Das Ändern eines Secrets erfordert manuellen Eingriff und Pod-Neustarts
3. GitOps-Inkompatibilität: Das Speichern verschlüsselter Secrets in Git offenbart weiterhin das Problem der Schlüsselverwaltung

External Secrets Operator Architektur

Der External Secrets Operator (ESO) verbindet Kubernetes mit externen Secret-Management-Systemen. Als CNCF Sandbox-Projekt 2023 veröffentlicht und Version 0.10 im Jahr 2026 erreichend, unterstützt ESO AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault und 15 weitere Backends.

Die Architektur umfasst drei Custom Resources:

# secret-store.yaml
# ClusterSecretStore defines the connection to Vault
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: "https://vault.internal:8200"
      path: "secret"
      version: "v2"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "external-secrets"
          serviceAccountRef:
            name: "external-secrets"
            namespace: "external-secrets"

Dieser ClusterSecretStore konfiguriert ESO für die Authentifizierung bei Vault mittels Kubernetes-Service-Account-Tokens. Die kubernetes-Authentifizierungsmethode validiert das Service-Account-JWT gegen die TokenReview-API des Clusters.

# external-secret.yaml
# ExternalSecret fetches and syncs the actual secret data
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-secret
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: secret/data/production/database
        property: username
    - secretKey: password
      remoteRef:
        key: secret/data/production/database
        property: password

ESO pollt Vault jede Stunde (refreshInterval: 1h) und aktualisiert das Kubernetes Secret automatisch. Die creationPolicy: Owner stellt sicher, dass das Secret gelöscht wird, wenn das ExternalSecret entfernt wird.

HashiCorp Vault Integrationsmuster

Vault bietet dynamische Secrets, automatische Rotation und umfassende Audit-Protokollierung. Die Kubernetes-Authentifizierungsmethode, dokumentiert in der Vault Kubernetes Auth-Dokumentation, ermöglicht Pods die Authentifizierung ohne Verteilung langlebiger Anmeldedaten.

Das Einrichten der Vault-Authentifizierung erfordert drei Schritte:

# vault-k8s-auth.sh
# Enable Kubernetes auth method in Vault
vault auth enable kubernetes

# Configure Vault to validate tokens against the Kubernetes API
vault write auth/kubernetes/config \
  kubernetes_host="https://kubernetes.default.svc:443" \
  kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

# Create a role that binds service accounts to policies
vault write auth/kubernetes/role/external-secrets \
  bound_service_account_names=external-secrets \
  bound_service_account_namespaces=external-secrets \
  policies=readonly-secrets \
  ttl=1h

Diese Konfiguration bindet den external-secrets Service Account an eine Vault-Policy. Die TTL begrenzt die Token-Gültigkeit, erzwingt Re-Authentifizierung und reduziert den Blast Radius kompromittierter Tokens.

Für Produktionsumgebungen sollte die Policy dem Least-Privilege-Prinzip folgen:

# readonly-secrets.hcl
# Vault policy granting read-only access to specific paths
path "secret/data/production/*" {
  capabilities = ["read"]
}

path "secret/metadata/production/*" {
  capabilities = ["list"]
}

Diese Policy gewährt Lesezugriff nur auf den Produktions-Secrets-Pfad. Teams, die verschiedene Umgebungen verwalten, erhalten separate Policies mit entsprechenden Pfadbeschränkungen.

Secret-Rotation ohne Ausfallzeit

Automatische Rotation verhindert, dass Secrets zu veralteten Angriffsvektoren werden. ESO handhabt die Kubernetes-Seite, aber die Anwendung muss Secrets neu laden ohne Neustart.

Zwei Ansätze existieren für Zero-Downtime-Rotation:

Volume-gemountete Secrets mit File-Watching:

# deployment-volume-secrets.yaml
# Mount secrets as files that update automatically
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  template:
    spec:
      containers:
        - name: api
          image: api:v2.1.0
          volumeMounts:
            - name: secrets
              mountPath: /etc/secrets
              readOnly: true
      volumes:
        - name: secrets
          secret:
            secretName: db-secret

Kubernetes aktualisiert gemountete Secret-Dateien innerhalb der kubelet-Synchronisierungsperiode (Standard 1 Minute). Die Anwendung liest Anmeldedaten aus /etc/secrets/password bei jeder Datenbankverbindung und übernimmt neue Werte ohne Neustart.

Reloader für Umgebungsvariablen-Secrets:

Anwendungen, die Umgebungsvariablen verwenden, erfordern Pod-Neustarts. Stakater Reloader automatisiert dies:

# deployment-with-reloader.yaml
# Annotation triggers rolling restart when secret changes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  annotations:
    reloader.stakater.com/auto: "true"
spec:
  template:
    spec:
      containers:
        - name: api
          envFrom:
            - secretRef:
                name: db-secret

Reloader überwacht Secret-Updates und führt Rolling Restarts durch, wobei die Verfügbarkeit während der Rotation erhalten bleibt.

Interview-Fragen zu Kubernetes Secrets

DevOps-Interviews testen konsequent das Verständnis von Secrets Management. Diese Fragen erscheinen von Junior- bis Senior-Level:

F: Welche Kodierung verwenden Kubernetes Secrets und warum ist dies für die Sicherheit unzureichend?

Secrets verwenden base64-Kodierung, eine umkehrbare Transformation, keine Verschlüsselung. Jeder Benutzer mit get-Berechtigung für Secrets kann Werte dekodieren. Sicherheit erfordert Verschlüsselung im Ruhezustand (Aktivierung der etcd-Verschlüsselung) und Einschränkung der RBAC-Berechtigungen. Für tiefere Kubernetes-Konzepte die Kubernetes-Interview-Grundlagen lesen.

F: Wie würden Secrets daran gehindert, in Git-Repositories zu erscheinen, wenn GitOps verwendet wird?

External Secrets Operator speichert nur Referenzen zu Secrets in Git, nicht die Werte selbst. Das ExternalSecret-Manifest enthält den Pfad zum Secret in Vault oder AWS Secrets Manager, während das eigentliche Secret nie das Repository berührt. Sealed Secrets von Bitnami bietet einen alternativen Ansatz mit asymmetrischer Verschlüsselung.

F: Erklären Sie den Unterschied zwischen SecretStore und ClusterSecretStore.

SecretStore ist Namespace-bezogen: ExternalSecrets im selben Namespace können darauf verweisen. ClusterSecretStore ist clusterweit: jeder Namespace kann darauf verweisen. ClusterSecretStore verwenden, wenn mehrere Teams eine einzelne Vault-Instanz teilen, und SecretStore, wenn jeder Namespace isolierte Secret-Backends hat.

F: Ein Pod kann nach dem Deployment nicht auf seine Secrets zugreifen. Wie würden Sie das Problem beheben?

Mit dem ExternalSecret-Status beginnen:

# troubleshoot-secrets.sh
# Check ExternalSecret sync status and conditions
kubectl get externalsecret database-credentials -o yaml

# Verify the Secret was created
kubectl get secret db-secret -o yaml

# Check ESO controller logs for auth errors
kubectl logs -n external-secrets deployment/external-secrets

Häufige Fehler sind abgelaufene Vault-Tokens, fehlerhafte Secret-Pfade und RBAC-Fehlkonfigurationen im ClusterSecretStore.

F: Wie wird Secret-Rotation für Datenbank-Anmeldedaten in der Produktion gehandhabt?

Vaults Database-Secrets-Engine generiert dynamische, kurzlebige Anmeldedaten. ESO mit einem refreshInterval kürzer als die Anmeldedaten-TTL konfigurieren. Für statische Anmeldedaten, die Rotation erfordern, Vaults Rotation-API kombiniert mit Reloader verwenden, um Pods nach Updates neu zu starten. Die Anwendung sollte Verbindungsfehler während des Rotationsfensters graceful handhaben.

AWS Secrets Manager mit ESO

Die AWS Secrets Manager-Integration erfordert IAM Roles for Service Accounts (IRSA). Dieses Pattern eliminiert statische Anmeldedaten vollständig:

# aws-secret-store.yaml
# ClusterSecretStore for AWS Secrets Manager with IRSA
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: aws-secrets
spec:
  provider:
    aws:
      service: SecretsManager
      region: eu-west-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa
            namespace: external-secrets

Die Service-Account-Annotation verknüpft mit der IAM-Rolle:

# service-account-irsa.yaml
# Service account with IAM role annotation
apiVersion: v1
kind: ServiceAccount
metadata:
  name: external-secrets-sa
  namespace: external-secrets
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/external-secrets

AWS rotiert automatisch Secrets, die über Secrets Manager mit einer Lambda-Funktion erstellt wurden. Kombiniert mit ESOs Refresh-Intervall, werden Secrets innerhalb der konfigurierten Polling-Periode an Kubernetes propagiert.

Multi-Cluster Secret-Synchronisation

Organisationen, die mehrere Cluster betreiben, benötigen konsistente Secret-Verteilung. Zwei Patterns adressieren diese Anforderung:

Hub-and-Spoke mit ClusterSecretStore:

Alle Cluster verbinden sich mit einer zentralen Vault-Instanz. Die ESO-Installation jedes Clusters referenziert dieselben Secrets, und Vault handhabt die Zugriffskontrolle durch Namespace-basierte Policies.

Replikation mit Vault Enterprise:

Vault Enterprise unterstützt Performance-Replikation über Regionen hinweg. Jeder Cluster verbindet sich mit seinem lokalen Vault-Replikat, reduziert Latenz bei gleichzeitiger Konsistenz. Die Vault Replikations-Dokumentation behandelt Disaster-Recovery- und Performance-Replikationsmodi.

Für Teams, die ArgoCD verwenden, behandelt der Artikel GitOps-Deployment-Patterns ApplicationSets, die ExternalSecrets über mehrere Cluster deployen.

RBAC-Härtung für Secrets-Zugriff

Standard-Cluster-Rollen gewähren übermäßigen Secret-Zugriff. RBAC durch Erstellen minimaler Rollen härten:

# restricted-role.yaml
# Role allowing secret access only in specific namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-reader
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]
    resourceNames: ["db-secret", "api-key"]

Das resourceNames-Feld beschränkt den Zugriff auf explizit aufgelistete Secrets. Ohne dieses Feld gewährt die Rolle Zugriff auf alle Secrets im Namespace.

Audit-Logging erfasst Secret-Zugriffsversuche:

# audit-policy.yaml
# Kubernetes audit policy for secret operations
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
    verbs: ["get", "list", "watch"]

Diese Policy protokolliert die vollständige Anfrage und Antwort für Secret-Operationen und ermöglicht Sicherheitsteams, unberechtigte Zugriffsmuster zu erkennen.

Produktions-Checkliste für Kubernetes Secrets

• etcd-Verschlüsselung im Ruhezustand mittels EncryptionConfiguration API-Ressource aktivieren
• External Secrets Operator v0.10+ mit ClusterSecretStore zu Vault oder Cloud-Provider deployen
• refreshInterval unter der Anmeldedaten-TTL konfigurieren, um sicherzustellen, dass Secrets vor Ablauf aktualisiert werden
• IRSA (AWS), Workload Identity (GCP) oder Kubernetes Auth (Vault) anstelle statischer Anmeldedaten verwenden
• RBAC mit resourceNames einschränken, um Secret-Zugriff auf spezifische benannte Secrets zu begrenzen
• Kubernetes-Audit-Logging für Secret-Operationen mit RequestResponse-Level aktivieren
• Reloader für Anwendungen deployen, die Umgebungsvariablen verwenden, um Secret-Updates zu handhaben
• Secret-Rotation in Staging vor Produktions-Deployment testen
• Wiederherstellungsverfahren für Secret-Backend-Ausfälle dokumentieren, die Pod-Scheduling beeinflussen