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 un serveur dorsal avec des pilotes NAS ONTAP.

10/29/2025 Contributeurs

Comprendre les exigences, les options d'authentification et les politiques d'exportation pour configurer un backend ONTAP avec les pilotes ONTAP NAS.

Exigences

Pour tous les backends ONTAP , Trident exige qu'au moins un agrégat soit affecté au SVM.
Vous pouvez 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 classe Gold qui utilise ontap-nas pilote et une classe Bronze qui utilise le ontap-nas-economy un.
Tous vos nœuds de travail Kubernetes doivent avoir les outils NFS appropriés installés. Se référer à"ici" pour plus de détails.
Trident prend uniquement en charge les volumes SMB montés sur des pods exécutés sur des nœuds Windows. Se référer à Préparez-vous à provisionner des volumes PME pour plus de détails.

Authentifier le backend ONTAP

Trident propose deux modes d'authentification pour un système dorsal ONTAP .

Authentification par identifiants : ce mode nécessite des autorisations suffisantes sur le serveur ONTAP . Il est recommandé d'utiliser un compte associé à un rôle de connexion de sécurité prédéfini, tel que admin ou vsadmin pour assurer une compatibilité maximale avec les versions ONTAP .
Mode basé sur un certificat : ce mode nécessite un certificat installé sur le serveur pour que Trident puisse communiquer avec un cluster ONTAP . Ici, la définition du backend doit contenir les valeurs encodées en Base64 du certificat client, de la clé et du certificat d'autorité de certification de confiance si utilisé (recommandé).

Vous pouvez mettre à jour les systèmes d'arrière-plan existants pour passer d'une méthode basée sur les identifiants à une méthode basée 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 actuelle de la configuration du serveur.

Si vous tentez de fournir à la fois des identifiants et des certificats, la création du backend échouera avec une erreur indiquant que plusieurs méthodes d'authentification ont été fournies dans le fichier de configuration.

Activer l'authentification par identifiants

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 :

YAML

---
version: 1
backendName: ExampleBackend
storageDriverName: ontap-nas
managementLIF: 10.0.0.1
dataLIF: 10.0.0.2
svm: svm_nfs
credentials:
  name: secret-backend-creds

JSON

{
  "version": 1,
  "backendName": "ExampleBackend",
  "storageDriverName": "ontap-nas",
  "managementLIF": "10.0.0.1",
  "dataLIF": "10.0.0.2",
  "svm": "svm_nfs",
  "credentials": {
        "name": "secret-backend-creds"
    }
}

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/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.

Activer l'authentification par certificat

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.

clientCertificate : valeur du certificat client encodée en Base64.
clientPrivateKey : valeur encodée en Base64 de la clé privée associée.
trustedCACertificate : valeur encodée en Base64 du certificat d’autorité de certification de confiance. Si vous utilisez une autorité de certification de confiance, ce paramètre doit être fourni. Ceci peut être ignoré si aucune autorité de certification de confiance n'est utilisée.

Un flux de travail typique comprend les étapes suivantes.

Étapes

Générer un certificat client et une clé. Lors de la génération, définissez le nom commun (CN) sur l'utilisateur ONTAP sous lequel s'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=vsadmin"
```

Ajouter un certificat d'autorité de certification de confiance au cluster ONTAP . Cela est peut-être déjà géré par l'administrateur du stockage. Ignorer 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>

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

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

security login create -user-or-group-name vsadmin -application ontapi -authentication-method cert -vserver <vserver-name>
security login create -user-or-group-name vsadmin -application http -authentication-method cert -vserver <vserver-name>

Testez l'authentification à l'aide du certificat généré. Remplacez < ONTAP Management LIF> et <nom du serveur virtuel> par l'adresse IP de l'interface de gestion LIF et le nom du SVM. Vous devez vous assurer que le LIF a sa politique de service configurée comme suit : default-data-management .

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

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

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

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

cat cert-backend-updated.json
{
"version": 1,
"storageDriverName": "ontap-nas",
"backendName": "NasBackend",
"managementLIF": "1.2.3.4",
"dataLIF": "1.2.3.8",
"svm": "vserver_test",
"clientCertificate": "Faaaakkkkeeee...Vaaalllluuuueeee",
"clientPrivateKey": "LS0tFaKE...0VaLuES0tLS0K",
"storagePrefix": "myPrefix_"
}

#Update backend with tridentctl
tridentctl update backend NasBackend -f cert-backend-updated.json -n trident
+------------+----------------+--------------------------------------+--------+---------+
|    NAME    | STORAGE DRIVER |                 UUID                 | STATE  | VOLUMES |
+------------+----------------+--------------------------------------+--------+---------+
| NasBackend | ontap-nas      | 98e19b74-aec7-4a3d-8dcf-128e5033b214 | online |       9 |
+------------+----------------+--------------------------------------+--------+---------+

Mettez à jour les méthodes d'authentification ou changez les identifiants.

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 update backend .

cat cert-backend-updated.json

{
"version": 1,
"storageDriverName": "ontap-nas",
"backendName": "NasBackend",
"managementLIF": "1.2.3.4",
"dataLIF": "1.2.3.8",
"svm": "vserver_test",
"username": "vsadmin",
"password": "password",
"storagePrefix": "myPrefix_"
}

#Update backend with tridentctl
tridentctl update backend NasBackend -f cert-backend-updated.json -n trident
+------------+----------------+--------------------------------------+--------+---------+
|    NAME    | STORAGE DRIVER |                 UUID                 | STATE  | VOLUMES |
+------------+----------------+--------------------------------------+--------+---------+
| NasBackend | ontap-nas      | 98e19b74-aec7-4a3d-8dcf-128e5033b214 | online |       9 |
+------------+----------------+--------------------------------------+--------+---------+

Lors de la rotation des mots de passe, l'administrateur du stockage doit d'abord mettre à jour le mot de passe de l'utilisateur sur ONTAP. Cette étape est suivie d'une mise à jour du système dorsal. Lors de la rotation des certificats, plusieurs certificats peuvent être ajoutés à l'utilisateur. Le système dorsal 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 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.

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.

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 .

Utilisation de l'interface de ligne de commande ONTAP

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\>
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"
Associer le rôle à l'utilisateur :

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

Utilisation du gestionnaire système

Effectuez les étapes suivantes dans ONTAP System Manager :

Créer un rôle personnalisé :
1. Pour créer un rôle personnalisé au niveau du cluster, sélectionnez Cluster > Paramètres.
  
  (Ou) Pour créer un rôle personnalisé au niveau de la SVM, sélectionnez Stockage > Machines virtuelles de stockage > required SVM > Paramètres > Utilisateurs et rôles.
2. Sélectionnez l'icône flèche (→) à côté de Utilisateurs et rôles.
3. Sélectionnez +Ajouter sous Rôles.
4. Définissez les règles du rôle et cliquez sur Enregistrer.
Associer 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 Utilisateurs.
2. Sélectionnez le nom d'utilisateur requis, puis sélectionnez un rôle dans le menu déroulant Rôle.
3. Cliquez sur Enregistrer.

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

Gérer les politiques d'exportation NFS

Trident utilise des politiques d'exportation NFS pour contrôler l'accès aux volumes qu'il provisionne.

Trident propose deux options pour la gestion des politiques d'exportation :

Trident peut gérer dynamiquement la politique d'exportation elle-même ; dans ce mode de fonctionnement, l'administrateur de stockage spécifie une liste de blocs CIDR qui représentent des adresses IP admissibles. Trident ajoute automatiquement à la politique d'exportation, lors de la publication, les adresses IP des nœuds concernés qui se trouvent dans ces plages. Sinon, lorsqu'aucun CIDR n'est spécifié, toutes les adresses IP unicast à portée globale trouvées sur le nœud sur lequel le volume est publié seront ajoutées à la politique d'exportation.
Les administrateurs de stockage peuvent créer une politique d'exportation et ajouter des règles manuellement. Trident utilise la politique d'exportation par défaut, sauf si un nom de politique d'exportation différent est spécifié dans la configuration.

Gérer dynamiquement les politiques d'exportation

Trident offre la possibilité de gérer dynamiquement les politiques d'exportation pour les systèmes backend ONTAP . Cela permet à l'administrateur du stockage de spécifier un espace d'adressage autorisé pour les adresses IP des nœuds de travail, plutôt que de définir manuellement des règles explicites. Cela simplifie considérablement la gestion des politiques d'exportation ; les modifications apportées à la politique d'exportation ne nécessitent plus d'intervention manuelle sur le cluster de stockage. De plus, cela permet de limiter l'accès au cluster de stockage aux seuls nœuds de travail qui montent des volumes et dont les adresses IP se trouvent dans la plage spécifiée, ce qui permet une gestion précise et automatisée.

N’utilisez pas la traduction d’adresses réseau (NAT) lorsque vous utilisez des politiques d’exportation dynamiques. Avec NAT, le contrôleur de stockage voit l'adresse NAT frontale et non l'adresse IP réelle de l'hôte ; l'accès sera donc refusé si aucune correspondance n'est trouvée dans les règles d'exportation.

Exemple

Deux options de configuration doivent être utilisées. Voici un exemple de définition de backend :

---
version: 1
storageDriverName: ontap-nas-economy
backendName: ontap_nas_auto_export
managementLIF: 192.168.0.135
svm: svm1
username: vsadmin
password: password
autoExportCIDRs:
  - 192.168.0.0/24
autoExportPolicy: true

Lorsque vous utilisez cette fonctionnalité, vous devez vous assurer que la jonction racine de votre SVM dispose d'une stratégie d'exportation préalablement créée avec une règle d'exportation autorisant le bloc CIDR du nœud (telle que la stratégie d'exportation par défaut). Suivez toujours les bonnes pratiques recommandées par NetApp pour dédier une SVM à Trident.

Voici une explication du fonctionnement de cette fonctionnalité à l'aide de l'exemple ci-dessus :

autoExportPolicy`est réglé sur `true . Cela indique que Trident crée une politique d'exportation pour chaque volume provisionné avec ce backend pour le svm1 SVM et gestion de l'ajout et de la suppression de règles à l'aide de autoexportCIDRs blocs d'adresses. Tant qu'un volume n'est pas attaché à un nœud, le volume utilise une politique d'exportation vide, sans aucune règle pour empêcher les accès non autorisés à ce volume. Lorsqu'un volume est publié sur un nœud, Trident crée une politique d'exportation portant le même nom que l'arbre qtree sous-jacent contenant l'adresse IP du nœud dans le bloc CIDR spécifié. Ces adresses IP seront également ajoutées à la politique d'exportation utilisée par le FlexVol volume parent.
- Par exemple:
  - UUID du serveur dorsal : 403b5326-8482-40db-96d0-d83fb3f4daec
  - autoExportPolicy`défini à `true
  - préfixe de stockage trident
  - UUID PVC a79bcf5f-7b6d-4a40-9876-e2551f159c1c
  - L'arbre qtree nommé trident_pvc_a79bcf5f_7b6d_4a40_9876_e2551f159c1c crée une politique d'exportation pour le FlexVol nommé trident-403b5326-8482-40db96d0-d83fb3f4daec , une politique d'exportation pour le qtree nommé
    trident_pvc_a79bcf5f_7b6d_4a40_9876_e2551f159c1c et une politique d'exportation vide nommée trident_empty sur la SVM. Les règles de la politique d'exportation FlexVol seront un sur-ensemble de toutes les règles contenues dans les politiques d'exportation qtree. La stratégie d'exportation vide sera réutilisée par tous les volumes non attachés.
`autoExportCIDRs`contient une liste de blocs d'adresses. Ce champ est facultatif et sa valeur par défaut est ["0.0.0.0/0", "::/0"]. Si aucune adresse n'est définie, Trident ajoute toutes les adresses unicast à portée globale trouvées sur les nœuds de travail comportant des publications.

Dans cet exemple, le 192.168.0.0/24 Un espace d'adressage est prévu. Cela indique que les adresses IP des nœuds Kubernetes qui se trouvent dans cette plage d'adresses et qui contiennent des publications seront ajoutées à la politique d'exportation créée par Trident . Lorsque Trident enregistre un nœud sur lequel il s'exécute, il récupère les adresses IP du nœud et les compare aux blocs d'adresses fournis dans autoExportCIDRs Au moment de la publication, après avoir filtré les adresses IP, Trident crée les règles de stratégie d'exportation pour les adresses IP clientes du nœud sur lequel il publie.

Vous pouvez mettre à jour autoExportPolicy et autoExportCIDRs pour les backends une fois que vous les avez créés. Vous pouvez ajouter de nouveaux CIDR pour un backend géré automatiquement ou supprimer les CIDR existants. Soyez prudent lors de la suppression des CIDR afin de vous assurer que les connexions existantes ne sont pas interrompues. Vous pouvez également choisir de désactiver autoExportPolicy pour un système dorsal et recourir à une politique d'exportation créée manuellement en cas de besoin. Cela nécessitera de paramétrer le exportPolicy paramètre dans votre configuration backend.

Une fois que Trident a créé ou mis à jour un backend, vous pouvez le vérifier à l'aide de tridentctl ou le correspondant tridentbackend CRD :

./tridentctl get backends ontap_nas_auto_export -n trident -o yaml
items:
- backendUUID: 403b5326-8482-40db-96d0-d83fb3f4daec
  config:
    aggregate: ""
    autoExportCIDRs:
    - 192.168.0.0/24
    autoExportPolicy: true
    backendName: ontap_nas_auto_export
    chapInitiatorSecret: ""
    chapTargetInitiatorSecret: ""
    chapTargetUsername: ""
    chapUsername: ""
    dataLIF: 192.168.0.135
    debug: false
    debugTraceFlags: null
    defaults:
      encryption: "false"
      exportPolicy: <automatic>
      fileSystemType: ext4

Lorsqu'un nœud est supprimé, Trident vérifie toutes les politiques d'exportation afin de supprimer les règles d'accès correspondant à ce nœud. En supprimant cette adresse IP de nœud des politiques d'exportation des backends gérés, Trident empêche les montages non autorisés, sauf si cette adresse IP est réutilisée par un nouveau nœud du cluster.

Pour les backends existants, la mise à jour du backend avec tridentctl update backend garantit que Trident gère automatiquement les politiques d'exportation. Cela crée deux nouvelles politiques d'exportation nommées d'après l'UUID et le nom qtree du backend lorsque cela est nécessaire. Les volumes présents sur le système dorsal utiliseront les politiques d'exportation nouvellement créées après avoir été démontés puis remontés.

La suppression d'un backend avec des politiques d'exportation gérées automatiquement supprimera la politique d'exportation créée dynamiquement. Si le système dorsal est recréé, il est traité comme un nouveau système dorsal et entraînera la création d'une nouvelle politique d'exportation.

Si l'adresse IP d'un nœud en production est mise à jour, vous devez redémarrer le pod Trident sur ce nœud. Trident mettra ensuite à jour sa politique d'exportation pour les serveurs backend qu'elle gère afin de refléter ce changement d'adresse IP.

Préparez-vous à provisionner des volumes PME

Avec un peu de préparation supplémentaire, vous pouvez provisionner des volumes SMB en utilisant ontap-nas conducteurs.

Vous devez configurer les protocoles NFS et SMB/CIFS sur la SVM pour créer un ontap-nas-economy Volume SMB pour les clusters ONTAP sur site. Le défaut de configuration de l'un ou l'autre de ces protocoles entraînera l'échec de la création du volume SMB.

`autoExportPolicy`La prise en charge des volumes SMB n'est pas assurée.

Avant de commencer

Avant de pouvoir provisionner des volumes SMB, vous devez disposer des éléments suivants.

Un cluster Kubernetes avec un nœud contrôleur Linux et au moins un nœud de travail Windows exécutant Windows Server 2022. Trident prend uniquement en charge les volumes SMB montés sur des pods exécutés sur des nœuds Windows.
Au moins un secret Trident contenant vos informations d'identification Active Directory. Générer des secrets smbcreds :
```
kubectl create secret generic smbcreds --from-literal username=user --from-literal password='password'
```
Un proxy CSI configuré comme un service Windows. Pour configurer un csi-proxy , se référer à"GitHub : CSI Proxy" ou"GitHub : CSI Proxy pour Windows" pour les nœuds Kubernetes exécutés sous Windows.

Étapes

Pour ONTAP sur site, vous pouvez créer un partage SMB en option ou Trident peut en créer un pour vous.

Les partages SMB sont requis pour Amazon FSx pour ONTAP.

Vous pouvez créer les partages d'administration SMB de deux manières : soit en utilisant…"Console de gestion Microsoft" composant logiciel enfichable Dossiers partagés ou via l'interface de ligne de commande ONTAP . Pour créer les partages SMB à l'aide de l'interface de ligne de commande ONTAP :
1. Si nécessaire, créez la structure de chemin d'accès au répertoire partagé.
  
  Le vserver cifs share create Cette commande vérifie le chemin spécifié dans l'option -path lors de la création du partage. Si le chemin spécifié n'existe pas, la commande échoue.
2. Créer un partage SMB associé à la SVM spécifiée :
  vserver cifs share create -vserver vserver_name -share-name share_name -path path [-share-properties share_properties,...] [other_attributes] [-comment text]
3. Vérifiez que le partage a bien été créé :
  vserver cifs share show -share-name share_name
  Se référer à"Créer un partage SMB" pour plus de détails.

Lors de la création du backend, vous devez configurer les éléments suivants pour spécifier les volumes SMB. Pour connaître toutes les options de configuration du backend FSx pour ONTAP , veuillez vous référer à"Options et exemples de configuration de FSx pour ONTAP" .

Paramètre Description Exemple

Paramètre	Description	Exemple
`smbShare`	Vous pouvez spécifier l'un des éléments suivants : le nom d'un partage SMB créé à l'aide de la console de gestion Microsoft ou de l'interface de ligne de commande ONTAP ; un nom permettant à Trident de créer le partage SMB ; ou vous pouvez laisser le paramètre vide pour empêcher l'accès aux volumes via un partage commun. Ce paramètre est facultatif pour ONTAP sur site. Ce paramètre est obligatoire pour les serveurs backend Amazon FSx for ONTAP et ne peut pas être vide.	`smb-share`
`nasType`	Doit être réglé sur `smb` . Si la valeur est nulle, la valeur par défaut est `nfs` .	`smb`
`securityStyle`	Style de sécurité pour les nouveaux volumes. Doit être réglé sur `ntfs` ou `mixed` pour les volumes SMB.	ntfs`ou `mixed pour les volumes SMB
`unixPermissions`	Mode pour les nouveaux volumes. Doit rester vide pour les volumes SMB.	""

smbShare

Vous pouvez spécifier l'un des éléments suivants : le nom d'un partage SMB créé à l'aide de la console de gestion Microsoft ou de l'interface de ligne de commande ONTAP ; un nom permettant à Trident de créer le partage SMB ; ou vous pouvez laisser le paramètre vide pour empêcher l'accès aux volumes via un partage commun. Ce paramètre est facultatif pour ONTAP sur site. Ce paramètre est obligatoire pour les serveurs backend Amazon FSx for ONTAP et ne peut pas être vide.

smb-share

nasType

Doit être réglé sur smb . Si la valeur est nulle, la valeur par défaut est nfs .

smb

securityStyle

Style de sécurité pour les nouveaux volumes. Doit être réglé sur ntfs ou mixed pour les volumes SMB.

ntfs`ou `mixed pour les volumes SMB

unixPermissions

Mode pour les nouveaux volumes. Doit rester vide pour les volumes SMB.

Activer le SMB sécurisé

À partir de la version 25.06, NetApp Trident prend en charge le provisionnement sécurisé des volumes SMB créés à l'aide de ontap-nas et ontap-nas-economy backends. Lorsque le protocole SMB sécurisé est activé, vous pouvez fournir un accès contrôlé aux partages SMB pour les utilisateurs et les groupes d'utilisateurs Active Directory (AD) à l'aide de listes de contrôle d'accès (ACL).

Points à retenir

Importer ontap-nas-economy Les volumes ne sont pas pris en charge.
Seuls les clones en lecture seule sont pris en charge pour ontap-nas-economy volumes.
Si le protocole SMB sécurisé est activé, Trident ignorera le partage SMB mentionné dans le système dorsal.
La mise à jour de l'annotation PVC, de l'annotation de classe de stockage et du champ backend ne met pas à jour la liste de contrôle d'accès (ACL) du partage SMB.
La liste de contrôle d'accès (ACL) de partage SMB spécifiée dans l'annotation du PVC cloné aura priorité sur celle du PVC source.
Veillez à fournir des utilisateurs AD valides tout en activant le protocole SMB sécurisé. Les utilisateurs non valides ne seront pas ajoutés à la liste de contrôle d'accès (ACL).
Si vous fournissez le même utilisateur AD dans le backend, la classe de stockage et le PVC avec des autorisations différentes, la priorité des autorisations sera la suivante : PVC, classe de stockage, puis backend.
Le protocole SMB sécurisé est pris en charge pour ontap-nas S'applique aux importations de volumes gérés et non aux importations de volumes non gérés.

Étapes

Spécifiez adAdminUser dans TridentBackendConfig comme indiqué dans l'exemple suivant :

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-nas
  managementLIF: 10.193.176.x
  svm: svm0
  useREST: true
  defaults:
    adAdminUser: tridentADtest
  credentials:
    name: backend-tbc-ontap-invest-secret

Ajoutez l'annotation dans la classe de stockage.

Ajoutez le trident.netapp.io/smbShareAdUser Annotation à la classe de stockage pour activer le protocole SMB sécurisé sans erreur. La valeur utilisateur spécifiée pour l'annotation trident.netapp.io/smbShareAdUser doit être identique au nom d'utilisateur spécifié dans le smbcreds secrète. Vous pouvez choisir l'une des options suivantes pour smbShareAdUserPermission : full_control , change , ou read . L'autorisation par défaut est full_control .

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ontap-smb-sc
  annotations:
    trident.netapp.io/smbShareAdUserPermission: change
    trident.netapp.io/smbShareAdUser: tridentADuser
parameters:
  backendType: ontap-nas
  csi.storage.k8s.io/node-stage-secret-name: smbcreds
  csi.storage.k8s.io/node-stage-secret-namespace: trident
  trident.netapp.io/nasType: smb
provisioner: csi.trident.netapp.io
reclaimPolicy: Delete
volumeBindingMode: Immediate

Créer un PVC.

L'exemple suivant crée un PVC :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc4
  namespace: trident
  annotations:
    trident.netapp.io/snapshotDirectory: "true"
    trident.netapp.io/smbShareAccessControl: |
      read:
        - tridentADtest
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: ontap-smb-sc

Préparez-vous à configurer un serveur dorsal avec des pilotes NAS ONTAP.

Creating your file...

Exigences

Authentifier le backend ONTAP

Activer l'authentification par identifiants

Activer l'authentification par certificat

Mettez à jour les méthodes d'authentification ou changez les identifiants.

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

Gérer les politiques d'exportation NFS

Gérer dynamiquement les politiques d'exportation

Exemple

Préparez-vous à provisionner des volumes PME

Activer le SMB sécurisé