etcd Encryption at Rest: Kubernetes-Secrets richtig verschlüsseln

TL;DR - Kurzfassung

Kubernetes speichert Secrets standardmäßig Base64-kodiert, aber unverschlüsselt in etcd. Mit einer EncryptionConfiguration aktivieren Sie Verschlüsselung direkt auf dem API-Server. Die empfohlenen Provider sind aescbc für Self-Managed-Cluster und kms für Cloud-Umgebungen. Nach der Aktivierung müssen alle bestehenden Secrets einmal neu geschrieben werden, damit die Verschlüsselung greift.

Wer glaubt, Kubernetes-Secrets seien sicher, irrt sich in den meisten Fällen. Ein kubectl get secret my-secret -o yaml zeigt Base64-kodierte Werte -- das ist keine Verschlüsselung, sondern lediglich Kodierung. Jeder mit Lesezugriff auf etcd kann sämtliche Secrets im Klartext auslesen. Für Unternehmen, die DSGVO, BSI IT-Grundschutz oder NIS2 einhalten müssen, ist das ein erhebliches Risiko.

# So prüfen Sie, ob Ihre Secrets verschlüsselt sind
# Direkter etcd-Zugriff (nur auf Control-Plane-Nodes)
ETCDCTL_API=3 etcdctl get /registry/secrets/default/my-secret \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key | hexdump -C | head -20

Sehen Sie im Output Klartextwerte wie Passwörter oder Tokens, sind Ihre Secrets nicht verschlüsselt.

Encryption Provider im Überblick

Kubernetes unterstützt mehrere Encryption Provider mit unterschiedlichen Eigenschaften:

Wichtig: aesgcm bietet authentifizierte Verschlüsselung, erfordert aber eine Schlüsselrotation alle 200.000 Schreibvorgänge. Für die meisten Cluster ist aescbc oder secretbox die pragmatischere Wahl.

EncryptionConfiguration einrichten

Schritt 1: Verschlüsselungsschlüssel generieren

# 32-Byte-Schlüssel für AES-256 erzeugen
head -c 32 /dev/urandom | base64
# Beispielausgabe: dGhpcyBpcyBhIHRlc3Qga2V5IGZvciBkZW1v

Schritt 2: EncryptionConfiguration erstellen

Legen Sie die Konfiguration auf allen Control-Plane-Nodes unter /etc/kubernetes/encryption-config.yaml ab:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps  # Optional, aber empfohlen für sensible ConfigMaps
    providers:
      # Erster Provider wird zum Verschlüsseln neuer Daten verwendet
      - aescbc:
          keys:
            - name: key-2026-03
              secret: dGhpcyBpcyBhIHRlc3Qga2V5IGZvciBkZW1v
      # Identity als Fallback zum Lesen unverschlüsselter Daten
      - identity: {}

Der erste Provider in der Liste wird für neue Verschlüsselungen verwendet. Der identity-Provider am Ende stellt sicher, dass bereits existierende, unverschlüsselte Secrets weiterhin gelesen werden können.

Schritt 3: API-Server konfigurieren

Fügen Sie das Flag --encryption-provider-config zum kube-apiserver hinzu:

# /etc/kubernetes/manifests/kube-apiserver.yaml (Static Pod Manifest)
apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
    - name: kube-apiserver
      command:
        - kube-apiserver
        ---encryption-provider-config=/etc/kubernetes/encryption-config.yaml
        # ... weitere Flags
      volumeMounts:
        - name: encryption-config
          mountPath: /etc/kubernetes/encryption-config.yaml
          readOnly: true
  volumes:
    - name: encryption-config
      hostPath:
        path: /etc/kubernetes/encryption-config.yaml
        type: File

Der API-Server startet automatisch neu, da es sich um ein Static Pod Manifest handelt.

Schritt 4: Bestehende Secrets neu verschlüsseln

Neue Secrets werden ab sofort verschlüsselt. Bestehende Secrets müssen einmal neu geschrieben werden:

# Alle Secrets in allen Namespaces neu verschlüsseln
kubectl get secrets --all-namespaces -o json | \
  kubectl replace -f -

# Prüfen, ob die Verschlüsselung aktiv ist
kubectl get secret my-secret -n default -o yaml
# Der Output zeigt weiterhin Base64, aber in etcd ist der Wert verschlüsselt

Schlüsselrotation durchführen

Regelmäßige Schlüsselrotation ist Pflicht -- mindestens alle 90 Tage nach BSI-Empfehlung.

Ablauf der Rotation:

1. Neuen Schlüssel generieren und als ersten Eintrag in die keys-Liste setzen
2. API-Server neu starten (geschieht bei Static Pods automatisch)
3. Alle Secrets neu schreiben, damit sie mit dem neuen Schlüssel verschlüsselt werden
4. Alten Schlüssel erst entfernen, nachdem alle Secrets migriert sind

# Aktualisierte encryption-config.yaml mit neuem Schlüssel
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            # Neuer Schlüssel zuerst (wird zum Verschlüsseln verwendet)
            - name: key-2026-06
              secret: bmV1ZXIgc2NobHVlc3NlbCBmdWVyIHJvdGF0aW9u
            # Alter Schlüssel zum Entschlüsseln bestehender Daten
            - name: key-2026-03
              secret: dGhpcyBpcyBhIHRlc3Qga2V5IGZvciBkZW1v
      - identity: {}

# Nach API-Server-Neustart: Alle Secrets migrieren
kubectl get secrets --all-namespaces -o json | kubectl replace -f -

# Verifizieren, dass keine Secrets mehr mit dem alten Schlüssel verschlüsselt sind
# Dann den alten Schlüssel aus der Konfiguration entfernen

KMS Provider für Cloud-Umgebungen

Für Cluster in AWS, GCP oder Azure ist der KMS Provider v2 die beste Wahl. Der Verschlüsselungsschlüssel verlässt nie den Key Management Service.

Bei Managed Kubernetes (EKS, GKE, AKS) ist Encryption at Rest oft bereits aktiviert. Prüfen Sie dies in den Cluster-Einstellungen Ihres Cloud-Providers.

Häufige Fehler vermeiden

Drei Probleme treten bei der Einrichtung regelmäßig auf:

Schlüssel nur auf einem Control-Plane-Node: Die encryption-config.yaml muss auf allen Control-Plane-Nodes identisch sein. Andernfalls können Secrets, die auf einem Node verschlüsselt wurden, auf einem anderen nicht entschlüsselt werden.

Identity-Provider vergessen: Ohne identity als letzten Provider schlägt das Lesen aller unverschlüsselten Secrets nach der Aktivierung fehl. Der Cluster wird instabil.

Secrets nicht neu geschrieben: Die Verschlüsselung gilt nur für neue Schreibvorgänge. Bestehende Secrets bleiben unverschlüsselt, bis sie mit kubectl replace neu geschrieben werden.

FAQ

Sind Kubernetes-Secrets ohne Encryption at Rest sicher?

Nein. Ohne Encryption at Rest liegen Secrets Base64-kodiert in etcd. Base64 ist keine Verschlüsselung. Jeder mit Zugriff auf etcd-Backups oder die etcd-Datenbank kann alle Secrets im Klartext lesen.

Welchen Encryption Provider sollte ich verwenden?

Für Self-Managed-Cluster ist aescbc der etablierte Standard. secretbox ist eine modernere Alternative mit vergleichbarer Sicherheit. Für Cloud-Umgebungen nutzen Sie den KMS Provider, da der Schlüssel nie den Key Management Service verlässt.

Muss ich nach der Aktivierung alle Secrets neu erstellen?

Sie müssen bestehende Secrets nicht löschen und neu erstellen, aber einmal neu schreiben. Der Befehl kubectl get secrets --all-namespaces -o json | kubectl replace -f - erledigt das für den gesamten Cluster.

Wie oft sollte ich den Verschlüsselungsschlüssel rotieren?

Das BSI empfiehlt eine Rotation alle 90 Tage. Bei aesgcm ist eine Rotation nach spätestens 200.000 Schreibvorgängen technisch notwendig. Automatisieren Sie die Rotation, um menschliche Fehler zu vermeiden.

Was passiert, wenn der Verschlüsselungsschlüssel verloren geht?

Ohne den Schlüssel können verschlüsselte Secrets nicht mehr entschlüsselt werden. Sichern Sie die encryption-config.yaml an einem separaten, sicheren Ort -- idealerweise in einem Hardware Security Module (HSM) oder einem externen Secret Manager.