Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Préparez-vous à configurer le backend avec les pilotes SAN ONTAP

PDF

Comprenez les exigences et les options d'authentification pour configurer un backend ONTAP avec des pilotes SAN ONTAP.

Exigences

Pour tous les backends ONTAP, Trident exige qu'au moins un agrégat soit affecté au SVM.

Remarque "Systèmes ASA r2" diffèrent des autres systèmes ONTAP (ASA, AFF et FAS) par l’implémentation de leur couche de stockage. Dans les systèmes ASA r2, des zones de disponibilité de stockage sont utilisées au lieu des agrégats. Consultez l’article de la "ce" Knowledge Base pour savoir comment affecter des agrégats aux SVM dans les systèmes ASA r2.

N'oubliez pas que vous pouvez également exécuter plusieurs pilotes et créer des classes de stockage qui pointent vers l'un ou l'autre. Par exemple, vous pouvez configurer une san-dev classe qui utilise le ontap-san pilote et une san-default classe qui utilise le ontap-san-economy pilote.

Tous vos nœuds de travail Kubernetes doivent disposer des outils iSCSI appropriés. Consultez "Préparez le nœud de travail" pour plus de détails.

Authentifier le backend ONTAP

Trident propose deux modes d'authentification pour un backend ONTAP.

  • Authentification par identifiants : le nom d’utilisateur et le mot de passe d’un utilisateur ONTAP disposant des autorisations requises. Il est recommandé d’utiliser un rôle de connexion de sécurité prédéfini, tel que admin ou vsadmin pour garantir une compatibilité maximale avec les versions d’ONTAP.

  • Authentification par certificat : Trident peut également communiquer avec un cluster ONTAP à l’aide d’un certificat installé sur le backend. Dans ce cas, la définition du backend doit contenir les valeurs encodées en Base64 du certificat client, de la clé et, si utilisé (recommandé), du certificat de l’autorité de certification de confiance.

Vous pouvez mettre à jour les backends existants pour basculer entre les méthodes basées sur les identifiants et celles basées sur les certificats. Cependant, une seule méthode d'authentification est prise en charge à la fois. Pour passer à une autre méthode d'authentification, vous devez supprimer la méthode existante de la configuration du backend.

Avertissement Si vous tentez de fournir à la fois des informations d'identification et des certificats, la création du backend échouera avec une erreur indiquant que plus d'une méthode d'authentification a été fournie dans le fichier de configuration.

Activer l'authentification basée sur les identifiants

Trident requiert les identifiants d'un administrateur au niveau SVM ou au niveau cluster pour communiquer avec le backend ONTAP. Il est recommandé d'utiliser des rôles standard prédéfinis tels que admin ou vsadmin. Cela garantit la compatibilité avec les futures versions d'ONTAP qui pourraient exposer des API de fonctionnalités à utiliser par les futures versions de Trident. Un rôle de connexion de sécurité personnalisé peut être créé et utilisé avec Trident, mais cela n'est pas recommandé.

Voici un exemple de définition de backend :

YAML
---
version: 1
backendName: ExampleBackend
storageDriverName: ontap-san
managementLIF: 10.0.0.1
svm: svm_nfs
username: vsadmin
password: password
JSON
{
  "version": 1,
  "backendName": "ExampleBackend",
  "storageDriverName": "ontap-san",
  "managementLIF": "10.0.0.1",
  "svm": "svm_nfs",
  "username": "vsadmin",
  "password": "password"
}

Il est important de noter que la définition du backend est le seul endroit où les identifiants sont stockés en clair. Après la création du backend, les noms d'utilisateur et mots de passe sont encodés avec Base64 et stockés comme secrets Kubernetes. La création ou la mise à jour d'un backend est la seule étape qui nécessite la connaissance des identifiants. En tant que telle, il s'agit d'une opération réservée à l'administrateur Kubernetes/stockage.

Activer l'authentification basée sur les certificats

Les nouveaux et les anciens backends peuvent utiliser un certificat et communiquer avec le backend ONTAP. Trois paramètres sont requis dans la définition du backend.

  • clientCertificate: Valeur codée en Base64 du certificat client.

  • clientPrivateKey : valeur encodée en Base64 de la clé privée associée.

  • trustedCACertificate : valeur encodée en Base64 du certificat CA de confiance. Si vous utilisez un CA de confiance, ce paramètre doit être fourni. Cela peut être ignoré si aucun CA de confiance n'est utilisé.

Un workflow typique implique les étapes suivantes.

Étapes

  1. Générez un certificat client et une clé. Lors de la génération, définissez le nom commun (CN) sur l'utilisateur ONTAP à authentifier.

    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"

  2. Ajoutez un certificat d'autorité de certification de confiance au cluster ONTAP. Cette opération peut déjà être effectuée par l'administrateur de stockage. Ignorez si aucune autorité de certification de confiance n'est utilisée.

    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>

  3. Installez le certificat client et la clé (de l'étape 1) sur le cluster ONTAP.

    security certificate install -type client-ca -cert-name <certificate-name> -vserver <vserver-name>
security ssl modify -vserver <vserver-name> -client-enabled true
    Remarque Après avoir exécuté cette commande, ONTAP vous invite à saisir un certificat. Collez le contenu du k8senv.pem fichier généré à l’étape 1, puis appuyez sur END pour terminer l’installation.

  4. Confirmez que le rôle de connexion de sécurité ONTAP prend en charge cert la méthode d'authentification.

    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

  5. Testez l'authentification à l'aide du certificat généré. Remplacez <ONTAP Management LIF> et <vserver name> par l'adresse IP de la LIF de gestion et le nom SVM.

    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>'

  6. Encodez le certificat, la clé et le certificat d'autorité de certification de confiance avec Base64.

    base64 -w 0 k8senv.pem >> cert_base64
base64 -w 0 k8senv.key >> key_base64
base64 -w 0 trustedca.pem >> trustedca_base64

  7. Créez le backend en utilisant les valeurs obtenues à l'étape précédente.

    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 |
+------------+----------------+--------------------------------------+--------+---------+

Mettez à jour les méthodes d'authentification ou faites pivoter les identifiants

Vous pouvez mettre à jour un backend existant pour utiliser une méthode d'authentification différente ou pour faire pivoter ses identifiants. Cela fonctionne dans les deux sens : les backends qui utilisent un nom d'utilisateur/mot de passe peuvent être mis à jour pour utiliser des certificats ; les backends qui utilisent des certificats peuvent être mis à jour pour utiliser un nom d'utilisateur/mot de passe. Pour ce faire, vous devez supprimer la méthode d'authentification existante et ajouter la nouvelle méthode d'authentification. Ensuite, utilisez le fichier backend.json mis à jour contenant les paramètres requis pour exécuter 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 |
+------------+----------------+--------------------------------------+--------+---------+
Remarque Lors du renouvellement des mots de passe, l'administrateur du stockage doit d'abord mettre à jour le mot de passe de l'utilisateur sur ONTAP. Cette opération est suivie d'une mise à jour du backend. Lors du renouvellement des certificats, plusieurs certificats peuvent être associés à l'utilisateur. Le backend est ensuite mis à jour pour utiliser le nouveau certificat, après quoi l'ancien certificat peut être supprimé du cluster ONTAP.

La mise à jour d'un backend n'interrompt pas l'accès aux volumes déjà créés et n'affecte pas les connexions de volumes établies ultérieurement. Une mise à jour réussie du backend indique que Trident peut communiquer avec le backend ONTAP et gérer les futures opérations sur les volumes.

Créer un rôle ONTAP personnalisé pour Trident

Vous pouvez créer un rôle de cluster ONTAP avec des privilèges minimaux afin de ne pas avoir à utiliser le rôle d'administrateur ONTAP pour effectuer des opérations dans Trident. Lorsque vous incluez le nom d'utilisateur dans une configuration backend Trident, Trident utilise le rôle de cluster ONTAP que vous avez créé pour effectuer les opérations.

Reportez-vous à "Générateur de rôles personnalisés Trident" pour plus d'informations sur la création de rôles personnalisés Trident.

Utilisation de l'interface de ligne de commande ONTAP

  1. Créez un nouveau rôle à l'aide de la commande suivante :

    security login role create <role_name\> -cmddirname "command" -access all –vserver <svm_name\>

  2. Créez un nom d'utilisateur pour l'utilisateur Trident :

    security login create -username <user_name\> -application ontapi -authmethod <password\> -role <name_of_role_in_step_1\> –vserver <svm_name\> -comment "user_description"

  3. Associez le rôle à l'utilisateur :

    security login modify username <user_name\> –vserver <svm_name\> -role <role_name\> -application ontapi -application console -authmethod <password\>

Utilisation de System Manager

Effectuez les étapes suivantes dans ONTAP System Manager :

  1. Créer un rôle personnalisé:

    1. Pour créer un rôle personnalisé au niveau du cluster, sélectionnez Cluster > Settings.

      (Ou) Pour créer un rôle personnalisé au niveau de la SVM, sélectionnez Storage > Storage VMs > required SVM> Paramètres > Utilisateurs et rôles.

    2. Sélectionnez l'icône flèche (→) à côté de Users and Roles.

    3. Sélectionnez +Add sous Roles.

    4. Définissez les règles du rôle et cliquez sur Save.

  2. Associez le rôle à l'utilisateur Trident : + Effectuez les étapes suivantes sur la page Utilisateurs et rôles :

    1. Sélectionnez l’icône Ajouter + sous Users.

    2. Sélectionnez le nom d'utilisateur requis, puis sélectionnez un rôle dans le menu déroulant pour Rôle.

    3. Cliquez sur Enregistrer.

Reportez-vous aux pages suivantes pour plus d'informations :

Authentifiez les connexions avec CHAP bidirectionnel

Trident peut authentifier les sessions iSCSI avec CHAP bidirectionnel pour les ontap-san et ontap-san-economy pilotes. Cela nécessite l’activation de l’option useCHAP dans la définition de votre backend. Lorsqu’elle est définie sur true, Trident configure la sécurité par défaut de l’initiateur du SVM sur CHAP bidirectionnel et définit le nom d’utilisateur et les secrets à partir du fichier backend. NetApp recommande d’utiliser CHAP bidirectionnel pour authentifier les connexions. Voir l’exemple de configuration suivant :

---
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
Avertissement Le useCHAP paramètre est une option booléenne qui ne peut être configurée qu'une seule fois. Il est défini sur faux par défaut. Après l'avoir défini sur vrai, vous ne pouvez plus le définir sur faux.

En plus de useCHAP=true, les chapInitiatorSecret, chapTargetInitiatorSecret, chapTargetUsername et chapUsername, les champs doivent être inclus dans la définition du backend. Les secrets peuvent être modifiés après la création d'un backend en exécutant tridentctl update.

Comment ça marche

En définissant useCHAP sur true, l'administrateur de stockage demande à Trident de configurer CHAP sur le système de stockage. Cela inclut les éléments suivants :

  • Configuration de CHAP sur la SVM :

    • Si le type de sécurité par défaut de l'initiateur SVM est « aucun » (défini par défaut) et qu'il n'y a pas de LUN préexistants déjà présents dans le volume, Trident définira le type de sécurité par défaut à CHAP et procédera à la configuration du nom d'utilisateur et des secrets de l'initiateur CHAP et de la cible.

    • Si la SVM contient des LUN, Trident n'activera pas CHAP sur la SVM. Cela garantit que l'accès aux LUN déjà présentes sur la SVM n'est pas restreint.

  • Configuration du nom d'utilisateur et des secrets de l'initiateur et de la cible CHAP ; ces options doivent être spécifiées dans la configuration du backend (comme indiqué ci-dessus).

Après la création du backend, Trident crée une CRD correspondante tridentbackend et stocke les secrets CHAP ainsi que les noms d'utilisateur en tant que secrets Kubernetes. Tous les PV créés par Trident sur ce backend seront montés et attachés via CHAP.

Renouvelez les identifiants et mettez à jour les backends

Vous pouvez mettre à jour les informations d'identification CHAP en modifiant les paramètres CHAP dans le backend.json fichier. Cela nécessitera la mise à jour des secrets CHAP et l'utilisation de la tridentctl update commande pour appliquer ces modifications.

Avertissement Lors de la mise à jour des secrets CHAP pour un backend, vous devez utiliser tridentctl pour mettre à jour le backend. Ne mettez pas à jour les informations d'identification sur le cluster de stockage à l'aide de l'ONTAP CLI ou d'ONTAP System Manager, car Trident ne pourra pas prendre en compte ces modifications. 
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 |
+----------------+----------------+--------------------------------------+--------+---------+

Les connexions existantes restent inchangées ; elles demeureront actives si les identifiants sont mis à jour par Trident sur le SVM. Les nouvelles connexions utilisent les identifiants mis à jour et les connexions existantes demeurent actives. La déconnexion puis la reconnexion d'anciens PV entraînera leur utilisation des identifiants mis à jour.