Trident a besoin des identifiants d'un administrateur au niveau SVM/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é ascendante avec les futures versions ONTAP qui pourraient exposer des API de fonctionnalités utilisables par les futures versions de Trident . Il est possible de créer et d'utiliser un rôle de connexion de sécurité personnalisé avec Trident, mais cela n'est pas recommandé.

Voici un exemple de définition de backend :

N'oubliez pas que la définition du backend est le seul endroit où les identifiants sont stockés en clair. Une fois le backend créé, les noms d'utilisateur et les mots de passe sont encodés en Base64 et stockés en tant que secrets Kubernetes. La création ou la mise à jour d'un backend est la seule étape qui nécessite la connaissance des identifiants. Il s'agit donc d'une opération réservée aux administrateurs, qui doit être effectuée par l'administrateur Kubernetes/stockage.

Les nouveaux et les existants serveurs dorsaux peuvent utiliser un certificat et communiquer avec le serveur dorsal ONTAP . Trois paramètres sont requis dans la définition du backend.

Un flux de travail typique comprend les étapes suivantes.

Vous pouvez mettre à jour un système dorsal existant pour utiliser une méthode d'authentification différente ou pour renouveler ses identifiants. Cela fonctionne dans les deux sens : les systèmes d’arrière-plan qui utilisent un nom d’utilisateur/mot de passe peuvent être mis à jour pour utiliser des certificats ; les systèmes d’arrière-plan 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. Utilisez ensuite le fichier backend.json mis à jour contenant les paramètres requis pour exécuter tridentctl backend update .

La mise à jour d'un système dorsal n'interrompt pas l'accès aux volumes déjà créés et n'a aucun impact sur les connexions de volumes effectuées ultérieurement. Une mise à jour réussie du système dorsal indique que Trident peut communiquer avec le système dorsal ONTAP et gérer les futures opérations de volume.

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.

Se référer à"Générateur de rôles personnalisés Trident" pour plus d'informations sur la création de rôles personnalisés Trident .

Pour plus d'informations, veuillez consulter les pages suivantes :

En fixant useCHAP Si la valeur est « true », l'administrateur du stockage demande à Trident de configurer CHAP sur le système de stockage dorsal. Cela comprend les éléments suivants :

Une fois le backend créé, Trident crée un correspondant tridentbackend CRD et stocke les secrets CHAP et 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.

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

Les connexions existantes resteront inchangées ; elles resteront actives si les informations d'identification sont mises à jour par Trident sur le SVM. Les nouvelles connexions utilisent les informations d'identification mises à jour et les connexions existantes restent actives. Déconnecter puis reconnecter les anciens PV leur permettra d'utiliser les identifiants mis à jour.