Vorbereiten der Back-End-Konfiguration mit ONTAP-SAN-Treibern
Verstehen Sie die Anforderungen und Authentifizierungsoptionen für die Konfiguration eines ONTAP-Backends mit ONTAP-SAN-Treibern.
Anforderungen
Für alle ONTAP Back-Ends benötigt Astra Trident mindestens ein Aggregat, das der SVM zugewiesen ist.
Denken Sie daran, dass Sie auch mehr als einen Treiber ausführen können und Speicherklassen erstellen können, die auf den einen oder anderen verweisen. Sie können beispielsweise eine Klasse konfigurieren san-dev
, die den ontap-san
Treiber und eine san-default
Klasse verwendet, die diesen verwendet ontap-san-economy
.
Alle Kubernetes-Worker-Nodes müssen über die entsprechenden iSCSI-Tools verfügen. Weitere Informationen finden Sie unter "Bereiten Sie den Knoten „Worker“ vor" .
Authentifizieren Sie das ONTAP-Backend
Astra Trident bietet zwei Arten der Authentifizierung eines ONTAP-Backend.
-
Anmeldeinformationsbasiert: Benutzername und Passwort für einen ONTAP-Benutzer mit den erforderlichen Berechtigungen. Es wird empfohlen, eine vordefinierte Sicherheits-Login-Rolle zu verwenden, wie
admin
odervsadmin
, um maximale Kompatibilität mit ONTAP-Versionen zu gewährleisten. -
Zertifikatsbasiert: Astra Trident kann auch mit einem ONTAP Cluster kommunizieren. Verwenden Sie dazu ein Zertifikat, das auf dem Backend installiert ist. Hier muss die Backend-Definition Base64-kodierte Werte des Client-Zertifikats, des Schlüssels und des vertrauenswürdigen CA-Zertifikats enthalten, sofern verwendet (empfohlen).
Sie können vorhandene Back-Ends aktualisieren, um zwischen auf Anmeldeinformationen basierenden und zertifikatbasierten Methoden zu verschieben. Es wird jedoch immer nur eine Authentifizierungsmethode unterstützt. Um zu einer anderen Authentifizierungsmethode zu wechseln, müssen Sie die vorhandene Methode von der Backend-Konfiguration entfernen.
Wenn Sie versuchen, sowohl Anmeldeinformationen als auch Zertifikate bereitzustellen, schlägt die Backend-Erstellung mit einem Fehler fehl, dass mehr als eine Authentifizierungsmethode in der Konfigurationsdatei angegeben wurde. |
Aktivieren Sie die Anmeldeinformationsbasierte Authentifizierung
Astra Trident erfordert die Zugangsdaten für einen Administrator mit SVM-Umfang/Cluster-Umfang, um mit dem Backend von ONTAP zu kommunizieren. Es wird empfohlen, standardmäßige, vordefinierte Rollen wie oder vsadmin`zu verwenden `admin
. So ist gewährleistet, dass die Kompatibilität mit künftigen ONTAP Versionen gewährleistet ist, die FunktionsAPIs der künftigen Astra Trident Versionen bereitstellen können. Eine benutzerdefinierte Sicherheits-Login-Rolle kann mit Astra Trident erstellt und verwendet werden, wird aber nicht empfohlen.
Eine Beispiel-Back-End-Definition sieht folgendermaßen aus:
--- version: 1 backendName: ExampleBackend storageDriverName: ontap-san managementLIF: 10.0.0.1 svm: svm_nfs username: vsadmin password: password
{ "version": 1, "backendName": "ExampleBackend", "storageDriverName": "ontap-san", "managementLIF": "10.0.0.1", "svm": "svm_nfs", "username": "vsadmin", "password": "password" }
Beachten Sie, dass die Backend-Definition der einzige Ort ist, an dem die Anmeldeinformationen im reinen Text gespeichert werden. Nach der Erstellung des Backend werden Benutzernamen/Passwörter mit Base64 codiert und als Kubernetes Secrets gespeichert. Die Erstellung oder Aktualisierung eines Backend ist der einzige Schritt, der Kenntnisse über die Anmeldeinformationen erfordert. Daher ist dieser Vorgang nur für Administratoren und wird vom Kubernetes-/Storage-Administrator ausgeführt.
Aktivieren Sie die zertifikatbasierte Authentifizierung
Neue und vorhandene Back-Ends können ein Zertifikat verwenden und mit dem ONTAP-Back-End kommunizieren. In der Backend-Definition sind drei Parameter erforderlich.
-
ClientCertificate: Base64-codierter Wert des Clientzertifikats.
-
ClientPrivateKey: Base64-kodierte Wert des zugeordneten privaten Schlüssels.
-
Trusted CACertificate: Base64-codierter Wert des vertrauenswürdigen CA-Zertifikats. Bei Verwendung einer vertrauenswürdigen CA muss dieser Parameter angegeben werden. Dies kann ignoriert werden, wenn keine vertrauenswürdige CA verwendet wird.
Ein typischer Workflow umfasst die folgenden Schritte.
-
Erzeugen eines Clientzertifikats und eines Schlüssels. Legen Sie beim Generieren den allgemeinen Namen (CN) für den ONTAP-Benutzer fest, der sich authentifizieren soll als.
openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -keyout k8senv.key -out k8senv.pem -subj "/C=US/ST=NC/L=RTP/O=NetApp/CN=admin"
-
Fügen Sie dem ONTAP-Cluster ein vertrauenswürdiges CA-Zertifikat hinzu. Dies kann möglicherweise bereits vom Storage-Administrator übernommen werden. Ignorieren, wenn keine vertrauenswürdige CA verwendet wird.
security certificate install -type server -cert-name <trusted-ca-cert-name> -vserver <vserver-name> ssl modify -vserver <vserver-name> -server-enabled true -client-enabled true -common-name <common-name> -serial <SN-from-trusted-CA-cert> -ca <cert-authority>
-
Installieren Sie das Client-Zertifikat und den Schlüssel (von Schritt 1) auf dem ONTAP-Cluster.
security certificate install -type client-ca -cert-name <certificate-name> -vserver <vserver-name> security ssl modify -vserver <vserver-name> -client-enabled true
-
Vergewissern Sie sich, dass die ONTAP-Sicherheits-Anmeldungsrolle die Authentifizierungsmethode unterstützt
cert
.security login create -user-or-group-name admin -application ontapi -authentication-method cert security login create -user-or-group-name admin -application http -authentication-method cert
-
Testen Sie die Authentifizierung mithilfe des generierten Zertifikats. <ONTAP Management LIF> und <vServer Name> durch Management-LIF-IP und SVM-Namen ersetzen.
curl -X POST -Lk https://<ONTAP-Management-LIF>/servlets/netapp.servlets.admin.XMLrequest_filer --key k8senv.key --cert ~/k8senv.pem -d '<?xml version="1.0" encoding="UTF-8"?><netapp xmlns="http://www.netapp.com/filer/admin" version="1.21" vfiler="<vserver-name>"><vserver-get></vserver-get></netapp>'
-
Encodieren von Zertifikat, Schlüssel und vertrauenswürdigem CA-Zertifikat mit Base64.
base64 -w 0 k8senv.pem >> cert_base64 base64 -w 0 k8senv.key >> key_base64 base64 -w 0 trustedca.pem >> trustedca_base64
-
Erstellen Sie das Backend mit den Werten, die aus dem vorherigen Schritt ermittelt wurden.
cat cert-backend.json { "version": 1, "storageDriverName": "ontap-san", "backendName": "SanBackend", "managementLIF": "1.2.3.4", "svm": "vserver_test", "clientCertificate": "Faaaakkkkeeee...Vaaalllluuuueeee", "clientPrivateKey": "LS0tFaKE...0VaLuES0tLS0K", "trustedCACertificate": "QNFinfO...SiqOyN", "storagePrefix": "myPrefix_" } tridentctl create backend -f cert-backend.json -n trident +------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +------------+----------------+--------------------------------------+--------+---------+ | SanBackend | ontap-san | 586b1cd5-8cf8-428d-a76c-2872713612c1 | online | 0 | +------------+----------------+--------------------------------------+--------+---------+
Aktualisieren Sie Authentifizierungsmethoden, oder drehen Sie die Anmeldedaten
Sie können ein vorhandenes Backend aktualisieren, um eine andere Authentifizierungsmethode zu verwenden oder ihre Anmeldedaten zu drehen. Das funktioniert auf beide Arten: Back-Ends, die einen Benutzernamen/ein Passwort verwenden, können aktualisiert werden, um Zertifikate zu verwenden; Back-Ends, die Zertifikate verwenden, können auf Benutzername/Passwort-basiert aktualisiert werden. Dazu müssen Sie die vorhandene Authentifizierungsmethode entfernen und die neue Authentifizierungsmethode hinzufügen. Verwenden Sie dann die aktualisierte Datei Backend.json, die die erforderlichen Parameter enthält tridentctl backend update
.
cat cert-backend-updated.json { "version": 1, "storageDriverName": "ontap-san", "backendName": "SanBackend", "managementLIF": "1.2.3.4", "svm": "vserver_test", "username": "vsadmin", "password": "password", "storagePrefix": "myPrefix_" } #Update backend with tridentctl tridentctl update backend SanBackend -f cert-backend-updated.json -n trident +------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +------------+----------------+--------------------------------------+--------+---------+ | SanBackend | ontap-san | 586b1cd5-8cf8-428d-a76c-2872713612c1 | online | 9 | +------------+----------------+--------------------------------------+--------+---------+
Bei der Änderung von Passwörtern muss der Speicheradministrator das Kennwort für den Benutzer auf ONTAP aktualisieren. Auf diese Weise folgt ein Backend-Update. Beim Drehen von Zertifikaten können dem Benutzer mehrere Zertifikate hinzugefügt werden. Das Backend wird dann aktualisiert und verwendet das neue Zertifikat. Danach kann das alte Zertifikat aus dem ONTAP Cluster gelöscht werden. |
Durch die Aktualisierung eines Backend wird der Zugriff auf Volumes, die bereits erstellt wurden, nicht unterbrochen, und auch die danach erstellten Volume-Verbindungen werden beeinträchtigt. Ein erfolgreiches Backend-Update zeigt, dass Astra Trident mit dem ONTAP-Backend kommunizieren und zukünftige Volume-Operationen verarbeiten kann.
Verbindungen mit bidirektionalem CHAP authentifizieren
Astra Trident kann iSCSI-Sitzungen mit bidirektionalem CHAP für die und ontap-san-economy
-Treiber authentifizieren ontap-san
. Dazu muss die Option in Ihrer Backend-Definition aktiviert useCHAP
werden. Bei Einstellung auf true
konfiguriert Astra Trident die standardmäßige Initiatorsicherheit der SVM auf bidirektionales CHAP und legt den Benutzernamen und die Schlüssel aus der Backend-Datei fest. NetApp empfiehlt die Verwendung von bidirektionalem CHAP zur Authentifizierung von Verbindungen. Die folgende Beispielkonfiguration ist verfügbar:
--- version: 1 storageDriverName: ontap-san backendName: ontap_san_chap managementLIF: 192.168.0.135 svm: ontap_iscsi_svm useCHAP: true username: vsadmin password: password chapInitiatorSecret: cl9qxIm36DKyawxy chapTargetInitiatorSecret: rqxigXgkesIpwxyz chapTargetUsername: iJF4heBRT0TCwxyz chapUsername: uh2aNCLSd6cNwxyz
Der useCHAP Parameter ist eine Boolesche Option, die nur einmal konfiguriert werden kann. Die Standardeinstellung ist „false“. Nachdem Sie die Einstellung auf „true“ gesetzt haben, können Sie sie nicht auf „false“ setzen.
|
Zusätzlich zu useCHAP=true
chapTargetUsername
müssen die chapInitiatorSecret
Felder , , chapTargetInitiatorSecret
und chapUsername
in die Backend-Definition einbezogen werden. Die Secrets können geändert werden, nachdem ein Backend durch Ausführen erstellt tridentctl update
wurde.
So funktioniert es
Wenn useCHAP
der Storage-Administrator auf „true“ setzt, weist er Astra Trident an, CHAP auf dem Storage-Back-End zu konfigurieren. Dazu gehört Folgendes:
-
Einrichten von CHAP auf der SVM:
-
Wenn der Standard-Initiator-Sicherheitstyp der SVM none (standardmäßig festgelegt) ist und, wenn keine bereits vorhandenen LUNs im Volume vorhanden sind, setzt Astra Trident den Standard-Sicherheitstyp auf
CHAP
und fährt mit der Konfiguration des CHAP-Initiators und der Zielbenutzernamen und -Schlüssel fort. -
Wenn die SVM LUNs enthält, aktiviert Astra Trident nicht CHAP auf der SVM. Dadurch wird sichergestellt, dass der Zugriff auf die LUNs, die bereits auf der SVM vorhanden sind, nicht eingeschränkt wird.
-
-
Konfigurieren des CHAP-Initiators und des Ziel-Usernamens und der Schlüssel; diese Optionen müssen in der Back-End-Konfiguration angegeben werden (siehe oben).
Nach der Erstellung des Backends erstellt Astra Trident eine entsprechende tridentbackend
CRD und speichert die CHAP-Geheimnisse und Benutzernamen als Kubernetes-Geheimnisse. Alle PVS, die von Astra Trident auf diesem Backend erstellt werden, werden über CHAP gemountet und angeschlossen.
Anmeldedaten rotieren und Back-Ends aktualisieren
Sie können die CHAP-Anmeldeinformationen aktualisieren, indem Sie die CHAP-Parameter in der Datei aktualisieren backend.json
. Dies erfordert die Aktualisierung der CHAP-Schlüssel und die Verwendung des tridentctl update
Befehls, um diese Änderungen widerzuspiegeln.
Wenn Sie die CHAP-Schlüssel für ein Backend aktualisieren, müssen Sie tridentctl das Backend aktualisieren. Aktualisieren Sie die Anmeldeinformationen im Storage-Cluster nicht über die Benutzeroberfläche von CLI/ONTAP, da Astra Trident diese Änderungen nicht übernehmen kann.
|
cat backend-san.json { "version": 1, "storageDriverName": "ontap-san", "backendName": "ontap_san_chap", "managementLIF": "192.168.0.135", "svm": "ontap_iscsi_svm", "useCHAP": true, "username": "vsadmin", "password": "password", "chapInitiatorSecret": "cl9qxUpDaTeD", "chapTargetInitiatorSecret": "rqxigXgkeUpDaTeD", "chapTargetUsername": "iJF4heBRT0TCwxyz", "chapUsername": "uh2aNCLSd6cNwxyz", } ./tridentctl update backend ontap_san_chap -f backend-san.json -n trident +----------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +----------------+----------------+--------------------------------------+--------+---------+ | ontap_san_chap | ontap-san | aa458f3b-ad2d-4378-8a33-1a472ffbeb5c | online | 7 | +----------------+----------------+--------------------------------------+--------+---------+
Bestehende Verbindungen bleiben unbeeinträchtigt, sie bleiben auch weiterhin aktiv, wenn die Anmeldedaten vom Astra Trident auf der SVM aktualisiert werden. Neue Verbindungen verwenden die aktualisierten Anmeldedaten und vorhandene Verbindungen bleiben weiterhin aktiv. Wenn Sie alte PVS trennen und neu verbinden, werden sie die aktualisierten Anmeldedaten verwenden.