El artículo solicitado no está disponible. No corresponde a esta versión del producto o la información relevante está organizada de forma diferente en esta versión de los documentos. Puedes buscar, examinar o volver a la otra versión.

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árate para configurar un backend con controladores ONTAP NAS

02/25/2026

PDF

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

A partir de la versión 25.10, NetApp Trident es compatible con "Sistema de almacenamiento NetApp AFX". NetApp AFX storage systems difieren de otros sistemas ONTAP (ASA, AFF y FAS) en la implementación de su capa de almacenamiento.

Sólo el ontap-nas controlador (con protocolo NFS) es compatible con los sistemas AFX; el protocolo SMB no es compatible.

En la configuración del backend de Trident, no necesitas especificar que tu sistema es AFX. Cuando seleccionas ontap-nas como storageDriverName, Trident detecta automáticamente los sistemas AFX.

Requisitos

Para todos los backends de ONTAP, Trident requiere que al menos un agregado esté asignado a la 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 use el ontap-nas controlador y una clase Bronze que use el ontap-nas-economy otro.
Todos tus nodos worker de Kubernetes deben tener instaladas las herramientas NFS adecuadas. Consulta "aquí" para más detalles.
Trident solo admite volúmenes SMB montados en pods que se ejecutan en nodos Windows. Consulta Prepárate para aprovisionar volúmenes SMB para más detalles.

Autentica el backend de ONTAP

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

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

Puedes actualizar los backends existentes para pasar de métodos basados en credenciales a métodos basados en certificados y viceversa. Sin embargo, solo se admite un método de autenticación a la vez. Para cambiar a otro método de autenticación, debes eliminar el método existente de la configuración del backend.

Si intentas 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.

Habilita la autenticación basada en credenciales

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

Un ejemplo de definición de backend se verá 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"
    }
}

Ten en cuenta que la definición del backend es el único lugar donde se almacenan las credenciales en texto plano. Después de crear el backend, los nombres de usuario y contraseñas se codifican con Base64 y se almacenan como secretos de Kubernetes. La creación o actualización de un backend es el único paso que requiere conocimiento de las credenciales. Así que es una operación solo para el administrador, que debe realizar el administrador de Kubernetes o el administrador de almacenamiento.

Habilita la autenticación basada en certificados

Los backends, tanto nuevos como 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 de cliente.
clientPrivateKey: Valor codificado en Base64 de la clave privada asociada.
trustedCACertificate: Valor codificado en Base64 del certificado de CA de confianza. Si usas una CA de confianza, tienes que proporcionar este parámetro. Esto se puede ignorar si no usas una CA de confianza.

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

Pasos

Genera un certificado y una clave de cliente. Al generarlos, asigna el nombre común (CN) al usuario de ONTAP con el que te vas a 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"
```

Agrega un certificado de CA de confianza al clúster de ONTAP. Esto puede que ya lo haya gestionado el administrador de almacenamiento. Ignora esto si no se usa 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>

Instala 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

Confirma que el rol de inicio de sesión de seguridad de ONTAP admite cert el 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 la autenticación usando el certificado generado. Reemplaza <ONTAP Management LIF> y <vserver name> con la dirección IP de Management LIF y el nombre de SVM. Debes asegurarte de que el LIF tenga su política de servicio configurada en 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>'

Codifica el certificado, la clave y el certificado de CA confiable con Base64.

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

Crea un backend usando 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 |
+------------+----------------+--------------------------------------+--------+---------+

Actualiza los métodos de autenticación o rota 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 backends que usan nombre de usuario y contraseña pueden actualizarse para usar certificados; los backends que utilizan certificados pueden actualizarse para usar nombre de usuario y contraseña. Para hacer esto, debes eliminar el método de autenticación existente y agregar el nuevo método de autenticación. Luego usa 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 contraseñas, el administrador de almacenamiento debe primero actualizar la contraseña del usuario en ONTAP. Luego, se realiza una actualización del backend. Al rotar certificados, se pueden agregar varios certificados al usuario. Después, el backend se actualiza para usar el nuevo certificado, y luego se puede eliminar el certificado antiguo del clúster de ONTAP.

Actualizar un backend no interrumpe el acceso a los volúmenes ya creados ni afecta las conexiones de volumen realizadas después. Una actualización correcta del backend indica que Trident puede comunicarse con el backend de ONTAP y gestionar futuras operaciones de volumen.

Crear rol ONTAP personalizado para Trident

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

Consulta "Generador de roles personalizados de Trident" para más información sobre cómo crear roles personalizados de Trident.

Usando ONTAP CLI

Crea un nuevo rol usando el siguiente comando:

security login role create <role_name\> -cmddirname "command" -access all –vserver <svm_name\>
Crea un nombre de usuario para el usuario 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 System Manager

Realiza los siguientes pasos en ONTAP System Manager:

Crea un rol personalizado:
1. Para crear un rol personalizado a nivel de cluster, selecciona Cluster > Settings.
  
  (O) Para crear un rol personalizado a nivel de SVM, selecciona Storage > Storage VMs > required SVM> Settings > Users and Roles.
2. Selecciona el icono de flecha (→) junto a Users and Roles.
3. Selecciona +Add en Roles.
4. Define las reglas para el rol y haz clic en Guardar.
Asigna el rol al usuario Trident: + Realiza los siguientes pasos en la página Usuarios y roles:
1. Selecciona el icono Add + en Usuarios.
2. Selecciona el nombre de usuario requerido y elige un rol en el menú desplegable de Role.
3. Haz clic en Guardar.

Consulta las siguientes páginas para obtener más información:

Gestiona las políticas de exportación de NFS

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

Trident ofrece dos opciones cuando trabajas con políticas de exportación:

Trident puede gestionar dinámicamente la política de exportación por sí mismo; en este modo de funcionamiento, el administrador de almacenamiento especifica una lista de bloques CIDR que representan direcciones IP admisibles. Trident añade automáticamente a la política de exportación las direcciones IP de nodo aplicables que estén dentro de estos rangos en el momento de la publicación. Como alternativa, cuando no se especifican CIDR, se añadirán a la política de exportación todas las direcciones IP de unidifusión de ámbito global que se encuentren en el nodo al que se está publicando el volumen.
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.

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

Trident ofrece la capacidad de gestionar dinámicamente las políticas de exportación para los backends de ONTAP. Esto le da al administrador de almacenamiento la posibilidad de especificar un espacio de direcciones permitido para las direcciones IP de los nodos de trabajo, en vez de definir reglas explícitas manualmente. Esto simplifica mucho la gestión de las políticas de exportación; las modificaciones en 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 solo 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 detallada.

No uses Network Address Translation (NAT) cuando uses políticas de exportación dinámicas. Con NAT, el controlador de almacenamiento ve la dirección NAT del frontend y no la dirección IP real del host, así que se denegará el acceso cuando no se encuentre coincidencia en las reglas de exportación.

Ejemplo

Hay dos opciones de configuración que deben utilizarse. Aquí tienes 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 usar esta función, debes asegurarte de que la unión raíz de tu SVM tenga una política de exportación previamente creada con una regla de exportación que permita el bloque CIDR del nodo (como la política de exportación predeterminada). Sigue siempre la práctica recomendada por NetApp de dedicar una SVM para Trident.

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

autoExportPolicy se establece en true. Esto indica que Trident crea una política de exportación para cada volumen aprovisionado con este backend para la svm1 SVM y gestiona la adición y eliminación de reglas usando bloques de direcciones autoexportCIDRs. 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 un volumen se publica en un nodo, Trident crea una política de exportación con el mismo nombre que el qtree subyacente que contiene la dirección 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 volumen principal FlexVol.
- Por ejemplo:
  - UUID de backend 403b5326-8482-40db-96d0-d83fb3f4daec
  - autoExportPolicy establecer en true
  - prefijo de almacenamiento trident
  - PVC UUID a79bcf5f-7b6d-4a40-9876-e2551f159c1c
  - El qtree llamado trident_pvc_a79bcf5f_7b6d_4a40_9876_e2551f159c1c crea una política de exportación para el FlexVol llamado 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 del FlexVol serán un superconjunto de cualquier regla contenida en las políticas de exportación del qtree. La política de exportación vacía se reutilizará para cualquier volumen que no esté adjunto.
autoExportCIDRs contiene una lista de bloques de direcciones. Este campo es opcional y su valor predeterminado es ["0.0.0.0/0", "::/0"]. Si no se define, Trident agrega todas las direcciones unicast de alcance global que se encuentran en los nodos de trabajo con publicaciones.

En este ejemplo, el espacio de direcciones 192.168.0.0/24 se proporciona. Esto indica que las direcciones IP de los nodos de Kubernetes que estén dentro de este rango de direcciones con publicaciones se añadirá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. Al momento de publicar, después de filtrar las IP, Trident crea las reglas de la política de exportación para las direcciones IP de cliente del nodo al que está publicando.

Puedes actualizar autoExportPolicy y autoExportCIDRs para los backends después de crearlos. Puedes añadir nuevos CIDR para un backend que se gestiona automáticamente o eliminar los CIDR existentes. Ten cuidado al eliminar los CIDR para asegurarte de que no se interrumpan las conexiones existentes. También puedes elegir deshabilitar autoExportPolicy para un backend y volver a una política de exportación creada manualmente. Esto requerirá configurar el parámetro exportPolicy en la configuración del backend.

Después de que Trident crea o actualiza un backend, puedes verificar el backend usando 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

Al eliminar un nodo, Trident revisa todas las políticas de exportación para eliminar las reglas de acceso correspondientes al nodo. Al eliminar esta dirección IP de 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 preexistentes, actualizar el backend con tridentctl update backend asegura que Trident gestione las políticas de exportación automáticamente. Esto crea dos nuevas políticas de exportación nombradas según el UUID y el nombre del qtree del backend cuando sean necesarias. Los volúmenes que están presentes en el backend usarán las nuevas políticas de exportación después de desmontarlos y volver a montarlos.

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

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

Prepárate para aprovisionar volúmenes SMB

Con un poco de preparación adicional, puedes aprovisionar volúmenes SMB usando `ontap-nas`drivers.

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

autoExportPolicy no es compatible con volúmenes SMB.

Antes de empezar

Antes de que puedas aprovisionar volúmenes SMB, debes tener lo siguiente.

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

Pasos

Para ONTAP local, puedes crear opcionalmente un recurso compartido SMB o Trident puede crear uno para ti.

Se requieren recursos compartidos SMB para Amazon FSx for ONTAP.

Puedes crear los recursos compartidos de administrador de SMB de dos maneras: usando el complemento "Microsoft Management Console" Shared Folders o usando la CLI de ONTAP. Para crear los recursos compartidos de SMB usando la CLI de ONTAP:
1. Si es necesario, crea la estructura de ruta del directorio para el recurso compartido.
  
  El `vserver cifs share create`comando comprueba 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. Crea 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. Verifica que se creó el recurso compartido:
  vserver cifs share show -share-name share_name
  Consulta "Crear un recurso compartido SMB" para obtener detalles completos.

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

Parámetro Descripción Ejemplo

Parámetro	Descripción	Ejemplo
`smbShare`	Puedes especificar uno de los siguientes: el nombre de un recurso compartido SMB creado usando Microsoft Management Console o la CLI de ONTAP, un nombre para permitir que Trident cree el recurso compartido SMB, o puedes 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 for ONTAP y no puede estar en blanco.	`smb-share`
`nasType`	Debe establecerse 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

Puedes especificar uno de los siguientes: el nombre de un recurso compartido SMB creado usando Microsoft Management Console o la CLI de ONTAP, un nombre para permitir que Trident cree el recurso compartido SMB, o puedes 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 for ONTAP y no puede estar en blanco.

smb-share

nasType

Debe establecerse 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.

Habilita 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, puedes proporcionar acceso controlado a los recursos compartidos SMB para usuarios y grupos de usuarios de Active Directory (AD) usando listas de control de acceso (ACL).

Puntos para recordar

No se admite la importación ontap-nas-economy de 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.
Actualizar la anotación de PVC, la anotación de la storage class y el campo backend no actualiza la ACL del recurso compartido SMB.
La ACL de recurso compartido SMB especificada en la anotación del PVC clonado tendrá prioridad sobre las del PVC de origen.
Asegúrate de proporcionar usuarios de AD válidos al habilitar SMB seguro. Los usuarios no válidos no se añadirán a la ACL.
Si proporcionas 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 luego backend.
SMB seguro es compatible para `ontap-nas`importaciones de volúmenes administrados y no aplica a importaciones de volúmenes no administrados.

Pasos

Especifica 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

Añade la anotación en la clase de almacenamiento.

Agrega la trident.netapp.io/smbShareAdUser anotación a la clase de almacenamiento para habilitar SMB seguro sin fallar. 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 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 PVC.

El siguiente ejemplo crea una 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árate para configurar un backend con controladores ONTAP NAS

Creating your file...

Requisitos

Autentica el backend de ONTAP

Habilita la autenticación basada en credenciales

Habilita la autenticación basada en certificados

Actualiza los métodos de autenticación o rota las credenciales

Crear rol ONTAP personalizado para Trident

Gestiona las políticas de exportación de NFS

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

Ejemplo

Prepárate para aprovisionar volúmenes SMB

Habilita SMB seguro