Skip to main content
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Trident Linux Unified Key Setup (LUKS)

Beitragende netapp-aruldeepa juliantap joan-ing netapp-mwallis
Änderungen vorschlagen

Linux Unified Key Setup (LUKS) ist eine Spezifikation für die Festplattenverschlüsselung. Trident verwendet LUKS, um eine hostseitige Verschlüsselung pro Volume für ONTAP SAN und ONTAP SAN ECONOMY Volumes bereitzustellen, einschließlich Unterstützung für die Rotation von Passphrasen und die Volume-Erweiterung.

In Trident verwenden LUKS-verschlüsselte Volumes den aes-xts-plain64-Cypher und -Modus, wie von empfohlen"NIST".

Hinweis Die LUKS-Verschlüsselung wird für ASA R2-Systeme nicht unterstützt. Weitere Informationen zu ASA R2-Systemen finden Sie unter "Erfahren Sie mehr über ASA r2 Storage-Systeme" .
Bevor Sie beginnen
  • Worker Nodes müssen cryptsetup 2.1 oder höher (aber unter 3.0) installiert sein. Weitere Informationen finden Sie unter "Gitlab: Cryptsetup".

  • Aus Performance-Gründen empfiehlt NetApp, dass Workerknoten die AES-NI (Advanced Encryption Standard New Instructions) unterstützen. Führen Sie den folgenden Befehl aus, um die Unterstützung von AES-NI zu überprüfen:

    grep "aes" /proc/cpuinfo

    Wenn nichts zurückgegeben wird, unterstützt Ihr Prozessor nicht AES-NI. Weitere Informationen zu AES-NI finden Sie unter: "Intel: Advanced Encryption Standard Instructions (AES-NI)".

Aktivieren Sie die LUKS-Verschlüsselung

Sie können die Verschlüsselung auf Host-Seite pro Volume mithilfe von Linux Unified Key Setup (LUKS) für ONTAP SAN und ONTAP SAN ECONOMY Volumes aktivieren.

Schritte
  1. Definieren Sie LUKS-Verschlüsselungsattribute in der Backend-Konfiguration. Weitere Informationen zu den Back-End-Konfigurationsoptionen für ONTAP SAN finden Sie unter "ONTAP SAN-Konfigurationsoptionen".

    {
      "storage": [
        {
          "labels": {
            "luks": "true"
          },
          "zone": "us_east_1a",
          "defaults": {
            "luksEncryption": "true"
          }
        },
        {
          "labels": {
            "luks": "false"
          },
          "zone": "us_east_1a",
          "defaults": {
            "luksEncryption": "false"
          }
        }
      ]
    }
  2. Nutzung parameters.selector So definieren Sie die Speicherpools mit LUKS-Verschlüsselung. Beispiel:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: luks
    provisioner: csi.trident.netapp.io
    parameters:
      selector: "luks=true"
      csi.storage.k8s.io/node-stage-secret-name: luks-${pvc.name}
      csi.storage.k8s.io/node-stage-secret-namespace: ${pvc.namespace}
  3. Erstellen Sie ein Geheimnis, das die LUKS-Passphrase enthält. Beispiel:

    kubectl -n trident create -f luks-pvc1.yaml
    apiVersion: v1
    kind: Secret
    metadata:
      name: luks-pvc1
    stringData:
      luks-passphrase-name: A
      luks-passphrase: secretA

Verwendung von LUKS mit RWX Raw-Block-Volumes

Ab Trident 26.10 können Sie LUKS-Verschlüsselung mit iSCSI-basierten Raw-Block-Volumes verwenden, die im ReadWriteMany (RWX)-Zugriffsmodus an mehrere Kubernetes-Knoten angebunden sind. Dies ist nützlich für Workloads wie KubeVirt virtuelle Maschinen, die während einer Live-Migration dasselbe verschlüsselte Volume an einem Zielknoten anbinden müssen, während es noch am Quellknoten angebunden ist.

Die RWX LUKS-Unterstützung ist auf Raw Block Volumes beschränkt. RWX LUKS Volumes im Dateisystemmodus werden nicht unterstützt. Die Applikation ist für die Koordination des gleichzeitigen Zugriffs auf die entschlüsselten Daten verantwortlich; Trident koordiniert ausschließlich LUKS-Operationen.

Die Konfiguration von LUKS im Backend, der StorageClass und des Passphrase-Secret erfolgt wie in Aktivieren Sie die LUKS-Verschlüsselung beschrieben. Anschließend lässt sich ein PVC mit volumeMode: Block und ReadWriteMany erstellen:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-rwx-pvc
  namespace: my-app
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Block
  storageClassName: san-luks-rwx
  resources:
    requests:
      storage: 10Gi

Pods auf mehreren Knoten können dieses PVC als Rohblockgerät einbinden. Trident formatiert das Gerät beim ersten Einbinden mit LUKS2 und öffnet das bestehende verschlüsselte Volume auf nachfolgenden Knoten. Bestehende LUKS-Operationen, einschließlich Passphrase-Rotation und Volume-Erweiterung, werden unterstützt.

Warum Trident LUKS-Operationen serialisiert

LUKS2 speichert redundante Kopien seines Verschlüsselungsheaders am Anfang des Blockgeräts. cryptsetup Es kann einen Header reparieren, wenn es erkennt, dass sich die Kopien unterscheiden, auch während Befehlen, die scheinbar schreibgeschützt sind. Die Sperrung ist lokal auf einen Knoten beschränkt und kann Operationen auf anderen Knoten nicht koordinieren. Wenn ein Knoten den Header aktualisiert, während ein anderer cryptsetup ausführt, könnte der zweite Knoten eine Header-Reparatur auslösen und die Aktualisierung unterbrechen, wodurch der Header möglicherweise beschädigt wird.

Um gleichzeitigen Zugriff auf Header zu verhindern, verwendet Trident für jedes RWX LUKS Volume eine Kubernetes Lease. Bevor ein Knoten einen cryptsetup Befehl für das Volume ausführt, muss er die Lease besitzen. Trident gibt die Lease nach einer erfolgreichen Operation frei. Wenn ein anderer Knoten eine Operation anfordert, während die Lease gehalten wird, gibt Trident einen Fehler zurück, bei dem ein erneuter Versuch möglich ist, und Kubernetes versucht es später erneut. Operationen auf verschiedenen Volumes sind unabhängig.

Schlägt ein cryptsetup Vorgang fehl, behält Trident die Lease absichtlich bei, sodass nur derselbe Knoten einen erneuten Versuch unternehmen kann. Ein Warnereignis mit Grund LeaseRetained protokolliert den Fehler. Leases laufen nicht automatisch ab; ein Administrator sollte eine Lease erst entfernen, nachdem sichergestellt wurde, dass auf dem Knoten, der die Lease hält, kein cryptsetup Vorgang ausgeführt wird. Informationen zu den Wiederherstellungsschritten enthält Behebung eines blockierten Lease für RWX Linux Unified Key Setup (LUKS) Volumes.

Da die Knoten das Volume nacheinander öffnen, kann das Starten von Workloads auf vielen verschiedenen Knoten länger dauern als bei einem unverschlüsselten Volume. Kubernetes wiederholt bei vorübergehenden Sperrfehlern den Versuch, nachdem der aktuelle Vorgang abgeschlossen ist. Pods können bei umfangreichen Scale-outs länger in ContainerCreating verbleiben; Workloads auf demselben Knoten können sich eine einzige offene Gerätezuordnung teilen.

Einschränkungen

LUKS-verschlüsselte Volumes können die ONTAP Deduplizierung und Komprimierung nicht nutzen.

Back-End-Konfiguration zum Importieren von LUKS-Volumes

Um ein LUKS-Volume zu importieren, müssen Sie auf(true dem Backend festlegen luksEncryption. Die luksEncryption Option zeigt Trident an, ob das Volume LUKS-konform ist (true) oder nicht LUKS-konform (false), wie im folgenden Beispiel gezeigt.

version: 1
storageDriverName: ontap-san
managementLIF: 10.0.0.1
dataLIF: 10.0.0.2
svm: trident_svm
username: admin
password: password
defaults:
  luksEncryption: 'true'
  spaceAllocation: 'false'
  snapshotPolicy: default
  snapshotReserve: '10'

PVC-Konfiguration für den Import von LUKS-Volumes

Um LUKS-Volumes dynamisch zu importieren, setzen Sie die Beschriftung trident.netapp.io/luksEncryption auf true und fügen Sie eine LUKS-fähige Storage-Klasse in die PVC ein, wie in diesem Beispiel gezeigt.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: luks-pvc
  namespace: trident
  annotations:
    trident.netapp.io/luksEncryption: "true"
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: luks-sc

Eine LUKS-Passphrase drehen

Sie können die LUKS-Passphrase drehen und die Drehung bestätigen.

Warnung Vergessen Sie keine Passphrase, bis Sie überprüft haben, dass sie nicht mehr von einem Volume, einem Snapshot oder einem geheimen Schlüssel referenziert wird. Wenn eine referenzierte Passphrase verloren geht, können Sie das Volume möglicherweise nicht mounten und die Daten bleiben verschlüsselt und unzugänglich.
Über diese Aufgabe

DIE Drehung der LUKS-Passphrase erfolgt, wenn ein Pod, das das Volume bindet, nach der Angabe einer neuen LUKS-Passphrase erstellt wird. Wenn ein neuer Pod erstellt wird, vergleicht Trident die LUKS-Passphrase auf dem Volume mit der aktiven Passphrase im Secret.

  • Wenn die Passphrase auf dem Volume nicht mit der aktiven Passphrase im Geheimnis übereinstimmt, erfolgt die Drehung.

  • Wenn die Passphrase auf dem Volume mit der aktiven Passphrase im Geheimnis übereinstimmt, wird das angezeigt previous-luks-passphrase Parameter wird ignoriert.

Schritte
  1. Fügen Sie die hinzu node-publish-secret-name Und node-publish-secret-namespace StorageClass-Parameter. Beispiel:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: csi-san
    provisioner: csi.trident.netapp.io
    parameters:
      trident.netapp.io/backendType: "ontap-san"
      csi.storage.k8s.io/node-stage-secret-name: luks
      csi.storage.k8s.io/node-stage-secret-namespace: ${pvc.namespace}
      csi.storage.k8s.io/node-publish-secret-name: luks
      csi.storage.k8s.io/node-publish-secret-namespace: ${pvc.namespace}
  2. Identifizieren Sie vorhandene Passphrases auf dem Volume oder Snapshot.

    Datenmenge
    tridentctl -d get volume luks-pvc1
    GET http://127.0.0.1:8000/trident/v1/volume/<volumeID>
    
    ...luksPassphraseNames:["A"]
    Snapshot
    tridentctl -d get snapshot luks-pvc1
    GET http://127.0.0.1:8000/trident/v1/volume/<volumeID>/<snapshotID>
    
    ...luksPassphraseNames:["A"]
  3. Aktualisieren Sie das LUKS-Geheimnis für das Volume, um die neuen und vorherigen Passphrases anzugeben. Unbedingt previous-luke-passphrase-name Und previous-luks-passphrase Übereinstimmung mit der vorherigen Passphrase.

    apiVersion: v1
    kind: Secret
    metadata:
      name: luks-pvc1
    stringData:
      luks-passphrase-name: B
      luks-passphrase: secretB
      previous-luks-passphrase-name: A
      previous-luks-passphrase: secretA
  4. Erstellen Sie einen neuen Pod, der das Volume montiert. Dies ist erforderlich, um die Rotation zu initiieren.

  5. Überprüfen Sie, ob die Passphrase gedreht wurde.

    Datenmenge
    tridentctl -d get volume luks-pvc1
    GET http://127.0.0.1:8000/trident/v1/volume/<volumeID>
    
    ...luksPassphraseNames:["B"]
    Snapshot
    tridentctl -d get snapshot luks-pvc1
    GET http://127.0.0.1:8000/trident/v1/volume/<volumeID>/<snapshotID>
    
    ...luksPassphraseNames:["B"]
Ergebnisse

Die Passphrase wurde gedreht, wenn nur die neue Passphrase auf dem Volume und dem Snapshot zurückgegeben wird.

Hinweis Werden beispielsweise zwei Passphrases zurückgegeben luksPassphraseNames: ["B", "A"], Die Rotation ist unvollständig. Sie können einen neuen Pod auslösen, um zu versuchen, die Rotation abzuschließen.

Aktivieren Sie die Volume-Erweiterung

Sie können Volume-Erweiterung auf einem LUKS-verschlüsselten Volume aktivieren.

Schritte
  1. Aktivieren Sie die CSINodeExpandSecret Funktionstor (Beta 1.25+). Siehe "Kubernetes 1.25: Verwenden Sie Secrets zur Node-gesteuerten Erweiterung von CSI Volumes" Entsprechende Details.

  2. Fügen Sie die hinzu node-expand-secret-name Und node-expand-secret-namespace StorageClass-Parameter. Beispiel:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: luks
    provisioner: csi.trident.netapp.io
    parameters:
      selector: "luks=true"
      csi.storage.k8s.io/node-stage-secret-name: luks-${pvc.name}
      csi.storage.k8s.io/node-stage-secret-namespace: ${pvc.namespace}
      csi.storage.k8s.io/node-expand-secret-name: luks-${pvc.name}
      csi.storage.k8s.io/node-expand-secret-namespace: ${pvc.namespace}
    allowVolumeExpansion: true
Ergebnisse

Wenn Sie die Online-Speichererweiterung initiieren, gibt das Kubelet die entsprechenden Zugangsdaten an den Treiber weiter.