Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Prepárese para configurar un backend con controladores NAS ONTAP .

10/29/2025 Colaboradores

PDF

Comprenda los requisitos, las opciones de autenticación y las políticas de exportación para configurar un backend ONTAP con controladores ONTAP NAS.

Requisitos

Para todos los backends de ONTAP , Trident requiere que se asigne al menos un agregado al SVM.
Puedes ejecutar más de un controlador y crear clases de almacenamiento que apunten a uno u otro. Por ejemplo, podrías configurar una clase Gold que utilice la ontap-nas conductor y una clase Bronce que utiliza el ontap-nas-economy uno.
Todos tus nodos de trabajo de Kubernetes deben tener instaladas las herramientas NFS apropiadas. Referirse a"aquí" Para más detalles.
Trident solo admite volúmenes SMB montados en pods que se ejecutan en nodos Windows. Referirse a Preparar el aprovisionamiento de volúmenes SMB Para más detalles.

Autenticar el backend de ONTAP

Trident ofrece dos modos de autenticación de un backend ONTAP .

Basado en credenciales: Este modo requiere permisos suficientes para el backend de ONTAP . Se recomienda utilizar una cuenta asociada a un rol de inicio de sesión de seguridad predefinido, como por ejemplo: admin o vsadmin para garantizar la máxima compatibilidad con las versiones de ONTAP .
Basado en certificados: Este modo requiere un certificado instalado en el backend para que Trident se comunique con un clúster ONTAP . Aquí, la definición del backend debe contener valores codificados en Base64 del certificado del cliente, la clave y el certificado de CA de confianza si se utiliza (recomendado).

Puedes actualizar los sistemas backend existentes para alternar entre métodos basados en credenciales y métodos basados en certificados. Sin embargo, solo se admite un método de autenticación a la vez. Para cambiar a un método de autenticación diferente, debe eliminar el método existente de la configuración del backend.

Si intenta proporcionar tanto credenciales como certificados, la creación del backend fallará con un error que indica que se proporcionó más de un método de autenticación en el archivo de configuración.

Habilitar la autenticación basada en credenciales

Trident requiere las credenciales de un administrador con ámbito SVM/ámbito de clúster para comunicarse con el backend de ONTAP . Se recomienda utilizar roles estándar predefinidos, tales como: admin o vsadmin . Esto garantiza la compatibilidad con versiones futuras de ONTAP que podrían exponer API de funciones para ser utilizadas por futuras versiones de Trident . Se puede crear y usar un rol de inicio de sesión de seguridad personalizado con Trident, pero no se recomienda.

Un ejemplo de definición de backend se vería así:

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"
    }
}

Tenga en cuenta que la definición del backend es el único lugar donde las credenciales se almacenan en texto plano. Una vez creado el backend, los nombres de usuario y las contraseñas se codifican con Base64 y se almacenan como secretos de Kubernetes. La creación/actualización de un backend es el único paso que requiere conocer las credenciales. Por lo tanto, se trata de una operación exclusiva para administradores, que debe ser realizada por el administrador de Kubernetes/almacenamiento.

Habilitar la autenticación basada en certificados

Los backends nuevos y existentes pueden usar un certificado y comunicarse con el backend de ONTAP . Se requieren tres parámetros en la definición del backend.

clientCertificate: Valor codificado en Base64 del certificado del cliente.
clientPrivateKey: Valor codificado en Base64 de la clave privada asociada.
trustedCACertificate: Valor codificado en Base64 del certificado de CA de confianza. Si se utiliza una CA de confianza, este parámetro debe proporcionarse. Esto puede ignorarse si no se utiliza ninguna CA de confianza.

Un flujo de trabajo típico comprende los siguientes pasos.

Pasos

Generar un certificado y una clave de cliente. Al generar, configure el Nombre Común (CN) con el usuario ONTAP con el que se autenticará.
```
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"
```

Agregar certificado de CA de confianza al clúster ONTAP . Es posible que esto ya lo gestione el administrador de almacenamiento. Ignorar si no se utiliza ninguna CA de confianza.

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>

Instale el certificado y la clave del cliente (del paso 1) en el clúster ONTAP .

security certificate install -type client-ca -cert-name <certificate-name> -vserver <vserver-name>
security ssl modify -vserver <vserver-name> -client-enabled true

Confirme que el rol de inicio de sesión de seguridad de ONTAP es compatible. cert Método de autenticación.

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>

Prueba de autenticación utilizando el certificado generado. Reemplace < ONTAP Management LIF> y <vserver name> con la IP de Management LIF y el nombre de SVM. Debe asegurarse de que la LIF tenga configurada su política de servicio para 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>'

Codifique el certificado, la clave y el certificado de CA de confianza con Base64.

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

Crea el backend utilizando los valores obtenidos en el paso anterior.

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

Actualizar los métodos de autenticación o rotar las credenciales

Puedes actualizar un backend existente para usar un método de autenticación diferente o para rotar sus credenciales. Esto funciona en ambos sentidos: los sistemas de gestión de backends que utilizan nombre de usuario/contraseña pueden actualizarse para usar certificados; los sistemas de gestión de backends que utilizan certificados pueden actualizarse para basarse en nombre de usuario/contraseña. Para ello, debe eliminar el método de autenticación existente y agregar el nuevo método de autenticación. A continuación, utilice el archivo backend.json actualizado que contiene los parámetros necesarios para ejecutar 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 |
+------------+----------------+--------------------------------------+--------+---------+

Al rotar las contraseñas, el administrador de almacenamiento primero debe actualizar la contraseña del usuario en ONTAP. A continuación se realiza una actualización del servidor. Al rotar los certificados, se pueden agregar varios certificados al usuario. Posteriormente, se actualiza el sistema backend para utilizar el nuevo certificado, tras lo cual se puede eliminar el certificado antiguo del clúster ONTAP .

La actualización de un backend no interrumpe el acceso a los volúmenes que ya se han creado, ni afecta a las conexiones de volumen realizadas posteriormente. Una actualización exitosa del backend indica que Trident puede comunicarse con el backend de ONTAP y gestionar futuras operaciones de volumen.

Cree un rol ONTAP personalizado para Trident.

Puede crear un rol de clúster ONTAP con privilegios mínimos para que no tenga que usar el rol de administrador de ONTAP para realizar operaciones en Trident. Cuando incluyes el nombre de usuario en una configuración de backend de Trident , Trident utiliza el rol de clúster ONTAP que creaste para realizar las operaciones.

Referirse a"Generador de roles personalizados de Trident" Para obtener más información sobre la creación de roles personalizados de Trident .

Uso de la CLI de ONTAP

Crea un nuevo rol utilizando el siguiente comando:

security login role create <role_name\> -cmddirname "command" -access all –vserver <svm_name\>
Crea un nombre de usuario para el usuario de Trident :

security login create -username <user_name\> -application ontapi -authmethod <password\> -role <name_of_role_in_step_1\> –vserver <svm_name\> -comment "user_description"
Asigna el rol al usuario:

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

Usando el Administrador del sistema

Realice los siguientes pasos en ONTAP System Manager:

Crea un rol personalizado:
1. Para crear un rol personalizado a nivel de clúster, seleccione Clúster > Configuración.
  
  (O) Para crear un rol personalizado a nivel de SVM, seleccione Almacenamiento > Máquinas virtuales de almacenamiento > required SVM > Configuración > Usuarios y roles.
2. Seleccione el icono de flecha (→) junto a Usuarios y roles.
3. Seleccione **Agregar en Roles.
4. Define las reglas para el rol y haz clic en Guardar.
Asigna el rol al usuario de Trident *: + Realiza los siguientes pasos en la página *Usuarios y roles:
1. Seleccione el icono Agregar *+ debajo de Usuarios.
2. Seleccione el nombre de usuario requerido y seleccione un rol en el menú desplegable para Rol.
3. Haga clic en Guardar.

Para obtener más información, consulte las siguientes páginas:

Gestionar las políticas de exportación NFS

Trident utiliza políticas de exportación NFS para controlar el acceso a los volúmenes que aprovisiona.

Trident ofrece dos opciones al trabajar con políticas de exportación:

Trident puede gestionar dinámicamente la propia política de exportación; en este modo de funcionamiento, el administrador de almacenamiento especifica una lista de bloques CIDR que representan direcciones IP admisibles. Trident agrega automáticamente a la política de exportación, en el momento de la publicación, las direcciones IP de los nodos aplicables que se encuentren dentro de estos rangos. Alternativamente, cuando no se especifican CIDR, todas las IP de unidifusión de ámbito global que se encuentren en el nodo al que se publica el volumen se agregarán a la política de exportación.
Los administradores de almacenamiento pueden crear una política de exportación y agregar reglas manualmente. Trident utiliza la política de exportación predeterminada a menos que se especifique un nombre de política de exportación diferente en la configuración.

Gestionar dinámicamente las políticas de exportación

Trident ofrece la capacidad de gestionar dinámicamente las políticas de exportación para los sistemas backend de ONTAP . Esto proporciona al administrador de almacenamiento la capacidad de especificar un espacio de direcciones permitido para las IP de los nodos de trabajo, en lugar de definir reglas explícitas manualmente. Simplifica enormemente la gestión de la política de exportación; las modificaciones a la política de exportación ya no requieren intervención manual en el clúster de almacenamiento. Además, esto ayuda a restringir el acceso al clúster de almacenamiento únicamente a los nodos de trabajo que están montando volúmenes y tienen direcciones IP dentro del rango especificado, lo que permite una gestión automatizada y de grano fino.

No utilice la traducción de direcciones de red (NAT) cuando utilice políticas de exportación dinámicas. Con NAT, el controlador de almacenamiento ve la dirección NAT de front-end y no la dirección IP real del host, por lo que el acceso se denegará cuando no se encuentre ninguna coincidencia en las reglas de exportación.

Ejemplo

Existen dos opciones de configuración que deben utilizarse. Aquí tenéis un ejemplo de definición 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

Al utilizar esta función, debe asegurarse de que la unión raíz en su SVM tenga una política de exportación creada previamente con una regla de exportación que permita el bloque CIDR del nodo (como la política de exportación predeterminada). Siga siempre las mejores prácticas recomendadas NetApp para dedicar una SVM a Trident.

Aquí tienes una explicación de cómo funciona esta función utilizando el ejemplo anterior:

autoExportPolicy`está configurado para `true . Esto indica que Trident crea una política de exportación para cada volumen aprovisionado con este backend para el svm1 SVM y gestionar la adición y eliminación de reglas utilizando autoexportCIDRs bloques de direcciones. Hasta que un volumen se conecta a un nodo, el volumen utiliza una política de exportación vacía sin reglas para evitar el acceso no deseado a ese volumen. Cuando se publica un volumen en un nodo, Trident crea una política de exportación con el mismo nombre que el qtree subyacente que contiene la IP del nodo dentro del bloque CIDR especificado. Estas direcciones IP también se añadirán a la política de exportación utilizada por el FlexVol volume principal.
- Por ejemplo:
  - UUID del backend 403b5326-8482-40db-96d0-d83fb3f4daec
  - autoExportPolicy`empezar a `true
  - prefijo de almacenamiento trident
  - UUID de PVC a79bcf5f-7b6d-4a40-9876-e2551f159c1c
  - El qtree denominado trident_pvc_a79bcf5f_7b6d_4a40_9876_e2551f159c1c crea una política de exportación para el FlexVol denominado trident-403b5326-8482-40db96d0-d83fb3f4daec , una política de exportación para el qtree llamado
    trident_pvc_a79bcf5f_7b6d_4a40_9876_e2551f159c1c y una política de exportación vacía llamada trident_empty en la SVM. Las reglas para la política de exportación de FlexVol serán un superconjunto de cualquier regla contenida en las políticas de exportación de qtree. La política de exportación vacía será reutilizada por cualquier volumen que no esté adjunto.
`autoExportCIDRs`Contiene una lista de bloques de direcciones. Este campo es opcional y por defecto es ["0.0.0.0/0", "::/0"]. Si no se define, Trident agrega todas las direcciones unicast de ámbito global que se encuentren en los nodos de trabajo con publicaciones.

En este ejemplo, el 192.168.0.0/24 Se proporciona espacio de direcciones. Esto indica que las direcciones IP de los nodos de Kubernetes que se encuentren dentro de este rango de direcciones con publicaciones se agregarán a la política de exportación que crea Trident . Cuando Trident registra un nodo en el que se ejecuta, recupera las direcciones IP del nodo y las compara con los bloques de direcciones proporcionados en autoExportCIDRs En el momento de la publicación, después de filtrar las direcciones IP, Trident crea las reglas de política de exportación para las direcciones IP de los clientes del nodo al que está publicando.

Puedes actualizar autoExportPolicy y autoExportCIDRs para los backends después de crearlos. Puede agregar nuevos CIDR para un backend que se administra automáticamente o eliminar los CIDR existentes. Tenga cuidado al eliminar CIDR para asegurarse de que no se pierdan las conexiones existentes. También puedes optar por desactivar autoExportPolicy para un backend y recurrir a una política de exportación creada manualmente. Esto requerirá configurar el exportPolicy parámetro en la configuración de tu backend.

Después de que Trident crea o actualiza un backend, puede comprobar el backend mediante tridentctl o el correspondiente 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

Cuando se elimina un nodo, Trident revisa todas las políticas de exportación para eliminar las reglas de acceso correspondientes al nodo. Al eliminar la IP de este nodo de las políticas de exportación de los backends administrados, Trident evita montajes no autorizados, a menos que esta IP sea reutilizada por un nuevo nodo en el clúster.

Para los backends existentes, actualizar el backend con tridentctl update backend garantiza que Trident gestione automáticamente las políticas de exportación. Esto crea dos nuevas políticas de exportación que reciben el nombre del UUID del backend y del nombre del qtree cuando sea necesario. Los volúmenes que se encuentren en el backend utilizarán las políticas de exportación recién creadas después de desmontarlos y volverlos a montar.

Eliminar un backend con políticas de exportación autogestionadas eliminará la política de exportación creada dinámicamente. Si se vuelve a crear el backend, se tratará como un backend nuevo y dará lugar a la creación de una nueva política de exportación.

Si se actualiza la dirección IP de un nodo activo, debe reiniciar el pod de Trident en el nodo. A continuación, Trident actualizará la política de exportación para los backends que administra para reflejar este cambio de IP.

Preparar el aprovisionamiento de volúmenes SMB

Con un poco de preparación adicional, puede aprovisionar volúmenes SMB usando ontap-nas conductores.

Debes configurar los protocolos NFS y SMB/CIFS en la SVM para crear una ontap-nas-economy Volumen SMB para clústeres ONTAP locales. Si no se configura alguno de estos protocolos, la creación del volumen SMB fallará.

`autoExportPolicy`No es compatible con volúmenes SMB.

Antes de empezar

Antes de poder aprovisionar volúmenes SMB, debe tener lo siguiente.

Un clúster de Kubernetes con un nodo controlador Linux y al menos un nodo de trabajo Windows que ejecuta Windows Server 2022. Trident solo admite volúmenes SMB montados en pods que se ejecutan en nodos Windows.
Al menos un secreto de Trident que contenga sus credenciales de Active Directory. Para generar secretos smbcreds :
```
kubectl create secret generic smbcreds --from-literal username=user --from-literal password='password'
```
Un proxy CSI configurado como servicio de Windows. Para configurar un csi-proxy , consulte a"GitHub: Proxy CSI" o"GitHub: Proxy CSI para Windows" para nodos de Kubernetes que se ejecutan en Windows.

Pasos

Para ONTAP local, opcionalmente puede crear un recurso compartido SMB o Trident puede crearlo por usted.

Se requieren recursos compartidos SMB para Amazon FSx para ONTAP.

Puedes crear los recursos compartidos de administración SMB de dos maneras: utilizando…"Consola de administración de Microsoft" Complemento de carpetas compartidas o mediante la CLI de ONTAP . Para crear los recursos compartidos SMB mediante la CLI de ONTAP :
1. Si es necesario, cree la estructura de rutas de directorio para el recurso compartido.
  
  El vserver cifs share create El comando verifica la ruta especificada en la opción -path durante la creación del recurso compartido. Si la ruta especificada no existe, el comando falla.
2. Cree un recurso compartido SMB asociado con la SVM especificada:
  vserver cifs share create -vserver vserver_name -share-name share_name -path path [-share-properties share_properties,...] [other_attributes] [-comment text]
3. Verifique que se haya creado el recurso compartido:
  vserver cifs share show -share-name share_name
  Referirse a"Crear un recurso compartido SMB" Para más detalles.

Al crear el backend, debe configurar lo siguiente para especificar los volúmenes SMB. Para conocer todas las opciones de configuración del backend de FSx para ONTAP , consulte"Opciones de configuración y ejemplos de FSx para ONTAP" .

Parámetro Descripción Ejemplo

Parámetro	Descripción	Ejemplo
`smbShare`	Puede especificar una de las siguientes opciones: el nombre de un recurso compartido SMB creado mediante la Consola de administración de Microsoft o la CLI de ONTAP ; un nombre para permitir que Trident cree el recurso compartido SMB; o puede dejar el parámetro en blanco para evitar el acceso compartido común a los volúmenes. Este parámetro es opcional para ONTAP local. Este parámetro es obligatorio para los backends de Amazon FSx para ONTAP y no puede estar en blanco.	`smb-share`
`nasType`	Debe configurarse en `smb` . Si es nulo, el valor predeterminado es `nfs` .	`smb`
`securityStyle`	Estilo de seguridad para nuevos volúmenes. Debe configurarse en `ntfs` o `mixed` para volúmenes SMB.	ntfs`o `mixed para volúmenes SMB
`unixPermissions`	Modo para nuevos volúmenes. Debe dejarse vacío para volúmenes SMB.	""

smbShare

Puede especificar una de las siguientes opciones: el nombre de un recurso compartido SMB creado mediante la Consola de administración de Microsoft o la CLI de ONTAP ; un nombre para permitir que Trident cree el recurso compartido SMB; o puede dejar el parámetro en blanco para evitar el acceso compartido común a los volúmenes. Este parámetro es opcional para ONTAP local. Este parámetro es obligatorio para los backends de Amazon FSx para ONTAP y no puede estar en blanco.

smb-share

nasType

Debe configurarse en smb . Si es nulo, el valor predeterminado es nfs .

smb

securityStyle

Estilo de seguridad para nuevos volúmenes. Debe configurarse en ntfs o mixed para volúmenes SMB.

ntfs`o `mixed para volúmenes SMB

unixPermissions

Modo para nuevos volúmenes. Debe dejarse vacío para volúmenes SMB.

Habilitar SMB seguro

A partir de la versión 25.06, NetApp Trident admite el aprovisionamiento seguro de volúmenes SMB creados mediante ontap-nas y ontap-nas-economy backends. Cuando SMB seguro está habilitado, puede proporcionar acceso controlado a los recursos compartidos SMB para usuarios y grupos de usuarios de Active Directory (AD) mediante listas de control de acceso (ACL).

Puntos para recordar

Importador ontap-nas-economy No se admiten volúmenes.
Solo se admiten clones de solo lectura para ontap-nas-economy volúmenes.
Si Secure SMB está habilitado, Trident ignorará el recurso compartido SMB mencionado en el backend.
La actualización de la anotación PVC, la anotación de la clase de almacenamiento y el campo backend no actualiza la ACL del recurso compartido SMB.
Las ACL de recursos compartidos SMB especificadas en la anotación del PVC clonado tendrán prioridad sobre las del PVC de origen.
Asegúrese de proporcionar usuarios de AD válidos al habilitar SMB seguro. Los usuarios no válidos no se agregarán a la ACL.
Si se proporciona el mismo usuario de AD en el backend, la clase de almacenamiento y el PVC con diferentes permisos, la prioridad de permisos será: PVC, clase de almacenamiento y, por último, backend.
Se admite Secure SMB para ontap-nas Se aplica a las importaciones de volumen gestionadas y no a las importaciones de volumen no gestionadas.

Pasos

Especifique adAdminUser en TridentBackendConfig como se muestra en el siguiente ejemplo:

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

Agregue la anotación en la clase de almacenamiento.

Añade el trident.netapp.io/smbShareAdUser Anotación a la clase de almacenamiento para habilitar SMB seguro sin fallos. El valor de usuario especificado para la anotación trident.netapp.io/smbShareAdUser debe ser el mismo que el nombre de usuario especificado en el smbcreds secreto. Puedes elegir una de las siguientes opciones para smbShareAdUserPermission : full_control , change , o read . El permiso predeterminado es 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

Crea un tubo de PVC.

El siguiente ejemplo crea 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

Prepárese para configurar un backend con controladores NAS ONTAP .

Creating your file...

Requisitos

Autenticar el backend de ONTAP

Habilitar la autenticación basada en credenciales

Habilitar la autenticación basada en certificados

Actualizar los métodos de autenticación o rotar las credenciales

Cree un rol ONTAP personalizado para Trident.

Gestionar las políticas de exportación NFS

Gestionar dinámicamente las políticas de exportación

Ejemplo

Preparar el aprovisionamiento de volúmenes SMB

Habilitar SMB seguro