LUKS Verschlüsselter Speicher in Kubernetes

Heutzutage finden immer mehr zustandsbehaftete Anwendungen ihren Weg in produktive Kubernetes-Cluster. Daher ist es wahrscheinlich, dass du bereits persistente Volumes oder persistente Volume-Claims (PVs/PVCs) für die von dir oder deiner Organisation bereitgestellten Workloads verwendest. Wenn du diese Anwendungen gründlich absichern willst, musst du dich auch um deine Daten kümmern. Ein guter erster Schritt ist die Verwendung von verschlüsseltem Speicher in Kubernetes. In diesem Tutorial zeigen wir dir, wie du verschlüsselten Speicher in NETWAYS Managed Kubernetes Clustern einrichtest.

Voraussetzungen

Um den verschlüsselten Speicher in Kubernetes Clustern auf MyNWS auszuprobieren, musst du zunächst ein Cluster erstellen. Das kannst du über das Kubernetes-Menü auf dem MyNWS-Dashboard. Für dieses Tutorial ist die kleinstmögliche Konfiguration, bestehend aus einem Control-Plane-Node der Größe s1.medium und einem Worker-Node der Größe s1.medium, ausreichend. Stelle  sicher, dass dein Cluster öffentlich zugänglich ist, damit du es über das Internet erreichen kannst, und klicke auf Create.

Nach ein paar Minuten ist dein Cluster bereit. Lade Deine kubeconfig wie unten gezeigt herunter (Du kannst zwischen einer OIDC-basierten Konfiguration oder einer Admin-Konfiguration wählen), und wir können mit der Erkundung unserer Speicheroptionen beginnen.

Prüfen der verfügbaren Speicheroptionen

Sobald wir unsere kubeconfig-Datei haben und uns mit unserem Cluster verbinden können, können wir mit dem folgenden Befehl alle StorageClasses anzeigen, die in unserem Cluster verfügbar sind:

Wie wir sehen können, sind alle verfügbaren StorageClasses in Bezug auf Provisioner, ReclaimPolicy, VolumeBindingMode und AllowVolumeExpansion auf die gleiche Weise konfiguriert – für weitere Informationen zu diesen Themen schaue bitte in die offizielle Kubernetes-Dokumentation. Der interessanteste Teil für uns ist im Moment der Provisioner – es ist cinder.csi.openstack.org für alle StorageClasses. Das bedeutet, dass OpenStack hinter den Kulissen die Erstellung, Verwaltung und Löschung der PersistentVolumes in unseren Kubernetes-Clustern für uns übernimmt. Aber was bedeuten diese StorageClass-Namen?

• standard ist als default eingestellt und stellt ein ext4-formatiertes OpenStack-Volume mit einem IOPS-Limit von 1000 IOPS und Bursts von bis zu 2000 IOPS bereit.
• nws-storage ist ähnlich wie standard, aber formatiert das OpenStack-Volume als xfs statt ext4.
• high-iops ist eine schnellere Variante von nws-storage, mit einem IOPS-Limit von 2000 IOPS und Bursts von bis zu 4000IOPS.
• encrypted nutzt ein OpenStack-Volume, das transparent LUKS-verschlüsselten Speicher bietet, mit den IOPS-Grenzen von nws-storage.
• encrypted-high-iops kombiniert die Konfigurationen von high-iops und encrypted

Dieses Standard-Setup ist für eine Vielzahl von Anwendungsanforderungen geeignet: Anwendungen, die viel langsamen und/oder schnellen Speicher benötigen, der keine sensiblen Daten enthält, können die default-, nws-storage- oder high-iops-StorageClasses verwenden, während sensible Daten mit den encrypted(-high-iops)-StorageClasses LUKS-verschlüsselten Speicher in Kubernetes nutzen können. Aber wie verwendet man sie, und wie funktionieren sie?

Anfragen von verschlüsseltem Speicher in Kubernetes

Kubernetes bietet uns eine nützliche API für die programmatische Anforderung von Speicher jeder Art von StorageClass – einen PersistentVolumeClaim (PVC). Man definiert ihn als Objekt für die API von Kubernetes, z. B. über ein YAML-Manifest, und Kubernetes und die externen Provisioner  übernehmen die tatsächliche Arbeit. In unserem Fall bedeutet das, dass der cinder.csi.openstack.org-Provisioner sich um die folgenden Dinge kümmert, wenn wir verschlüsselten Speicher auf NETWAYS Managed Kubernetes anfordern:

• Erstellung des Verschlüsselungsschlüssel im OpenStack-Schlüsselverwaltungssystem (KMS) Barbican.
• Erstellung eines LUKS-verschlüsseltes Volumes in OpenStack.
• Bereitstellung des Volumes für unsere  Workloads in Kubernetes, bereits entschlüsselt und einsatzbereit!

Schauen wir uns das in Aktion an: Unten ist ein Beispiel für ein PVC-Manifest, das wir mit kubectl apply -f <Datei> auf unser Cluster anwenden können:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: encrypted-claim
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi
  storageClassName: encrypted

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: encrypted-claim
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi
  storageClassName: encrypted

Wir können den PVC mit kubectl get pvc -n default überprüfen und sehen, dass ein PVC erstellt und an ein PersistentVolume gebunden wurde, das dem eigentlichen, verschlüsselten Speicher entspricht, der uns von OpenStack zur Verfügung gestellt wird:

Schauen wir uns als nächstes an, ob wir das Volume innerhalb unserer Workloads verwenden können!

Zugriff auf verschlüsselten Speicher in Kubernetes

Als Nutzer eines Managed-Kubernetes-Angebots wollen wir uns wahrscheinlich nicht mit den Feinheiten von Key-Management-Systemen (KMS), Volume-Provisionern und der ständigen Ver- und Entschlüsselung unserer Volumes auseinandersetzen. Wir wollen einfach nur Storage in unseren Anwendungen nutzen, die auf Kubernetes laufen.

Sehen wir uns also an, ob OpenStack und NETWAYS Managed Kubernetes uns genau das ermöglichen, indem wir die folgende Demo–Anwendung auf unser Cluster anwenden:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deployment
  namespace: default
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          volumeMounts:
            - name: encrypted-storage
              mountPath: /data-encrypted
      volumes:
        - name: encrypted-storage
          persistentVolumeClaim:
            claimName: encrypted-claim

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deployment
  namespace: default
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          volumeMounts:
            - name: encrypted-storage
              mountPath: /data-encrypted
      volumes:
        - name: encrypted-storage
          persistentVolumeClaim:
            claimName: encrypted-claim

Nachdem wir dieses Manifest mit kubectl apply -f <Datei> auf unser Cluster angewendet haben, können wir den Status des Deployments überprüfen, um zu sehen, ob der Pod den referenzierten, verschlüsselten PersistentVolumeClaim erfolgreich mounten konnte:

Der letzte Test besteht nun darin, zu prüfen, ob wir von unserem NGINX-Pod aus von dem vermeintlich verschlüsselten Volume lesen und darauf schreiben können. Das können wir mit dieser Befehlsfolge tun:

kubectl exec -n default deployment/test-deployment -- \
  /bin/sh -c 'touch /data-encrypted/test.txt && \
  echo "Hello World!" > /data-encrypted/test.txt'
kubectl rollout restart -n default deployment/test-deployment
kubectl rollout status -n default --watch deployment/test-deployment
kubectl exec -n default deployment/test-deployment -- \
  /bin/cat /data-encrypted/test.txt

kubectl exec -n default deployment/test-deployment -- \
  /bin/sh -c 'touch /data-encrypted/test.txt && \
  echo "Hello World!" > /data-encrypted/test.txt'
kubectl rollout restart -n default deployment/test-deployment
kubectl rollout status -n default --watch deployment/test-deployment
kubectl exec -n default deployment/test-deployment -- \
  /bin/cat /data-encrypted/test.txt

Diese Sequenz wird…

1. Eine Datei test.txt in unserem gemounteten verschlüsselten Volume innerhalb des Pods erstellen und Hello World! in diese Datei schreiben.
2. Das Deployment restarten, damit wir sicherstellen können, dass die Daten tatsächlich persistiert wurden.
3. Auf den erfolgreich durchgeführten Restart warten.
4. Den Inhalt der Datei auslesen, die wir zuvor angelegt hatten

Und so wie es aussieht, hat es funktioniert! Wir können tatsächlich verschlüsselten Speicher in Kubenetes mit den LUKS-verschlüsselten Volumes von OpenStack nutzen, was uns die Mühe erspart, die Verschlüsselung selbst einzurichten.

Für mehr Sicherheit!

Obwohl verschlüsselter Speicher in Kubernetes, unterstützt durch die OpenStack-Funktion für verschlüsselte Volumes, nur eine Verschlüsselung im Ruhezustand bietet, ist es dennoch ein weiterer (oder erster) Schritt in Richtung sicherer Workloads.
Das Beste daran ist, dass wir nichts manuell tun müssen: Erstelle einfach einen PVC, der auf eine verschlüsselte Speicherklasse verweist, und OpenStack übernimmt die gesamte Arbeit, um dir verschlüsselten Speicher in Kubernetes zur Verfügung zu stellen.

Wenn du weitere Fragen zu den technischen Details dieses Prozesses hast, zögere nicht, dich mit unseren mit unseren MyEngineer® in Verbindung zu setzen! Natürlich gehört zu Cloud-Native Sicherheit mehr als nur verschlüsselte Daten. Deshalb solltest du unbedingt unseren Newsletter abonnieren und die Augen offen halten nach Inhalten zu Service Meshes, Policy Engines und anderen Sicherheitsmaßnahmen, die wir in Zukunft gerne mit und für dich erkunden möchten.