Kubernetes Verschluesselung: Praxisleitfaden fuer etcd, mTLS und Key Management

TL;DR

• Kubernetes Secrets liegen standardmaessig nur Base64-kodiert (nicht verschluesselt) in etcd. EncryptionConfiguration mit AES-GCM ist Pflicht fuer jeden produktiven Cluster.
• Data-in-Transit zwischen Pods ist ohne Service Mesh oder manuelle TLS-Konfiguration unverschluesselt. Linkerd bringt mTLS mit minimalem Aufwand.
• Key Management gehoert nicht in den Cluster: Externe KMS-Loesungen wie HashiCorp Vault oder Cloud-KMS sind der Standard fuer Schluesselrotation und Zugriffskontrolle.
• Cert-Manager automatisiert die TLS-Zertifikatsverwaltung fuer Ingress-Ressourcen und interne Services vollstaendig.
• Die groesste Luecke in der Praxis: Viele Teams verschluesseln den Ingress-Traffic, vergessen aber die interne Pod-zu-Pod-Kommunikation.

Das Problem: Was Kubernetes standardmaessig nicht verschluesselt

Kubernetes verschluesselt ueberraschend wenig out of the box. Ja, die Kommunikation zwischen API-Server, Kubelet und etcd laeuft ueber TLS. Aber das wars auch schon. Schauen wir uns an, was ungeschuetzt bleibt:

etcd-Daten: Secrets, ConfigMaps, ServiceAccount-Tokens -- alles liegt im Klartext in etcd. Base64-Encoding ist keine Verschluesselung. Wer Zugriff auf etcd hat (oder ein Backup davon), kann jedes Datenbankpasswort und jeden API-Key lesen.

Pod-zu-Pod-Traffic: Standardmaessig kommunizieren Pods ueber das Cluster-Netzwerk im Klartext. Ein Angreifer, der einen Pod kompromittiert, kann den Netzwerkverkehr anderer Pods im selben Node mitlesen.

Persistent Volumes: Ob ein PV verschluesselt ist, haengt vom Storage-Backend ab. Kubernetes selbst verschluesselt keine Volumes.

Das bedeutet: Verschluesselung in Kubernetes ist kein Feature, das man einschaltet. Es ist eine Architekturentscheidung, die mehrere Schichten betrifft.

Schicht 1: etcd-Verschluesselung (Data-at-Rest)

Die etcd-Verschluesselung schuetzt Daten innerhalb der etcd-Datenbank. Der API-Server verschluesselt die Daten vor dem Schreiben und entschluesselt sie beim Lesen. Fuer Clients aendert sich nichts.

EncryptionConfiguration erstellen

# /etc/kubernetes/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
    providers:
      # AES-GCM: schneller als CBC und bietet Integritaetspruefung
      - aesgcm:
          keys:
            - name: key-2026-02
              secret: c2VjdXJlLXJhbmRvbS0zMi1ieXRlLWtleS1oZXJl
      # Fallback: Bestehende unverschluesselte Daten lesen
      - identity: {}

Der API-Server muss mit dem Flag --encryption-provider-config gestartet werden:

# Schluessel generieren (32 Byte fuer AES-256)
head -c 32 /dev/urandom | base64

# Nach Aktivierung: Bestehende Secrets neu schreiben,
# damit sie verschluesselt werden
kubectl get secrets --all-namespaces -o json | kubectl replace -f -

# Verifizieren, dass Secrets verschluesselt sind
# (erfordert direkten etcd-Zugriff)
ETCDCTL_API=3 etcdctl get /registry/secrets/default/my-secret \
  --endpoints=https://127.0.0.1:2379 \
  --cert=/etc/kubernetes/pki/etcd/peer.crt \
  --key=/etc/kubernetes/pki/etcd/peer.key \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt | hexdump -C | head

Wenn die Verschluesselung aktiv ist, sehen Sie im hexdump keinen Klartext mehr, sondern den Prefix k8s:enc:aesgcm:v1:key-2026-02.

AES-CBC vs. AES-GCM

Die klare Empfehlung ist AES-GCM. Es ist schneller und bietet eine integrierte Integritaetspruefung, die Manipulationen an den verschluesselten Daten erkennt.

Schicht 2: Data-in-Transit Verschluesselung

Ingress-TLS mit Cert-Manager

Fuer externen Traffic ist TLS-Terminierung am Ingress-Controller der Standard. Cert-Manager automatisiert die Zertifikatsbeschaffung und -erneuerung:

# Cert-Manager ClusterIssuer fuer Let's Encrypt
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
    - http01:
        ingress:
          class: nginx
---
# Ingress mit automatischem TLS-Zertifikat
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - app.example.com
    secretName: app-tls-cert
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-service
            port:
              number: 8080

Das Zertifikat wird automatisch ausgestellt und vor Ablauf erneuert. Kein manuelles Handling noetig.

mTLS zwischen Services: Service Mesh

TLS am Ingress schuetzt nur den externen Traffic. Die interne Kommunikation zwischen Pods bleibt unverschluesselt, es sei denn, die Anwendungen selbst TLS implementieren oder ein Service Mesh die Verschluesselung uebernimmt.

Ein Service Mesh injiziert einen Sidecar-Proxy in jeden Pod. Dieser Proxy uebernimmt die TLS-Terminierung und -Initiierung transparent fuer die Anwendung. Die Anwendung kommuniziert lokal im Klartext mit dem Sidecar, der Sidecar verschluesselt den Traffic zum Ziel-Pod.

Vergleich der gaengigen Service Meshes:

Fuer die meisten Teams ist Linkerd der pragmatischste Einstieg. Installation und mTLS-Aktivierung sind in wenigen Minuten erledigt, und der Ressourcen-Overhead ist minimal. Einen detaillierten Vergleich zwischen Istio und Linkerd finden Sie in unserem Service Mesh Vergleich.

Schicht 3: Key Management

Verschluesselung ist nur so stark wie das Schluesselmanagement. Keys in Kubernetes Secrets zu speichern ist ein Zirkelschluss: Sie verschluesseln Secrets mit einem Key, der selbst ein Secret ist.

Externe KMS-Integration

Die Loesung ist ein externes Key Management System. Kubernetes unterstuetzt seit v1.29 die KMS v2 API, die den API-Server mit einem externen KMS verbindet:

# KMS-Provider Konfiguration fuer den API-Server
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - kms:
          apiVersion: v2
          name: vault-kms-provider
          endpoint: unix:///var/run/kms-plugin/socket.sock
          timeout: 3s
      - identity: {}

Der KMS-Provider laeuft als separater Prozess auf dem Control-Plane-Node und kommuniziert ueber einen Unix-Socket mit dem API-Server. Er leitet die Ver- und Entschluesselungsanfragen an das externe KMS weiter -- zum Beispiel HashiCorp Vault, AWS KMS oder Azure Key Vault.

Secrets Management mit External Secrets Operator

Fuer Anwendungs-Secrets bietet der External Secrets Operator eine elegante Loesung. Er synchronisiert Secrets aus externen Quellen automatisch in Kubernetes Secrets:

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

Damit liegen die Master-Secrets ausserhalb des Clusters. Kubernetes-Secrets werden automatisch aktualisiert, wenn sich der Wert in Vault aendert. Das refreshInterval steuert die Synchronisationsfrequenz.

Schluesselrotation

Schluesselrotation fuer die etcd-Verschluesselung laeuft in drei Schritten:

1. Neuen Schluessel an erster Stelle in der EncryptionConfiguration hinzufuegen
2. API-Server neu starten -- er nutzt ab sofort den neuen Schluessel zum Schreiben
3. Alle Secrets neu schreiben, damit sie mit dem neuen Schluessel verschluesselt werden

Der alte Schluessel bleibt als Fallback in der Liste, bis alle Daten mit dem neuen Schluessel verschluesselt sind. Danach kann er entfernt werden.

Verschluesselung fuer Persistent Volumes

Die PV-Verschluesselung haengt vom Storage-Backend ab. Kubernetes selbst bietet keine Storage-Verschluesselung. Hier die gaengigen Optionen:

Fuer Cloud-Umgebungen ist die Verschluesselung meist standardmaessig aktiv. Fuer On-Premise-Setups muessen Sie LUKS auf Betriebssystem-Ebene oder Storage-Array-Verschluesselung konfigurieren. Mehr zu Storage-Architektur finden Sie in unserem Kubernetes Storage Guide.

Haeufige Fehler und wie man sie vermeidet

Fehler 1: Base64 mit Verschluesselung verwechseln. Base64 ist eine Kodierung, keine Verschluesselung. kubectl get secret my-secret -o jsonpath='{.data.password}' | base64 -d gibt das Passwort im Klartext aus. Jeder mit RBAC-Zugriff auf Secrets kann sie lesen.

Fehler 2: EncryptionConfiguration aktivieren, aber bestehende Secrets nicht neu schreiben. Die Verschluesselung gilt nur fuer neue Schreibvorgaenge. Bestehende Secrets bleiben unverschluesselt, bis sie explizit neu geschrieben werden.

Fehler 3: TLS am Ingress und dann fertig. Der Ingress verschluesselt nur den externen Traffic. Innerhalb des Clusters laeuft alles im Klartext, wenn kein Service Mesh oder manuelles TLS konfiguriert ist.

Fehler 4: Schluessel im selben Cluster speichern, den sie schuetzen sollen. Wenn ein Angreifer den Cluster kompromittiert, hat er sowohl die verschluesselten Daten als auch die Schluessel. Ein externes KMS ist die Loesung.

Checkliste: Verschluesselung im Cluster verifizieren

# 1. etcd-Verschluesselung aktiv?
ps aux | grep kube-apiserver | grep encryption-provider-config

# 2. Cert-Manager installiert und funktional?
kubectl get clusterissuers
kubectl get certificates --all-namespaces

# 3. Service Mesh mit mTLS aktiv? (Beispiel Linkerd)
linkerd check
linkerd viz stat deploy -n production

# 4. PV-Verschluesselung aktiv?
kubectl get storageclass -o yaml | grep encrypted

DSGVO-Relevanz

Verschluesselung ist eine der explizit in Art. 32 DSGVO genannten technisch-organisatorischen Massnahmen. Besonders relevant: Wenn verschluesselte Daten kompromittiert werden und die Schluessel nicht betroffen sind, kann die Meldepflicht nach Art. 34 DSGVO entfallen, da die Daten fuer den Angreifer unlesbar sind.

Fuer Unternehmen, die personenbezogene Daten in Kubernetes verarbeiten, ist eine dokumentierte Verschluesselungsstrategie nicht optional. Sie ist Nachweis fuer angemessene Schutzmassnahmen. Mehr zu den Compliance-Anforderungen finden Sie in unserem DSGVO-Kubernetes-Guide.

Weitergehende Themen

Die Verschluesselung ist eine Schicht in einer mehrschichtigen Sicherheitsarchitektur. Ergaenzende Massnahmen:

• Penetration Testing deckt auf, ob Ihre Verschluesselung Luecken hat
• Runtime Security erkennt zur Laufzeit, wenn ein Angreifer versucht auf Secrets oder Schluessel zuzugreifen
• Kubernetes Production Setup beschreibt die sichere Grundkonfiguration eines Clusters
• Der Azure Key Vault vs. Kubernetes Secrets Vergleich hilft bei der Entscheidung fuer Azure-Umgebungen

Wenn Sie Ihre Verschluesselungsstrategie evaluieren oder umsetzen moechten, unterstuetzen wir Sie gerne -- von der Architekturberatung bis zur Implementierung. Kontaktieren Sie uns unter /kontakt.