Schlüssel und Zertifikate für die Speicherauthentifizierung rotieren

Für die Air-Gap-Appliance von Google Distributed Cloud (GDC) wird ONTAP Select (OTS) als Anbieter für softwaredefinierten Speicher verwendet. OTS hat ein eigenes Authentifizierungssystem, in dem jeder Identität (Kernservice oder Client) ein Name und ein Schlüssel zugeordnet sind.

In diesem Dokument werden die Schritte zum Rotieren der Authentifizierungsschlüssel und ‑zertifikate beschrieben, die für Folgendes ausgeführt werden müssen:

  • regelmäßige Schlüsselrotation, um dafür zu sorgen, dass das Gerät konform und sicher ist.
  • Schlüsseloffenlegung. Sie sollten den offengelegten Schlüssel so schnell wie möglich rotieren.

Hinweise

Sie benötigen die folgenden Zugriffsrechte:

  • Zugriff auf die Admin-Konsole für den ONTAP-Cluster
  • Kubeconfig für den Management API-Server

IPsec-Anmeldedaten (PSK) rotieren

Ab Version 9.10.1 unterstützt ONTAP die zertifikatbasierte Authentifizierung für IPsec. Diese Version von GDC basiert auf 9.14.1 und verwendet vorinstallierte Schlüssel.

Für Appliance wird IPsec für zwei Arten von OTS-Traffic implementiert:

  • Externer Traffic zwischen Bare-Metal-Hosts und SVMs.
  • Interner Traffic zwischen Worker-Knoten.

Wir gehen sie einzeln durch.

Vorbereitung

  • Zugriff auf die Admin-Konsole für den ONTAP-Cluster
  • Ein neuer vorinstallierter Schlüssel
  • Kubeconfig für den Management API-Server
  • Zugriff auf Hosts zum Aktualisieren der StrongSwan-Konfiguration

Auswirkungen

Während IPsec-Richtlinien rotiert werden, verlieren Hosts die IP-Verbindung zum Speichersystem. Verbindungen werden je nach Anwendungsverhalten unterbrochen oder schlagen möglicherweise fehl. Sie können Nutzer-Workloads während der Rotation pausieren, wenn möglich, aber es ist nicht erforderlich. Die Verbindungen sollten kurz nach dem Zurücksetzen der Secrets wiederhergestellt werden.

Schlüsselrotation für externen OTS-Traffic

Verwenden Sie den folgenden Befehl, um die Rotation zu prüfen, und vergleichen Sie die Ausgabe:

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get StorageEncryptionConnections -n gpc-system

Ausgabe:

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-1ba9796c   bm-1ba9796c        root-admin              10.4.4.0/24   bm-1ba9796c-pre-shared-key   True    6h16m
bm-96a5f32a   bm-96a5f32a        root-admin              10.4.4.0/24   bm-96a5f32a-pre-shared-key   True    16h
bm-e07f4a4f   bm-e07f4a4f        root-admin              10.4.4.0/24   bm-e07f4a4f-pre-shared-key   True    21h

Prüfen Sie, ob das Feld READY für den Host, auf dem Sie das Script zuvor ausgeführt haben, „true“ ist.

Rotieren Sie den PSK manuell, wenn Sie bei der Validierung Fehler finden.

  1. Führen Sie folgenden Befehl aus:

    export KUBECONFIG= #path to root-admin kubeconfig

    mgmt_ip="$(kubectl get storagecluster -A -o jsonpath='{.items[0].spec.network.clusterManagement.ip}')"

username="$(kubectl get secret storage-root-level1 -n gpc-system -o jsonpath='{.data.username}' | base64 -d)"

password="$(kubectl get secret storage-root-level1 -n gpc-system -o jsonpath='{.data.password}' | base64 -d)"

  2. Passwort ansehen und in die Zwischenablage kopieren:

    echo $password

  3. Melden Sie sich in der ONTAP-Konsole an:

    ssh $username@$mgmt_ip

    Wenn Sie zur Eingabe eines Passworts aufgefordert werden, fügen Sie das kopierte Passwort aus dem vorherigen Schritt ein.

  4. Verwenden Sie das folgende Script für die Rotation von Anmeldedaten:

    export KUBECONFIG= #path to root-admin kubeconfig

    kubectl get StorageEncryptionConnections -n gpc-system

    Ausgabe:

    NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-1ba9796c   bm-1ba9796c        root-admin              10.4.4.0/24   bm-1ba9796c-pre-shared-key   True    6h16m
bm-96a5f32a   bm-96a5f32a        root-admin              10.4.4.0/24   bm-96a5f32a-pre-shared-key   True    16h
bm-e07f4a4f   bm-e07f4a4f        root-admin              10.4.4.0/24   bm-e07f4a4f-pre-shared-key   True    21h

    Für jeden Host, den Sie rotieren möchten, können Sie Folgendes ausführen:

    export bm_host= //name of bm-host from above
export secret="${bm_host}-pre-shared-key"
export job_name="os-policy-config-host-ipsec-${bm_host}"
export ns="gpc-system"
export svm="$(kubectl get storageencryptionconnections "${bm_host}" -n "${ns}" -o jsonpath='{.spec.storageVirtualMachineRef.name}')"

    Prüfen Sie nun, ob alle Komponenten der Speicherverschlüsselungsverbindung angezeigt werden. Für Administratorclusterverbindungen, entweder Root-Administrator oder Organisationsadministrator, müssen Sie den Root-Administratorcluster verwenden.

    kubectl get secrets -n "${ns}" "${secret}"
kubectl get jobs -n "${ns}" "${job_name}"

    Wenn beide Elemente vorhanden sind, können Sie mit dem nächsten Schritt fortfahren. Ist dies nicht der Fall, halten Sie an und fahren Sie nicht mit der Änderung von IPsec fort. Wenden Sie sich an den technischen Support.

    kubectl delete secrets -n "${ns}" "${secret}"
kubectl delete jobs "${job_name}" -n "${ns}"

    Löschen Sie jetzt mit dem Management API-Server die storageencryptionconnection.

    export KUBECONFIG= #path to root-admin kubeconfig

    kubectl delete storageencryptionconnections "${bm_host}"

annotation_key="reconcile_annotation_key"
annotation_value="reconcile_annotation_value"

kubectl patch storagevirtualmachines "${svm}" -n "${ns}" --type=merge -p "{\"metadata\":{\"annotations\":{\"$annotation_key\":\"$annotation_value\"}}}"
kubectl patch storagevirtualmachines "${svm}" -n "${ns}" --type=json -p="[{\"op\": \"remove\", \"path\": \"/metadata/annotations/$annotation_key\"}]"

    Schlüsselrotation für internen OTS-Traffic

Verwenden Sie den folgenden Befehl, um die Rotation zu validieren, und vergleichen Sie die Ausgabe:

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get secret ots-internal-pre-shared-key -n gpc-system

Ausgabe:

NAME                          TYPE     DATA   AGE
ots-internal-pre-shared-key   Opaque   1      18m

kubectl get jobs -n gpc-system | grep os-policy-config-host-ipsec

Ausgabe:

os-policy-config-host-ipsec-bm-3d33bb857t5bh                Complete   1/1           17s        10m
os-policy-config-host-ipsec-bm-774fa8e6frgr7                Complete   1/1           30s        11m
os-policy-config-host-ipsec-bm-8e452fb29q5wd                Complete   1/1           23s        11m

Prüfen Sie, ob alle Jobs den Status Complete haben.

kubectl get StorageEncryptionConnections -n gpc-system

Ausgabe:

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-3d33bb85   bm-3d33bb85        root-admin              10.4.4.0/24   bm-3d33bb85-pre-shared-key   True    6h16m
bm-774fa8e6   bm-774fa8e6        root-admin              10.4.4.0/24   bm-774fa8e6-pre-shared-key   True    16h
bm-8e452fb2   bm-8e452fb2        root-admin              10.4.4.0/24   bm-8e452fb2-pre-shared-key   True    21h

Prüfen Sie, ob das Feld READY für alle Hosts „true“ ist.

  1. Löschen Sie alle CRs in Schritt 2 in der aufgeführten Reihenfolge.

    • Löschen Sie das Secret für den internen Traffic: sh kubectl delete secret ots-internal-pre-shared-key -n gpc-system.

    • Löschen Sie alle drei Betriebssystemrichtlinien-Jobs. sh kubectl delete jobs os-policy-config-host-ipsec-bm-3d33bb857t5bh -n gpc-system kubectl delete jobs os-policy-config-host-ipsec-bm-774fa8e6frgr7 -n gpc-system kubectl delete jobs os-policy-config-host-ipsec-bm-8e452fb29q5wd -n gpc-system

    • Löschen Sie alle drei storageencryptionconnection sh kubectl delete StorageEncryptionConnections bm-3d33bb85-root-admin -n gpc-system kubectl delete StorageEncryptionConnections bm-774fa8e6-root-admin -n gpc-system kubectl delete StorageEncryptionConnections bm-8e452fb2-root-admin -n gpc-system

  2. Warten Sie einige Minuten (ca. 3–5 Minuten). Wiederholen Sie Schritt 2, bis alle Creative-Anforderungen den Status „BEREIT“ oder „Abgeschlossen“ haben.

Lautstärketasten rotieren

In diesem Abschnitt werden die manuellen Schritte zum Rotieren von OTS-Volume-Anmeldedaten beschrieben.

Hinweise

Gehen Sie folgendermaßen vor:

  1. Prüfen Sie, ob Sie die Voraussetzungen für Laptops erfüllen.
  2. Achten Sie darauf, dass Sie sich über BM01 oder BM02 in der Konsole des OTS-Clusters anmelden können.

Rotation des Volume-Schlüssels einleiten

Lösen Sie in der OTS Console die einmalige Schlüsselrotation aus:

volume encryption rekey start -vserver SVM_name -volume volume_name

Mit dem folgenden Befehl wird der Verschlüsselungsschlüssel für vol1 auf SVMvs1 geändert:

cluster1::> volume encryption rekey start -vserver vs1 -volume vol1

Mit dem Befehl show können Sie die Namen der V‑Server und Volumes aufrufen:

vserver show
volume show

Rotation des Volume-Schlüssels überprüfen

Nachdem die Schlüsselrotation initiiert wurde, prüfen Sie den Status der Neuverschlüsselung:

volume encryption rekey show

Rufen Sie den Status des Vorgangs zum erneuten Verschlüsseln auf:

cluster1::> volume encryption rekey show

Vserver   Volume   Start Time           Status
-------   ------   ------------------   ---------------------------
vs1       vol1     9/18/2017 17:51:41   Phase 2 of 2 is in progress.

Wenn der Vorgang zum erneuten Verschlüsseln abgeschlossen ist, prüfen Sie, ob das Volume für die Verschlüsselung aktiviert ist:

volume show -is-encrypted true

Verschlüsselte Volumes auf cluster1 anzeigen:

cluster1::> volume show -is-encrypted true

Vserver  Volume  Aggregate  State  Type  Size  Available  Used
-------  ------  ---------  -----  ----  -----  --------- ----
vs1      vol1    aggr2     online    RW  200GB    160.0GB  20%

Externe HSM-Zertifikate rotieren

In diesem Abschnitt wird beschrieben, wie Sie die externen HSM-Zertifikate für ONTAP rotieren und aktualisieren.

Vorbereitung

  • Administratorzugriff auf den ONTAP-Cluster oder die relevanten SVMs
  • Aktuelles Passwort
  • kubectl-Zugriff auf die entsprechenden Cluster

Anleitung

  1. Sichern Sie die alten HSM-Zertifikate:

    kubectl get secret aa-aa-external-hsm-creds -n gpc-system -o yaml > external-hsm-creds-old.yaml

  2. Aktualisieren Sie das HSM-Zertifikate-Secret in Kubernetes:

    1. Kopieren Sie die alte YAML-Datei mit dem Secret: sh cp external-hsm-creds-old.yaml external-hsm-creds-new.yaml

    2. Aktualisieren Sie die neue Datei external-hsm-creds-new.yaml mit den neuen HSM-Anmeldedaten, einschließlich des Server-CA-Zertifikats, des öffentlichen Clientzertifikats und des privaten Schlüssels für den Client.

    3. Wenden Sie die Änderung an und aktualisieren Sie das HSM-Secret-Objekt.

      kubectl apply -f external-hsm-creds-new.yaml

  3. Aktualisieren Sie die HSM-Zertifikate in ONTAP:

    1. Melden Sie sich in der ONTAP-CLI an.

    2. Installieren Sie das neue Server-CA-Zertifikat:

      cluster::> security certificate install -type server-ca -vserver <>

    3. Installieren Sie das neue Clientzertifikat:

      cluster::> security certificate install -type client -vserver <>

    4. Aktualisieren Sie die Konfiguration des Schlüsselmanagers, damit die neu installierten Zertifikate verwendet werden:

      cluster::> security key-manager external modify -vserver <> -client-cert <> -server-ca-certs <>

Validierung

  1. Prüfen Sie die Änderung mit dem Schlüsselmanagerstatus:

    cluster::> security key-manager external show-status

    Prüfen Sie, ob sich die Schlüsselserver noch im Status Available befinden.

Anmeldedaten des Speichers rotieren

In diesem Abschnitt wird beschrieben, wie Sie den Speicheradministratornutzer und das zugehörige Passwort rotieren und festlegen.

Vorbereitung

  • Administratorzugriff auf den ONTAP-Cluster oder die relevanten SVMs
  • Aktuelles Passwort
  • kubectl-Zugriff auf die entsprechenden Cluster

Anleitung

  1. Beginnen Sie mit dem folgenden Befehl und folgen Sie dann den Eingabeaufforderungen:

    cluster::> security login password

  2. Aktualisieren Sie das Secret, damit es übereinstimmt:

    • Option 1 (interaktiv):

      kubectl edit secret -n <netapp_namespace> netapp_credential

      Ändern Sie das Passwort im Editor in den neuen base64-codierten Wert.

    • Option 2 (Patch mit jq-Abhängigkeit):

      k get secret -n <netapp_namespace> netapp_credential -o json | jq '.data["password"]="<new-base64-encoded-password>"' | kubectl apply -f -

ONTAP-Anmeldedaten für den Notfallzugriff rotieren

Bei der Einrichtung von Datei- und Blockspeicher werden vier Nutzerkonten mit Notfallzugriff erstellt, mit denen direkt auf ONTAP zugegriffen werden kann. Diese Anmeldedaten können als Secrets auf dem Management API-Server abgerufen werden. Sobald diese Anmeldedaten verwendet wurden, müssen sie rotiert werden.

Während der Einrichtung werden zwei Arten von Secrets erstellt: Ebene 1 und Ebene 2. Level 1 ist storage-root-level1 and storage-root-level1-backup. Level 2 ist storage-root-level2 and storage-root-level2-backup. Geheimnisse der Stufe 2 müssen im Safe gespeichert werden. Jede Stufe hat zwei Geheimnisse: ein normales und ein Backup. Die Software löscht sowohl normale als auch Backup-Secrets gleichzeitig. Wir empfehlen jedoch, aus Sicherheitsgründen immer nur eines dieser Partner-Secrets zu rotieren.

Während Secrets der Stufe 1 nach 90 Tagen automatisch rotiert werden, ist das bei Secrets der Stufe 2 nicht der Fall. Beide Arten von Secrets müssen manuell rotiert werden, wenn sie verwendet werden. Gehen Sie dazu so vor:

Vorbereitung

  • Erforderlicher Zugriff: Management API-Server

Validierung

  1. Die Secret-Rotation kann überprüft werden, indem Sie prüfen, ob das Secret weiterhin als zu löschend markiert ist. Wenn nicht, wurde das Secret rotiert. Folgen Sie Schritt 1 der folgenden Anleitung, um dies zu überprüfen.

  2. Wenn es sich um ein Geheimnis der Stufe 2 handelt, kopieren Sie es auf physische Medien und bewahren Sie es im Safe auf. Das Secret sollte dann mit der Annotation "disk.gdc.goog/persisted" als persistent gekennzeichnet werden.

     kubectl annotate secrets
 <secret_name> -n gpc-system disk.gdc.goog/persisted=''

Folgen Sie der Anleitung unten, um das Secret manuell zu rotieren, wenn Sie bei der Validierung einen Fehler feststellen.

Anleitung

  1. Prüfen, ob ein Secret zum Löschen markiert ist:

    1. Führen Sie dazu diesen Befehl aus:

      kubectl get secret <secret_name> -n gpc-system -o yaml

    2. Wenn das Feld deletionTimestamp wie in diesem Beispiel in der Antwort vorhanden ist, wird das Secret zum Löschen markiert. Andernfalls nicht.

      apiVersion: v1
data:
  password: KFZbQTJdYjIwSUtVVV1aNytJJVM=
  username: cm9vdC1sdmwy
immutable: true
kind: Secret
metadata:
  annotations:
    cluster-name: aa-aa-stge01
  creationTimestamp: "2022-12-21T05:03:02Z"
  deletionGracePeriodSeconds: 0
  deletionTimestamp: "2022-12-21T14:42:13Z"
  finalizers:
  - ontap.storage.private.gdc.goog/breakglass-finalizer
  labels:
    breakglass-secret: "true"
  name: storage-root-level2
  namespace: gpc-system
  resourceVersion: "591897"
  uid: 6f331f8a-bf48-4d59-9725-6c99c5e766f7
type: Opaque

  2. Rotieren Sie das Secret, nachdem Sie damit auf ONTAP zugegriffen haben:

    1. Prüfen Sie, ob die Partneranmeldedaten vorhanden und nicht zum Löschen markiert sind. Fahren Sie nicht fort und kehren Sie zu diesen Schritten zurück, wenn die Datei zur Löschung markiert ist.

    2. Wenn das Secret der Ebene 2 rotiert wird, muss das Partner-Secret als persistent gekennzeichnet werden, indem die Anmerkung disk.gdc.goog/persisted hinzugefügt wird:

      kubectl annotate secrets
<secret_name> -n gpc-system disk.gdc.goog/persisted=''

    3. Löschen Sie das Secret aus dem Cluster mit dem folgenden Befehl:

      kubectl delete
secret <secret_name> -n gpc-system

    4. Der Löschvorgang wird gestartet. Sie können prüfen, ob das Secret zum Löschen markiert ist. Es kann fast eine Stunde dauern, bis das Secret gelöscht und neu generiert wird.

Speicheradministrator- und SVM-Zertifikate rotieren

Diese Zertifikate sind die Serverzertifikate, die von GDC im ONTAP-System installiert werden.

Es gibt ein Zertifikat für den Speicheradministrator, auch bekannt als das Konto des Clusteradministrators. Der Name hat das Präfix des Hostnamens des ONTAP-Systems und einen nachgestellten eindeutigen Hash. Sie wird auf dem VServer des Clusteradministrators installiert. GDC verwendet dieses Zertifikat intern für administrative Aufgaben.

Es gibt auch mehrere serverseitige Zertifikate, die für ONTAP-SVMs definiert sind. Damit wird die Authentizität für Clients hergestellt, die mit den SVMs kommunizieren.

Alle Zertifikate können mit demselben Verfahren rotiert werden. Aufgrund einer Diskrepanz zwischen den Stammzertifizierungsstellen im Root-Administratorcluster ist für die in den folgenden Tabellen aufgeführten Cluster- und SVM-Zertifikate eine Rotation aller Zertifikate in der jeweiligen Liste erforderlich. Das bedeutet, dass bei Bedarf alle anderen Clusterzertifikate ebenfalls rotiert werden müssen. Dasselbe gilt für SVM-Zertifikate. Diese Einschränkung wird aufgehoben, sobald die automatische Zertifikatsverwaltung implementiert ist.

Vorbereitung

  • Administratorzugriff auf den ONTAP-Cluster oder die relevanten SVMs
  • kubectl-Zugriff auf die entsprechenden Kubernetes-Cluster
  • Installieren Sie die Client-CA-Zertifikate neu, wie in der Installationsanleitung für Client-CA-Zertifikate beschrieben.

Zuordnung zwischen Zertifikaten und Kubernetes-Secrets

Für jedes in ONTAP installierte Zertifikat gibt es ein entsprechendes Kubernetes-Secret auf dem Management API-Server, das die Zertifikatsdetails enthält. GDC generiert die Zertifikate. Das Ersetzen eines Zertifikats ist ganz einfach: Löschen Sie das Secret, das dem jeweiligen Zertifikat entspricht, und das Zertifikat wird sofort neu generiert. Das neue Zertifikat kann dann manuell in ONTAP installiert werden und ersetzt das alte.

Verwenden Sie kubectl get secrets -n <namespace> -s <secret> -o yaml, um das Zertifikat in Kubernetes zu prüfen und zu bestätigen, dass es mit den Details in ONTAP übereinstimmt, die über security certificate show -vserver <svm_name> angezeigt werden. Der Namespace ist immer „gpc-system“. Den Namen des Secrets finden Sie in der folgenden Tabelle.

Sie können die Zuordnung von Zertifikat zu Secret auch so prüfen:

kubectl get certificates -n <namespace>

Relevante Clusterzertifikate

ONTAP-Common-Name Vserver K8S-Zertifikatsname Name des Kubernetes-Secrets Beschreibung
– <hostname> <hostname>-admin-cert <hostname>-admin-cert-secret Clusteradministratorzertifikat
– <hostname> <hostname>-server-cert <hostname>-server-cert-secret Das Serverzertifikat ist vom GDC-Aussteller signiert und wird als ONTAP-Serverzertifikat verwendet.
– <hostname> <hostname>-read-only-cert <hostname>-read-only-cert-secret Lesezugriff für Monitoring

Relevante SVM-Zertifikate

Vserver K8S-Zertifikatsname Name des Kubernetes-Secrets Beschreibung
root-admin root-admin-server-cert root-admin-server-cert-secret Das Serverzertifikat ist vom GDC-Aussteller signiert, der als SVM-Serverzertifikat verwendet wird.
root-admin root-admin-s3-server-cert root-admin-s3-server-cert-secret Vom GDC-Aussteller signiertes Serverzertifikat, das als ONTAP-S3-Serverzertifikat verwendet wird
root-admin root-admin-client-cert root-admin-client-cert-secret Zugriff durch SVM-Administrator
root-admin root-admin-s3-identity-client-cert root-admin-s3-identity-client-cert-secret S3-Identitätszugriff

Validierung

Vserver-Zertifikat

Nachdem alle Zertifikate rotiert wurden, prüfen Sie, ob das Trident-Backend für jeden Cluster, der dem rotierten Serverzertifikat zugeordnet ist, weiterhin erfolgreich verbunden ist.

  1. Führen Sie Folgendes aus:

    export KUBECONFIG= #path to root-admin kubeconfig

    kubectl get tridentbackendconfigs -n netapp-trident

    Die Ausgabe sollte so aussehen:

    NAME                                   BACKEND NAME   BACKEND UUID                           PHASE   STATUS
netapp-trident-backend-tbc-ontap-san   iscsi-san      a46ce1c7-26da-42c9-b475-e5e37a0911f8   Bound   Success

  2. Prüfen Sie, ob PHASE den Wert Bound und Status den Wert Success hat.

Root-Administratorzertifikat

Um das Administratorzertifikat zu testen, können wir eine neue StorageVirtualMachine erstellen und prüfen, ob GDC sie richtig abgleichen kann. Dazu sind die folgenden Schritte auszuführen:

  1. Listen Sie die vorhandenen StorageVirtualMachines auf und wählen Sie eine zum Klonen als Test aus.
  2. Extrahieren Sie die Kubernetes-Spezifikation dafür.
  3. Bearbeiten Sie die Definition, um den Namen zu ändern und unnötige Felder zu löschen.
  4. Wenden Sie die Testdefinition an.
  5. Warten Sie, bis der Status der StorageVirtualMachine Ready lautet.
  6. Löschen Sie die StorageVirtualMachine für den Test.
  7. Löschen Sie die tatsächliche SVM aus ONTAP.

Beispiel

In diesem Beispiel wird der GDC NetApp-Namespace gpc-system verwendet und organization-root-user wird vorübergehend in eine neue SVM namens test-svm geklont.

  1. SVMs auflisten:

    kubectl get storagevirtualmachines -n ngpc-system

    Ausgabe:

    NAME                      AGE
organization-root-admin   13d

  2. Extrahieren Sie die Spezifikation:

    kubectl get storagevirtualmachines -n gpc-system -o yaml > svm.yaml

  3. Bearbeiten Sie die Spezifikation so, dass sie in etwa so aussieht:

    apiVersion: system.gpc.gke.io/v1alpha1
kind: StorageVirtualMachine
metadata:
  labels:
    ontap.storage.gpc.gke.io/role: user
  name: test-svm
  namespace: netapp-alatl12-gpcstge02
spec:
  aggregates:
  - alatl12-gpcstge02-c1-aggr1
  - alatl12-gpcstge02-c2-aggr1
  clusterName: alatl12-gpcstge02
  iscsiTarget:
    port: a0a-4
    subnetName: root-svm-data
  nasServer:
    port: a0a-4
    subnetName: root-svm-data
  svmNetwork:
    port: e0M
    subnetName: Default

  4. Wenden Sie es auf den Cluster an:

    kubectl create -f svm.yaml

  5. Warten Sie, bis die neue SVM bereit ist. Beobachten Sie regelmäßig die Ausgabe von:

    kubectl get storagevirtualmachines -n gpc-system test-svm

    Eine erfolgreiche Ausführung ist daran zu erkennen, dass

      Conditions:
    Last Transition Time:  2022-03-30T21:30:27Z
    Message:
    Observed Generation:   1
    Reason:                SVMCreated
    Status:                True
    Type:                  Ready

    oder AnsibleJobSucceed.

  6. Löschen Sie die SVM-Ressource:

    kubectl delete storagevirtualmachines -n gpc-system test-svm

  7. Löschen Sie sie vollständig aus ONTAP. Wenn Sie die Ressource löschen, wird sie nicht aus ONTAP entfernt.

    Melden Sie sich in der NetApp-Konsole an und löschen Sie die SVM:

    alatl12-gpcstge02::> vserver delete test-svm

    Ausgabe:

    Warning: When Vserver "test-svm" is deleted,
        the following objects are automatically removed as well:
        LIFs: 7
        Routes: 2
        Admin-created login accounts: 2
        Do you want to continue? {y|n}: y
[Job 3633] Success

Folgen Sie der Anleitung unten, um das ONTAP-Zertifikat manuell zu rotieren, wenn bei der Validierung ein Fehler auftritt.

Anleitung

Wenn der vorherige ONTAP-Zertifikatsname nicht zutrifft, muss in ONTAP nichts rotiert werden. Prüfen Sie das Zertifikat und das Secret in Kubernetes und löschen Sie das Secret.

  1. Generieren Sie ein neues Zertifikat und verweisen Sie dabei auf die vorherige Tabelle für den Secret-Namen:

    kubectl get certificates -n <namespace>

    $ kubectl patch Certificates <cert_name> -n gpc-system \
 --type=merge -p "{\"spec\":{\"privateKey\": {\"rotationPolicy\": \"Always\"}}}"
$ kubectl delete secret -n <namespace> <secret_name>

  2. So rufen Sie die installierten Zertifikate für einen bestimmten Vserver ab, für Zertifikate, die in ONTAP installiert sind (nicht als „nicht zutreffend“ gekennzeichnet):

    cluster::> security certificate show -vserver <svm_name> -type server

  3. Sehen Sie sich das entsprechende Secret in Kubernetes an (siehe Tabelle oben):

    kubectl get certificates -n <namespace>

  4. Wenn Sie mit dem Ergebnis zufrieden sind, löschen Sie das Secret, um ein neues Zertifikat zu generieren:

    kubectl delete secret -n <namespace> <secret_name>

  5. Prüfen Sie das Secret noch einmal, um zu sehen, ob ein neues Zertifikat neu generiert wurde. Erstellen Sie nach der Bestätigung ein neues Serverzertifikat in ONTAP. Führen Sie die folgenden Schritte nur für die oben genannten Zertifikate mit dem Suffix „server-cert“ aus.

  6. Extrahieren Sie den neuen TLS-Zertifikatskörper direkt mit kubectl und anderen Tools und installieren Sie ihn in ONTAP:

    $ gdch_cert_details -n <namespace> -s <secret_name>

cluster::> security certificate install -vserver <svm_name> -type server

    Der erste Prompt lautet:

    Please enter Certificate: Press <Enter> when done

    Geben Sie dort tls.crt ein. Wenn es in tls.crt mehrere Zertifikatsblöcke gibt, geben Sie den ersten Block ein und behalten Sie die verbleibenden Zertifikatsblöcke als Zwischenzertifikate für den nächsten Schritt bei.

  7. Das System fordert Sie auf: Please enter Private Key: Press <Enter> when done. Fügen Sie den Inhalt Ihrer tls.key-Datei ein und drücken Sie die Eingabetaste.

    Als Nächstes werden Sie aufgefordert: Do you want to continue entering root and/or intermediate certificates {y|n}: Wenn Ihre tls.crt-Datei nur ein einzelnes Zertifikat enthält, geben Sie N ein und drücken Sie die Eingabetaste. Geben Sie andernfalls Y ein und drücken Sie die Eingabetaste.

    Wenn Sie Y eingegeben haben:Sie werden aufgefordert, Zwischenzertifikate einzugeben. Fügen Sie sie einzeln aus Ihrer tls.crt-Datei ein und drücken Sie nach jeder Eingabe die Eingabetaste. Fügen Sie das Root-Zertifikat aus Ihrer ca.crt-Datei ein und drücken Sie die Eingabetaste.

    Wenn Sie N eingegeben haben: (Für diese Aufforderung sind keine weiteren Maßnahmen in Bezug auf Zertifikate erforderlich.)

    ONTAP gibt dann eine Seriennummer zurück. Notieren Sie sich diese Nummer, da sie die Seriennummer des neuen Zertifikats und der neuen Zertifizierungsstelle darstellt. Diese Seriennummer wird in den folgenden Schritten als <new\_server\_serial> und <new\_ca> bezeichnet. Führen Sie diese Schritte für Zertifikate nicht aus, wenn Sie ein S3-Serverzertifikat konfigurieren.

  8. Den aktuellen Status der SSL-Konfigurationen für den VServer und den Cluster ansehen. Halten Sie die CA für die Ausstellung von Serverzertifikaten, den allgemeinen Namen des Serverzertifikats und die Seriennummer des Serverzertifikats bereit, da sie als <old\_server\_common\_name>, <old\_ca> bzw. <old\_server\_serial> bezeichnet werden:

    cluster::> security ssl show -vserver <vserver>

    Dadurch werden die SSL-Informationen mit den alten Serverzertifikatsinformationen zurückgegeben. Sie können später darauf verweisen, um sicherzustellen, dass sie aktualisiert wurden, nachdem Sie die SSL-Konfiguration geändert haben.

  9. SSL-Konfiguration ändern:

    cluster::> security ssl modify -server-enabled -client-enabled true -vserver <svm_name> -serial <new_server_serial> -ca <new_ca>

  10. Sehen Sie sich den neuen Status der SSL-Konfigurationen für den VServer und den Cluster an. Hier sollte die aktualisierte Seriennummer für das jetzt installierte Serverzertifikat angezeigt werden:

    cluster::> security ssl show -vserver <vserver>

  11. Löschen Sie das alte Serverzertifikat, nachdem Sie den vorherigen Schritt ausgeführt haben:

    cluster::> security certificate delete -vserver <svm_name> -common-name <old_server_common_name> -ca <old_ca> -type server -serial <old_server_serial>

Client-CA-Zertifikate

  1. Rufen Sie alle Zertifizierungsstellenzertifikate aus der trust-store-internal-only-ConfigMap im Namespace gpc-system mit dem folgenden Befehl ab:

    kubectl get cm -n gpc-system trust-store-internal-only -o jsonpath='{.data.ca\.crt}'

  2. Führen Sie für jedes im vorherigen Schritt abgerufene CA-Zertifikat den folgenden Befehl in Ihrem ONTAP-Cluster aus:

    cluster::> security certificate install -vserver <svm_name> -type client-ca

    Sie werden aufgefordert: Please enter Certificate: Press <Enter> when done. Fügen Sie jeden in Schritt 1 abgerufenen Zertifikatsblock ein und drücken Sie die Eingabetaste. Wiederholen Sie diesen Installationsbefehl für jedes CA-Zertifikat.

Harvest-Zertifikate rotieren

Die Erstellung von Erntezertifikaten hängt von <hostname>-read-only-cert-secret ab. Achten Sie darauf, dass <hostname>-read-only-cert-secret gedreht wird, bevor Sie fortfahren.

  1. So rufen Sie die installierten Zertifikate für den Harvest-Pod auf:

    export KUBECONFIG= #path to root-admin kubeconfig

    cluster_name="$(kubectl get storagecluster -A -o jsonpath='{.items[0].metadata.name}')"
secret_name="$cluster_name"-read-only-cert-secret

    export TLS_CRT="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.tls\.crt}')"

    export TLS_KEY="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.tls\.key}')"

    export CA_CRT="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.ca\.crt}')"

  2. Patchen Sie das Secret für die Harvest-Anmeldedaten, um die aktualisierten Zertifikate bereitzustellen:

    $ kubectl patch secret \
-n gpc-system netapp-harvest-configuration-credential \
-p "{\"data\":{\"tls.crt\":\"${TLS_CRT:?}\",\"tls.key\":\"${TLS_KEY:?}\",\"ca.crt\":\"${CA_CRT:?}\"}}"

  3. Starten Sie den Harvest-Dienst neu, um die aktualisierte Konfiguration zu laden:

    kubectl delete pod -n gpc-system -l 'app=harvest.netapp.io'

Dateisystemzertifikate rotieren

Führen Sie den folgenden Befehl aus, um das file-storage-webhooks-serving-cert- und das file-observability-backend-target-cert-Zertifikat neu zu generieren.

kubectl delete secret file-storage-webhooks-serving-cert -n file-system
kubectl delete secret file-observability-backend-target-cert -n file-system

Starten Sie die Pods neu, um die aktualisierte Konfiguration zu laden:

kubectl delete pod -n file-system -l 'app=file-observability-backend-controller'
kubectl delete pod file-storage-backend-controller -n file-system

Trident- und ONTAP-Zertifikate rotieren

Trident muss mit ONTAP kommunizieren. Dies wird mit dem Trident-Backend konfiguriert, das das zuvor definierte Clientzertifikat <svm\_name>-client-cert-secret> verwendet. Die Rotation von Clientzertifikaten ist nicht Teil von Trident, aber Trident verwendet Teile dieses Zertifikats, die aktualisiert werden müssen.

Anleitung

Für die Aktualisierung des CA-Zertifikats:

  1. Exportieren Sie KUBECONFIG, damit es auf die kubeconfig-Datei für den Cluster verweist, der für die betreffenden Trident-Komponenten spezifisch ist. Auf jedem Cluster ist Trident konfiguriert.

  2. Rufen Sie das Base64-codierte CA-Zertifikat aus dem Secret „client-cert“ ab und speichern Sie es als Variable:

    ca_cert=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.ca\.crt}')

  3. Patchen Sie das tridentBackendConfig-Objekt:

    kubectl patch tridentBackendConfigs netapp-trident-backend-tbc-ontap-san -n netapp-trident --type=merge -p "{\"spec\":{\"trustedCACertificate\":\"$ca_cert\"}}"

Für das eigentliche Clientzertifikat und den Schlüssel:

  1. Rufen Sie das TLS-Zertifikat, Base64-codiert aus dem Secret „client-cert“, ab und speichern Sie es als Variable:

    tls_cert=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.tls\.crt}')

  2. Rufen Sie den TLS-Schlüssel ab, der aus dem Secret für das Clientzertifikat base64-doppelt codiert wurde, und speichern Sie ihn als Variable:

    tls_key=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.tls\.key}' | base64 -w 0)

  3. Aktualisieren Sie das Backend-Secret mit dem privaten Schlüssel:

    kubectl patch secrets netapp-trident-backend-tbc-ontap -n netapp-trident --type=merge -p "{\"data\":{\"clientPrivateKey\": \"$tls_key\"}}"

  4. Patchen Sie die Backend-Konfiguration mit dem TLS-Zertifikat:

    kubectl patch tridentBackendConfigs netapp-trident-backend-tbc-ontap-san -n netapp-trident --type=merge -p "{\"spec\":{\"clientCertificate\":\"$tls_cert\"}}"

Trident-Controller-Zertifikate rotieren

Die Trident-Container müssen mit dem Trident-Operator kommunizieren. Die Kommunikation erfolgt über HTTPS und Server- und Clientzertifikate müssen als Teil davon verwaltet werden.

Validierung

Prüfen Sie, ob sowohl das DaemonSet als auch das Deployment (falls zutreffend) in einem fehlerfreien Zustand sind.

Folgen Sie der Anleitung unten, um Server- und Clientzertifikate manuell zu rotieren, wenn Sie bei der Validierung Fehler feststellen.

Anleitung

Sowohl das Server- als auch das Clientzertifikat haben kein entsprechendes Zertifikat auf der ONTAP-Seite. Diese sind ausschließlich in den Clustern enthalten.

  1. Löschen Sie das Secret, das dem Zertifikat entspricht, das abläuft.

    kubectl delete secret -n netapp-trident <secret_name>

  2. Starten Sie das DaemonSet „netapp-trident-csi“ neu:

    kubectl rollout restart daemonset netapp-trident-csi -n netapp-trident

  3. Bei der Rotation von Serverzertifikaten müssen Sie auch die netapp-trident-csi-Bereitstellung neu starten:

    kubectl rollout restart deployments netapp-trident-csi -n netapp-trident

Trident-CA-Zertifikat

Das CA-Zertifikat wird verwendet, um die Zertifizierungsstelle zum Signieren der Trident-Server- und Clientzertifikate bereitzustellen.

Name des Zertifikats Namespace Secret Beschreibung
netapp-trident-csi-cert netapp-trident netapp-trident-csi-cert Trident CA Cert

Validierung

Sie sehen, dass das Secret neu generiert wurde. Damit die Client- und Serverzertifikate wirksam werden, können Sie auch die Trident-Controller-Zertifikate gemäß der vorherigen Anleitung rotieren, nachdem Sie dieses Zertifikat rotiert haben.

Folgen Sie der Anleitung unten, um das CA-Zertifikat manuell zu rotieren, wenn bei der Validierung ein Fehler auftritt.

Anleitung

Um diesen Schlüssel zu rotieren, müssen Sie das Secret nur aus Kubernetes löschen:

kubectl delete secret -n netapp-trident <secret_name>

Trident-CSI-Knoten und SVMs (Daten)

Dies ist ein SVM-weiter Satz von iSCSI-CHAP-Anmeldedaten, um den Zugriff auf die Datenebene für den Blockzugriff zu ermöglichen. Dies gilt nicht für Dateiprotokolle.

Management API-Server

Namespace Secret Beschreibung
gpc-system <organization>-<type>-svm-credential Für die Einrichtung von Trident erforderliche SVM-Konfiguration

Organisationsadministrator und Management API-Server

Namespace Secret Beschreibung
gpc-system <organization>-<type>-svm-credential Für die Einrichtung von Trident erforderliche SVM-Konfiguration
netapp-trident netapp-trident-backend-tbc-ontap Secret für die Verwaltung des Trident-Back-Ends erforderlich

Validierung

  1. Prüfen Sie, ob das Backend weiterhin erfolgreich konfiguriert ist:

    #export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

kubectl get tridentBackendConfigs -n netapp-trident

  2. Prüfen Sie, ob der Backend-Status Success lautet.

Folgen Sie der Anleitung unten, um die Secrets manuell zu rotieren, wenn bei der Validierung Fehler auftreten.

Anleitung

Generieren Sie für das Initiator-Secret und das Ziel-Initiator-Secret jeweils einen neuen zufälligen String mit 16 Zeichen ohne Sonderzeichen:

#export kubeconfig of Management API server
export KUBECONFIG= #path to root-admin kubeconfig

initiator_secret=$(head /dev/random | tr -dc A-Za-z0-9 | head -c16 | base64)

target_secret=$(head /dev/random | tr -dc A-Za-z0-9 | head -c16 | base64)

kubectl patch secrets -n gpc-system "$org-$type-svm-credential" --type=merge -p "{\"data\":{\"initiatorSecret\": \"$initiator_secret\", \"targetSecret\": \"$target_secret\"}}"

#export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

kubectl patch secrets -n netapp-trident netapp-trident-backend-tbc-ontap --type=merge -p "{\"data\":{\"chapInitiatorSecret\": \"$initiator_secret\", \"chapTargetInitiatorSecret\": \"$target_secret\"}}"

Trident-AES-Schlüssel

Der AES-Schlüssel wird intern von Trident verwendet, um iSCSI CHAP-Anmeldedaten für die interne Verwendung von Trident zu verschlüsseln. Es handelt sich um eine zufällige Zeichenfolge mit einer Länge von 32 Byte.

Cluster mit Trident (können Root-, Organisationsadministrator-, Nutzer- oder Systemcluster sein)

Namespace Secret Beschreibung
netapp-trident netapp-trident-aes-key AES-Schlüssel, der von Trident zum Verschlüsseln von iSCSI-CHAP-Anmeldedaten benötigt wird

Validierung

  1. Prüfen Sie, ob das Backend weiterhin richtig konfiguriert ist:

    #export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

kubectl get tridentBackendConfigs -n netapp-trident

  2. Prüfen Sie, ob der Backend-Status Success lautet.

  3. Versuch, ein Test-Volume zu erstellen:

    1. Erstellen Sie eine YAML-Datei mit den PVC-Informationen:

      echo "
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard-rwo" > pvc.yaml

    2. Wenden Sie es auf den Kubernetes-Cluster an:

      kubectl apply -f pvc.yaml

  4. Prüfen Sie, ob in den CSI-Logs Fehler aufgrund der iSCSI-Verschlüsselung vorhanden sind:

    kubectl logs deploy/netapp-trident-csi -n netapp-trident -c trident-main | grep "Error encrypting"

    Wenn keine Fehler aufgetreten sind, werden keine Logs zurückgegeben.

  5. Datei und PVC bereinigen:

    kubectl delete -f pvc.yaml
rm -f pvc.yaml

Folgen Sie der Anleitung unten, um den Schlüssel manuell zu rotieren, wenn Sie bei der Validierung einen Fehler finden.

Anleitung

Prüfen Sie vor der Rotation dieses Schlüssels, ob im Cluster ausstehende Pods mit persistenten Volumes vorhanden sind. Wenn ja, warten Sie, bis sie vollständig bereitgestellt sind, bevor Sie den Schlüssel rotieren.

Generieren Sie einen neuen zufälligen String mit einer Länge von 32 Zeichen ohne Sonderzeichen für den aesKey:

#export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

aes_key=$(head /dev/random | tr -dc A-Za-z0-9 | head -c32 | base64)

#save old key just in case of errors
old_key=$(kubectl get secrets -n netapp-trident "netapp-trident-aes-key" -o jsonpath='{.data.aesKey}')

kubectl patch secrets -n netapp-trident "netapp-trident-aes-key" --type=merge -p "{\"data\":{\"aesKey\": \"$aes_key\"}}"

kubectl rollout restart deployment netapp-trident-csi -n netapp-trident

Rollback

  1. Bei Fehlern ein Rollback auf die zuletzt verwendeten Anmeldedaten durchführen:

    kubectl patch secrets -n netapp-trident "netapp-trident-aes-key" --type=merge -p "{\"data\":{\"aesKey\": \"$old_key\"}}"

kubectl rollout restart deployment netapp-trident-csi -n netapp-trident

  2. Wiederholen Sie die Bestätigungsschritte.