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 el backend con los controladores SAN de ONTAP.

10/29/2025 Colaboradores

PDF

Comprenda los requisitos y las opciones de autenticación para configurar un backend ONTAP con controladores ONTAP SAN.

Requisitos

Para todos los backends de ONTAP , Trident requiere que se asigne al menos un agregado al SVM.

"Sistemas ASA r2"Se diferencian de otros sistemas ONTAP (ASA, AFF y FAS) en la implementación de su capa de almacenamiento. En los sistemas ASA r2, se utilizan zonas de disponibilidad de almacenamiento en lugar de agregados. Referirse a"este" Artículo de la base de conocimientos sobre cómo asignar agregados a SVM en sistemas ASA r2.

Recuerda que también puedes ejecutar más de un controlador y crear clases de almacenamiento que apunten a uno u otro. Por ejemplo, podrías configurar un san-dev clase que utiliza la ontap-san conductor y un san-default clase que utiliza la ontap-san-economy uno.

Todos los nodos de trabajo de Kubernetes deben tener instaladas las herramientas iSCSI adecuadas. Referirse a "Preparar el nodo de trabajo" Para más detalles.

Autenticar el backend de ONTAP

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

Basado en credenciales: El nombre de usuario y la contraseña de un usuario de ONTAP con los permisos necesarios. Se recomienda utilizar 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: Trident también puede comunicarse con un clúster ONTAP utilizando un certificado instalado en el backend. 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-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"
}

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 o 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=admin"
```

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 admin -application ontapi -authentication-method cert
security login create -user-or-group-name admin -application http -authentication-method cert

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.

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

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

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:

Autenticar conexiones con CHAP bidireccional

Trident puede autenticar sesiones iSCSI con CHAP bidireccional para la ontap-san y ontap-san-economy conductores. Esto requiere habilitar el useCHAP opción en la definición de tu backend. Cuando se configura para true Trident configura la seguridad del iniciador predeterminado de la SVM en CHAP bidireccional y establece el nombre de usuario y los secretos desde el archivo de backend. NetApp recomienda utilizar CHAP bidireccional para autenticar las conexiones. Consulte la siguiente configuración de ejemplo:

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

El useCHAP El parámetro es una opción booleana que solo se puede configurar una vez. Está configurado como falso por defecto. Una vez que lo hayas configurado como verdadero, no podrás configurarlo como falso.

Además de useCHAP=true , el chapInitiatorSecret , chapTargetInitiatorSecret , chapTargetUsername , y chapUsername Los campos deben incluirse en la definición del backend. Los secretos se pueden cambiar después de crear un backend ejecutando tridentctl update .

Cómo funciona

Mediante la configuración useCHAP Para que sea verdadero, el administrador de almacenamiento le indica a Trident que configure CHAP en el backend de almacenamiento. Esto incluye lo siguiente:

Configuración de CHAP en la SVM:
- Si el tipo de seguridad del iniciador predeterminado de la SVM es ninguno (establecido por defecto) y no hay LUN preexistentes en el volumen, Trident establecerá el tipo de seguridad predeterminado en CHAP y proceda a configurar el iniciador CHAP y el nombre de usuario y las claves de destino.
- Si la SVM contiene LUN, Trident no habilitará CHAP en la SVM. Esto garantiza que el acceso a las LUN que ya están presentes en la SVM no se vea restringido.
Configurar el nombre de usuario y las claves secretas del iniciador y del destino CHAP; estas opciones deben especificarse en la configuración del backend (como se muestra arriba).

Una vez creado el backend, Trident crea un correspondiente tridentbackend CRD y almacena los secretos CHAP y los nombres de usuario como secretos de Kubernetes. Todos los PV que Trident cree en este backend se montarán y conectarán a través de CHAP.

Rotar credenciales y actualizar backends

Puede actualizar las credenciales CHAP actualizando los parámetros CHAP en el archivo backend.json archivo. Esto requerirá actualizar los secretos CHAP y utilizar el tridentctl update orden para reflejar estos cambios.

Al actualizar los secretos CHAP para un backend, debe usar tridentctl para actualizar el backend. No actualice las credenciales en el clúster de almacenamiento mediante ONTAP CLI o ONTAP System Manager, ya que Trident no podrá detectar estos cambios.

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

Las conexiones existentes no se verán afectadas; seguirán activas si Trident actualiza las credenciales en la SVM. Las nuevas conexiones utilizan las credenciales actualizadas y las conexiones existentes permanecen activas. Desconectar y volver a conectar los PV antiguos hará que utilicen las credenciales actualizadas.