Kubernetes Encryption-at-Rest in Kubernetes

Warum ist Verschlüsselung so wichtig?

Encryption-at-Rest bezeichnet die Verschlüsselung von gespeicherten Daten, so dass diese auch bei unberechtigtem Zugriff auf physische oder virtuelle Speichermedien nicht lesbar sind.

In einer produktiv genutzten Kubernetes-Umgebung werden häufig auch unternehmenskritische Daten gespeichert - meist in Persistent Volumes (PV) oder in Kubernetes Secrets. Ohne entsprechende Verschlüsselung besteht die Gefahr, dass unberechtigte Dritte auf sensible Daten zugreifen können. Dies kann etwa passieren, wenn Nodes kompromittiert werden, Backups gestohlen werden oder Zugriffsrechte unzureichend konfiguriert werden. Besonders in regulierten Branchen, wie im Finanz- oder Gesundheitswesen ist Encryption-at-rest ein Muss, um Compliance-Anforderungen wie ISO-Normen oder auch die seit dem letzten Jahr inkraftgetretene DORA zu erfüllen.

Welche Verschlüsselungsmethoden bietet Kubernetes?

Es gibt verschiedene Ansätze, um Datenverschlüsselung im Ruhezustand in Kubernetes umzusetzen:

a) Node-Level Encryption

Die Verschlüsselung erfolgt auf Betriebssystemebene, beispielsweise mit LUKS/dm-crypt. LUKS (Linux Unified Key Setup) ist der Standard für Festplattenverschlüsselung unter Linux und verwendet dm-crypt (Device Mapper Crypt), um Datenblöcke auf dem Speichermedium zu verschlüsseln. Dabei wird AES-256 als Standardalgorithmus verwendet, auf den wir im nächsten Abschnitt genauer eingehen.

Beispielhafte Einrichtung mit LUKS:

sudo cryptsetup luksFormat /dev/sdX
sudo cryptsetup open /dev/sdX encrypted-volume
mkfs.ext4 /dev/mapper/encrypted-volume

b) Storage-Level Encryption

Storage-Level Encryption wird direkt auf der Speicherschicht umgesetzt, etwa durch Ceph, OpenStack Cinder oder AWS EBS mit nativer Verschlüsselung. Diese Methode ist für Anwendungen transparent, sodass keine Anpassungen auf Applikationsebene erforderlich sind. Viele dieser Storage-Backends nutzen AES-256 als Verschlüsselungsalgorithmus, um gespeicherte Daten sicher zu halten. AES-256 verwendet eine 256-Bit-Schlüssellänge und gehört zur Advanced Encryption Standard (AES)-Familie, die von der US-Regierung und internationalen Organisationen als sicher eingestuft wird. Durch seine hohe Schlüssellänge bietet AES-256 Schutz gegen Brute-Force-Angriffe und wird in sicherheitskritischen Bereichen wie Finanzwesen, Gesundheitswesen und behördlichen Infrastrukturen eingesetzt. AES-256 gilt als Industriestandard für starke Verschlüsselung und wird häufig in Compliance-Anforderungen wie ISO 27001 und DSGVO empfohlen.

Beispiel: Verschlüsselung eines Ceph RBD Volumes aktivieren:

ceph osd pool create encrypted-pool 128 128
ceph osd pool application enable encrypted-pool rbd
rbd create --size 10240 --pool encrypted-pool --image-feature encryption

c) Application-Level Encryption Hierbei erfolgt die Verschlüsselung direkt auf Applikationsebene, beispielsweise durch PostgreSQL Transparent Data Encryption oder HashiCorp Vault. Diese Methode bietet maximale Kontrolle über das Schlüsselmanagement, erfordert aber mehr Entwicklungsaufwand.

Kubernetes-native Verschlüsselung: CSI Encryption & Secrets Encryption

a) Verschlüsselung von Persistent Volumes mit CSI Viele CSI-Treiber (Container Storage Interface) bieten mittlerweile native Verschlüsselung.

Beispiel mit OpenEBS:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: encrypted-storage
provisioner: openebs.io/local
parameters:
  encryption: "true"

b) Kubernetes Secrets Encryption Kubernetes Secrets sind ein nativer Mechanismus zur Speicherung sensibler Informationen wie Passwörter, API-Schlüssel oder TLS-Zertifikate. Allerdings werden sie standardmäßig nur Base64-kodiert gespeichert und nicht verschlüsselt. Das bedeutet, dass ohne zusätzliche Schutzmaßnahmen jeder mit Zugriff auf das etcd-Backend die Secrets im Klartext auslesen kann.

Um die Sicherheit von Secrets zu erhöhen, gibt es mehrere Strategien:

• Encryption at Rest für etcd aktivieren, um sicherzustellen, dass Secrets auf der Speicherebene verschlüsselt werden.

• Key Management Systeme (KMS) nutzen, um Secrets sicher zu verwalten und automatisch zu rotieren.

• Sealed Secrets oder External Secrets Operator verwenden, um die Verwaltung und Bereitstellung von Secrets außerhalb des Clusters zu steuern.

Beispiel: Aktivierung der Secret Encryption in Kubernetes mit Key Management System (z. B. HashiCorp Vault):

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - kms:
          name: vault-encryption
          endpoint: unix:///var/run/vault.sock

Nach der Konfiguration:

kubectl apply -f encryption-config.yaml
kubectl get secrets my-secret -o yaml  # Verschlüsseltes Secret abrufen

Herausforderungen und Best Practices

a) Die richtige Balance zwischen Performance und Sicherheit finden Während Storage-Level Encryption die einfachste Implementierung bietet, kann sie zu erhöhter Latenz führen. Application-Level Encryption bietet mehr Kontrolle, erhöht aber den Entwicklungsaufwand. Eine gründliche Benchmark-Analyse ist daher ratsam, bevor man sich für eine Methode entscheidet.

b) Sichere Schlüsselverwaltung Ein zentrales Key Management System (KMS) wie Vault sollte genutzt werden, da das Speichern von Schlüsseln in Kubernetes Secrets nicht empfohlen wird. Zudem ist eine regelmäßige Rotation der Verschlüsselungsschlüssel essenziell.

c) Automatisierung mit Helm und Terraform Um die Verschlüsselung effizient zu verwalten, können Helm-Charts für Sicherheitsrichtlinien in Kubernetes genutzt werden. Terraform eignet sich zur automatisierten Konfiguration von Verschlüsselungsoptionen, etwa für AWS EBS oder OpenStack Cinder.

Fazit und Handlungsempfehlungen

Encryption-at-Rest ist eine essentielle Sicherheitsmaßnahme für Kubernetes-Umgebungen. Unternehmen sollten je nach Anwendungsfall entscheiden, ob sie Node-, Storage- oder Application-Level Encryption nutzen. Kubernetes-native Mechanismen wie CSI Encryption und Secrets Encryption bieten eine gute Basis, sollten aber mit einem robusten Key Management System (KMS) kombiniert werden.

Welche Maßnahmen können Unternehmen ohne großen Aufwand ergreifen, um ihre Kubernetes-Umgebung sicherer zu machen?

• Analyse der bestehenden Kubernetes Storage-Lösung – Welche Speicherarten werden genutzt?
• Verschlüsselung aktivieren – Falls Storage-Verschlüsselung nicht verfügbar ist, alternative Methoden in Betracht ziehen
• Schlüsselmanagement absichern – HashiCorp Vault oder OpenStack Barbican verwenden
• Performance & Compliance prüfen – Benchmarks und Audits durchführen