Vorbereiten der Konfiguration des Back-End 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. Beispielsweise könnten Sie A konfigurieren san-dev
Klasse, die den verwendet ontap-san
Fahrer und A san-default
Klasse, die den verwendet ontap-san-economy
Eins.
Alle Kubernetes-Worker-Nodes müssen über die entsprechenden iSCSI-Tools verfügen. Siehe "Bereiten Sie den Knoten „Worker“ vor" Entsprechende Details.
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 z. B.
admin
Odervsadmin
Für maximale Kompatibilität mit ONTAP Versionen. -
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, die Standard-vordefinierten Rollen wie zu verwenden admin
Oder vsadmin
. 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
-
Bestätigen Sie, dass die ONTAP-Sicherheitsanmeldungsrolle unterstützt wird
cert
Authentifizierungsmethode.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 Backend.json-Datei, 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 authentifizieren ontap-san
Und ontap-san-economy
Treiber. Hierfür muss die Aktivierung von erforderlich sein useCHAP
Option in der Back-End-Definition. Wenn eingestellt auf true
, Astra Trident konfiguriert die Standard-Initiator-Sicherheit der SVM auf bidirektionales CHAP und legt den Benutzernamen und die Schlüssel aus der Backend-Datei. 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
, Das chapInitiatorSecret
, chapTargetInitiatorSecret
, chapTargetUsername
, und chapUsername
Felder müssen in die Backend-Definition aufgenommen werden. Die Geheimnisse können geändert werden, nachdem ein Backend durch Ausführen erstellt wird tridentctl update
.
So funktioniert es
Nach Einstellung useCHAP
Der Storage-Administrator weist Astra Trident an, CHAP im Storage-Back-End zu konfigurieren. Dazu gehört Folgendes:
-
Einrichten von CHAP auf der SVM:
-
Wenn der Standardsicherheitstyp des SVM keine (standardmäßig eingestellt) ist und gibt es keine bereits vorhandenen LUNs im Volume, setzt Astra Trident den Standardsicherheitstyp auf
CHAP
Und fahren Sie mit der Konfiguration des CHAP-Initiators und des Zielbenutzernamens und der Schlüssel fort. -
Wenn die SVM LUNs enthält, aktiviert Astra Trident nicht CHAP auf der SVM. Dadurch wird sichergestellt, dass der Zugriff auf LUNs, die bereits auf der SVM vorhanden sind, nicht beschränkt ist.
-
-
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 Backend erstellt Astra Trident eine entsprechende tridentbackend
CRD: 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 im aktualisieren backend.json
Datei: Dazu müssen die CHAP-Schlüssel aktualisiert und der verwendet werden tridentctl update
Befehl zum Übergeben dieser Änderungen.
Wenn Sie die CHAP-Schlüssel für ein Backend aktualisieren, müssen Sie verwenden tridentctl Um das Backend zu 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.