Rotar claves de autenticación y certificados de almacenamiento

El dispositivo air-gapped de Google Distributed Cloud (GDC) adopta ONTAP Select (OTS) como proveedor de almacenamiento definido por software. OTS tiene su propio sistema de autenticación, en el que cada identidad (servicio principal o cliente) tiene un nombre y una clave asociados.

En este documento se describen los pasos que debes seguir para rotar las claves y los certificados de autenticación en los siguientes casos:

• rotación de claves programada periódicamente para asegurarse de que el dispositivo cumple los requisitos y es seguro.
• exposición de claves. Debes rotar la clave expuesta lo antes posible.

Antes de empezar

Asegúrate de que tienes el siguiente acceso:

• Acceso a la consola de administración del clúster ONTAP
• Kubeconfig del servidor de la API Management

Rotar las credenciales de IPsec (PSK)

ONTAP admite la autenticación basada en certificados para IPsec a partir de la versión 9.10.1. Esta versión de GDC es la 9.14.1 y usa claves precompartidas.

En el caso de los dispositivos, IPsec se implementa para dos tipos de tráfico OTS:

• Tráfico externo entre hosts de hardware desnudo y SVMs.
• Tráfico interno entre nodos de trabajador.

Vamos a verlos por separado.

Requisitos previos

• Acceso a la consola de administración del clúster ONTAP
• Una nueva clave precompartida
• Kubeconfig del servidor de la API Management
• Acceso a los hosts para actualizar la configuración de StrongSwan

Impacto

Mientras se rotan las políticas de IPsec, los hosts perderán la conectividad IP con el sistema de almacenamiento. Las conexiones se bloquearán o puede que fallen en función del comportamiento de la aplicación. Puedes pausar las cargas de trabajo de los usuarios durante la rotación si es posible, pero no es obligatorio. Las conexiones deberían recuperarse poco después de restablecer los secretos.

Rotación de claves para el tráfico externo de OTS

Para validar la rotación, usa el siguiente comando y compara el resultado:

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get StorageEncryptionConnections -n gpc-system

Resultado:

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-1ba9796c   bm-1ba9796c        root-admin              10.4.4.0/24   bm-1ba9796c-pre-shared-key   True    6h16m
bm-96a5f32a   bm-96a5f32a        root-admin              10.4.4.0/24   bm-96a5f32a-pre-shared-key   True    16h
bm-e07f4a4f   bm-e07f4a4f        root-admin              10.4.4.0/24   bm-e07f4a4f-pre-shared-key   True    21h

Verifica que el campo READY sea verdadero para el host específico en el que has ejecutado la secuencia de comandos anteriormente.

Rota manualmente la PSK si detectas algún error durante la validación.

1. Ejecuta el comando siguiente:

   export KUBECONFIG= #path to root-admin kubeconfig
   

   mgmt_ip="$(kubectl get storagecluster -A -o jsonpath='{.items[0].spec.network.clusterManagement.ip}')"
   
   username="$(kubectl get secret storage-root-level1 -n gpc-system -o jsonpath='{.data.username}' | base64 -d)"
   
   password="$(kubectl get secret storage-root-level1 -n gpc-system -o jsonpath='{.data.password}' | base64 -d)"
   

2. Para ver la contraseña y copiarla en el portapapeles, sigue estos pasos:

   echo $password
   

3. Inicia sesión en la consola de ONTAP:

   ssh $username@$mgmt_ip
   

   Cuando se te pida la contraseña, pega la que has copiado en el paso anterior.

4. Usa la siguiente secuencia de comandos para la rotación de credenciales:

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl get StorageEncryptionConnections -n gpc-system
   

   Resultado:

   NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
   bm-1ba9796c   bm-1ba9796c        root-admin              10.4.4.0/24   bm-1ba9796c-pre-shared-key   True    6h16m
   bm-96a5f32a   bm-96a5f32a        root-admin              10.4.4.0/24   bm-96a5f32a-pre-shared-key   True    16h
   bm-e07f4a4f   bm-e07f4a4f        root-admin              10.4.4.0/24   bm-e07f4a4f-pre-shared-key   True    21h
   

   Por cada anfitrión que quieras rotar, puedes ejecutar lo siguiente:

   export bm_host= //name of bm-host from above
   export secret="${bm_host}-pre-shared-key"
   export job_name="os-policy-config-host-ipsec-${bm_host}"
   export ns="gpc-system"
   export svm="$(kubectl get storageencryptionconnections "${bm_host}" -n "${ns}" -o jsonpath='{.spec.storageVirtualMachineRef.name}')"
   

   Ahora, confirma que ves todos los componentes de la conexión de cifrado de almacenamiento. Para las conexiones de clústeres de administrador, ya sea root-admin u organization-admin, debes usar el clúster root-admin.

   kubectl get secrets -n "${ns}" "${secret}"
   kubectl get jobs -n "${ns}" "${job_name}"
   

   Si ambos elementos están presentes, puede continuar con el siguiente paso. Si no es así, detente y no modifiques ipsec. Ponte en contacto con el servicio de asistencia técnica.

   kubectl delete secrets -n "${ns}" "${secret}"
   kubectl delete jobs "${job_name}" -n "${ns}"
   

   Ahora, usa el servidor de la API Management para eliminar la conexión storageencryptionconnection.

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl delete storageencryptionconnections "${bm_host}"
   
   annotation_key="reconcile_annotation_key"
   annotation_value="reconcile_annotation_value"
   
   kubectl patch storagevirtualmachines "${svm}" -n "${ns}" --type=merge -p "{\"metadata\":{\"annotations\":{\"$annotation_key\":\"$annotation_value\"}}}"
   kubectl patch storagevirtualmachines "${svm}" -n "${ns}" --type=json -p="[{\"op\": \"remove\", \"path\": \"/metadata/annotations/$annotation_key\"}]"
   

   Rotación de claves para el tráfico interno de OTS

Del mismo modo, para validar la rotación, usa el siguiente comando y compara el resultado:

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get secret ots-internal-pre-shared-key -n gpc-system

Resultado:

NAME                          TYPE     DATA   AGE
ots-internal-pre-shared-key   Opaque   1      18m

kubectl get jobs -n gpc-system | grep os-policy-config-host-ipsec

Resultado:

os-policy-config-host-ipsec-bm-3d33bb857t5bh                Complete   1/1           17s        10m
os-policy-config-host-ipsec-bm-774fa8e6frgr7                Complete   1/1           30s        11m
os-policy-config-host-ipsec-bm-8e452fb29q5wd                Complete   1/1           23s        11m

Verifica que todos los trabajos tengan el estado Complete.

kubectl get StorageEncryptionConnections -n gpc-system

Resultado:

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-3d33bb85   bm-3d33bb85        root-admin              10.4.4.0/24   bm-3d33bb85-pre-shared-key   True    6h16m
bm-774fa8e6   bm-774fa8e6        root-admin              10.4.4.0/24   bm-774fa8e6-pre-shared-key   True    16h
bm-8e452fb2   bm-8e452fb2        root-admin              10.4.4.0/24   bm-8e452fb2-pre-shared-key   True    21h

Verifica que el campo READY sea true en todos los hosts.

1. Elimina todos los CRs del paso 2 en el orden indicado.

   • Elimina el secreto del tráfico interno. sh kubectl delete secret ots-internal-pre-shared-key -n gpc-system

   • Eliminar los tres trabajos de política de SO sh kubectl delete jobs os-policy-config-host-ipsec-bm-3d33bb857t5bh -n gpc-system kubectl delete jobs os-policy-config-host-ipsec-bm-774fa8e6frgr7 -n gpc-system kubectl delete jobs os-policy-config-host-ipsec-bm-8e452fb29q5wd -n gpc-system

   • Eliminar los tres elementos storageencryptionconnection sh kubectl delete StorageEncryptionConnections bm-3d33bb85-root-admin -n gpc-system kubectl delete StorageEncryptionConnections bm-774fa8e6-root-admin -n gpc-system kubectl delete StorageEncryptionConnections bm-8e452fb2-root-admin -n gpc-system

2. Espera unos minutos (entre 3 y 5 minutos). Repite el paso 2 hasta que todos los CR tengan el estado READY o Complete.

Rotar teclas de volumen

En esta sección se describen los pasos manuales para rotar las credenciales de volumen de OTS.

Antes de empezar

Este agente debe seguir estos pasos:

1. Comprueba que cumples los requisitos previos para portátiles.
2. Asegúrate de que puedes iniciar sesión en la consola del clúster de OTS a través de BM01 o BM02.

Iniciar la rotación de las teclas de volumen

En la consola de OTS, activa la rotación única de claves:

volume encryption rekey start -vserver SVM_name -volume volume_name

El siguiente comando cambia la clave de cifrado de vol1 el SVMvs1:

cluster1::> volume encryption rekey start -vserver vs1 -volume vol1

Para ver los nombres de los servidores virtuales y los volúmenes, puedes usar el comando show:

vserver show
volume show

Verificar la rotación de claves de volumen

Una vez que se haya iniciado la rotación de claves, comprueba el estado de la renovación de claves:

volume encryption rekey show

Muestra el estado de la operación de cambio de clave:

cluster1::> volume encryption rekey show

Vserver   Volume   Start Time           Status
-------   ------   ------------------   ---------------------------
vs1       vol1     9/18/2017 17:51:41   Phase 2 of 2 is in progress.

Cuando se haya completado la operación de cambio de clave, comprueba que el volumen esté habilitado para el cifrado:

volume show -is-encrypted true

Muestra los volúmenes cifrados en cluster1:

cluster1::> volume show -is-encrypted true

Vserver  Volume  Aggregate  State  Type  Size  Available  Used
-------  ------  ---------  -----  ----  -----  --------- ----
vs1      vol1    aggr2     online    RW  200GB    160.0GB  20%

Rotar certificados de HSM externo

En esta sección se describe cómo rotar y actualizar los certificados HSM externos de ONTAP.

Requisitos previos

• Acceso de administrador al clúster de ONTAP o a las SVMs pertinentes
• Contraseña actual
• Acceso de kubectl a los clústeres adecuados

Instrucciones

1. Crea una copia de seguridad de los certificados HSM antiguos:

   kubectl get secret aa-aa-external-hsm-creds -n gpc-system -o yaml > external-hsm-creds-old.yaml
   

2. Actualiza el secreto de los certificados HSM en Kubernetes:

   1. Copia el archivo YAML antiguo de secretos: sh cp external-hsm-creds-old.yaml external-hsm-creds-new.yaml

   2. Actualiza el nuevo archivo external-hsm-creds-new.yaml con las nuevas credenciales de HSM, incluido el certificado de AC del servidor, el certificado de cliente público y la clave privada del cliente.

   3. Aplica el cambio y actualiza el objeto secreto del HSM.

      kubectl apply -f external-hsm-creds-new.yaml
      

3. Actualiza los certificados de HSM en ONTAP:

   1. Inicia sesión en la CLI de ONTAP.

   2. Instala el nuevo certificado AC del servidor:

      cluster::> security certificate install -type server-ca -vserver <>
      

   3. Instala el nuevo certificado de cliente:

      cluster::> security certificate install -type client -vserver <>
      

   4. Actualiza la configuración del gestor de claves para usar los certificados recién instalados:

      cluster::> security key-manager external modify -vserver <> -client-cert <> -server-ca-certs <>
      

Validación

1. Verifica el cambio con el estado del gestor de claves:

   cluster::> security key-manager external show-status
   

   Comprueba si los servidores de claves siguen en estado Available.

Rotar la credencial de administrador de almacenamiento

En esta sección se describe cómo cambiar y definir el usuario y la contraseña del administrador de almacenamiento.

Requisitos previos

• Acceso de administrador al clúster de ONTAP o a las SVMs pertinentes
• Contraseña actual
• Acceso de kubectl a los clústeres adecuados

Instrucciones

1. Empieza con el siguiente comando y, a continuación, sigue las indicaciones que aparecen:

   cluster::> security login password
   

2. Actualiza el secreto para que coincida:

   • Opción 1 (interactiva):

     kubectl edit secret -n <netapp_namespace> netapp_credential
     

     Usa el editor para cambiar la contraseña por el nuevo valor codificado en base64.

   • Opción 2 (parche con dependencia de jq):

     k get secret -n <netapp_namespace> netapp_credential -o json | jq '.data["password"]="<new-base64-encoded-password>"' | kubectl apply -f -
     

Rotar las credenciales de acceso de emergencia de ONTAP

Durante la configuración del almacenamiento de archivos y en bloque, se crean cuatro cuentas de usuario de acceso de emergencia que se pueden usar para acceder directamente a ONTAP. Estas credenciales se pueden obtener como secretos en el servidor de la API Management. Una vez que se hayan usado esas credenciales, deben rotarse.

Durante la configuración, se crean dos tipos de secretos: de nivel 1 y de nivel 2. El nivel 1 es storage-root-level1 and storage-root-level1-backup. El nivel 2 es storage-root-level2 and storage-root-level2-backup. Los secretos de nivel 2 deben almacenarse en la caja fuerte y cada nivel tiene dos secretos: uno normal y otro de respaldo. Aunque el software gestiona la eliminación de los secretos normales y de las copias de seguridad simultáneamente, te recomendamos que solo rotes uno de estos secretos de partner a la vez como medida de seguridad adicional.

Los secretos de nivel 1 se rotan automáticamente al cabo de 90 días, pero los de nivel 2 no. Si se usa alguno de estos tipos de secretos, debe rotarse manualmente siguiendo el proceso que se indica a continuación.

Requisitos previos

• Acceso necesario: servidor de la API Management

Validación

1. La rotación de secretos se puede validar comprobando si el secreto sigue marcado para su eliminación. Si no es así, el secreto se ha rotado. Sigue el paso 1 de las instrucciones que se indican a continuación para comprobarlo.

2. Si el secreto es de nivel 2, cópialo en un medio físico y guárdalo en la caja fuerte. Después, el secreto debe marcarse como persistente mediante la anotación "disk.gdc.goog/persisted".

    kubectl annotate secrets
    <secret_name> -n gpc-system disk.gdc.goog/persisted=''
   

Sigue estas instrucciones para rotar manualmente el secreto si detectas algún error durante la validación.

Instrucciones

1. Para comprobar si un secreto se ha marcado para eliminarlo, sigue estos pasos:

   1. Ejecuta el siguiente comando:

      kubectl get secret <secret_name> -n gpc-system -o yaml
      

   2. Si el campo deletionTimestamp está presente en la respuesta, como en este ejemplo, el secreto se marca para su eliminación. De lo contrario, no lo es.

      apiVersion: v1
      data:
        password: KFZbQTJdYjIwSUtVVV1aNytJJVM=
        username: cm9vdC1sdmwy
      immutable: true
      kind: Secret
      metadata:
        annotations:
          cluster-name: aa-aa-stge01
        creationTimestamp: "2022-12-21T05:03:02Z"
        deletionGracePeriodSeconds: 0
        deletionTimestamp: "2022-12-21T14:42:13Z"
        finalizers:
        - ontap.storage.private.gdc.goog/breakglass-finalizer
        labels:
          breakglass-secret: "true"
        name: storage-root-level2
        namespace: gpc-system
        resourceVersion: "591897"
        uid: 6f331f8a-bf48-4d59-9725-6c99c5e766f7
      type: Opaque
      
      

2. Rota el secreto después de usarlo para acceder a ONTAP:

   1. Comprueba si la credencial de partner existe y no está marcada para eliminarse. No continúes y vuelve a estos pasos más adelante si se ha marcado para eliminar.

   2. Si se está rotando el secreto de nivel 2, el secreto del partner debe marcarse como persistente añadiendo la anotación disk.gdc.goog/persisted:

      kubectl annotate secrets
      <secret_name> -n gpc-system disk.gdc.goog/persisted=''
      

   3. Elimina el secreto del clúster con el siguiente comando:

      kubectl delete
      secret <secret_name> -n gpc-system
      

   4. En este punto, se iniciará el proceso de eliminación (que se puede confirmar comprobando si el secreto está marcado para su eliminación). El secreto puede tardar casi una hora en eliminarse y volver a generarse.

Rotar los certificados de administrador de almacenamiento y de SVM

Estos certificados son los certificados de servidor instalados en el sistema ONTAP por GDC.

Hay un certificado para el administrador de almacenamiento, también conocido como cuenta de administrador del clúster. Su nombre tiene como prefijo el nombre de host del sistema ONTAP y un hash único al final. Se instala en el vserver de administrador del clúster. GDC usa este certificado internamente para tareas administrativas.

También hay varios certificados de servidor definidos para los SVMs de ONTAP. De esta forma, se establece la autenticidad de los clientes que se comunican con las SVMs.

Todos los certificados se pueden rotar con el mismo proceso. Debido a un error de coincidencia del certificado de CA raíz en el clúster root-admin, en el caso de los certificados de clúster y SVM, que se indican en las siguientes tablas, la rotación requiere rotar todos los certificados de la lista correspondiente. Esto significa que, si es necesario rotar algún certificado de clúster, también se deben rotar todos los demás certificados del clúster. Lo mismo ocurre con los certificados SVM. Esta limitación se solucionará cuando se implemente la gestión automática de certificados.

Requisitos previos

• Acceso de administrador al clúster de ONTAP o a las SVMs pertinentes
• Acceso de kubectl a los clústeres de Kubernetes adecuados
• Vuelve a instalar los certificados de CA de cliente que se indican en los pasos de instalación de los certificados de CA de cliente.

Asignación entre certificados y secretos de Kubernetes

Por cada certificado instalado en ONTAP, hay un secreto de Kubernetes correspondiente en el servidor de la API de gestión que contiene los detalles del certificado. GDC genera los certificados y el proceso para sustituir un certificado es sencillo: elimina el secreto que corresponda a un certificado determinado y el certificado se volverá a generar inmediatamente. A continuación, ese nuevo certificado se puede instalar en ONTAP manualmente para sustituir al antiguo.

Usa kubectl get secrets -n <namespace> -s <secret> -o yaml para inspeccionar el certificado en Kubernetes y verificar que coincide con los detalles de ONTAP que se ven en security certificate show -vserver <svm_name>. El espacio de nombres siempre será "gpc-system" y puedes consultar la tabla anterior para ver el nombre del secreto.

También puedes ver la asignación de certificado a secreto comprobando lo siguiente:

kubectl get certificates -n <namespace>

Certificados de clúster relevantes

Nombre común de ONTAP	Vserver	Nombre del certificado de K8s	Nombre del secreto de Kubernetes	Descripción
N/A	<hostname>	<hostname>-admin-cert	<hostname>-admin-cert-secret	Certificado de administrador de clústeres
N/A	<hostname>	<hostname>-server-cert	<hostname>-server-cert-secret	Certificado de servidor firmado por el emisor de GDC usado como certificado de servidor de ONTAP
N/A	<hostname>	<hostname>-read-only-cert	<hostname>-read-only-cert-secret	Acceso de monitorización de solo lectura

Certificados SVM relevantes

Vserver	Nombre del certificado de K8s	Nombre del secreto de Kubernetes	Descripción
administrador raíz	root-admin-server-cert	root-admin-server-cert-secret	Certificado de servidor firmado por el emisor de GDC usado como certificado de servidor SVM
administrador raíz	root-admin-s3-server-cert	root-admin-s3-server-cert-secret	Certificado de servidor firmado por el emisor de GDC usado como certificado de servidor S3 de ONTAP
administrador raíz	root-admin-client-cert	root-admin-client-cert-secret	Acceso de administrador de SVM
administrador raíz	root-admin-s3-identity-client-cert	root-admin-s3-identity-client-cert-secret	Acceso de identidad de S3

Validación

Certificado de Vserver

Una vez que se hayan rotado todos los certificados, comprueba que el backend de Trident siga conectado correctamente en todos los clústeres asociados al certificado del servidor que se haya rotado.

1. Ejecuta lo siguiente:

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl get tridentbackendconfigs -n netapp-trident
   

   La salida debería tener este aspecto:

   NAME                                   BACKEND NAME   BACKEND UUID                           PHASE   STATUS
   netapp-trident-backend-tbc-ontap-san   iscsi-san      a46ce1c7-26da-42c9-b475-e5e37a0911f8   Bound   Success
   

2. Verifica que el PHASE sea Bound y que el Status sea Success.

Certificado de administrador raíz

Para probar el certificado de administrador, podemos crear un StorageVirtualMachine de prueba y comprobar que GDC puede conciliarlo correctamente. Para ello, sigue estos pasos:

1. Lista las StorageVirtualMachines que ya tengas y elige una para clonarla como prueba.
2. Extrae la especificación de Kubernetes.
3. Edita la definición para cambiar el nombre y eliminar los campos innecesarios.
4. Aplica la definición de la prueba.
5. Espera a que el estado de StorageVirtualMachine sea Ready.
6. Elimina el StorageVirtualMachine de prueba.
7. Elimina el SVM real de ONTAP.

Ejemplo

En este ejemplo se usa un espacio de nombres de GDC NetApp gpc-system y se clona el organization-root-user temporalmente en un nuevo SVM llamado test-svm.

1. Lista de SVMs:

   kubectl get storagevirtualmachines -n ngpc-system
   

   Resultado:

   NAME                      AGE
   organization-root-admin   13d
   

2. Extrae la especificación:

   kubectl get storagevirtualmachines -n gpc-system -o yaml > svm.yaml
   

3. Edita la especificación para que sea similar a la siguiente:

   apiVersion: system.gpc.gke.io/v1alpha1
   kind: StorageVirtualMachine
   metadata:
     labels:
       ontap.storage.gpc.gke.io/role: user
     name: test-svm
     namespace: netapp-alatl12-gpcstge02
   spec:
     aggregates:
     - alatl12-gpcstge02-c1-aggr1
     - alatl12-gpcstge02-c2-aggr1
     clusterName: alatl12-gpcstge02
     iscsiTarget:
       port: a0a-4
       subnetName: root-svm-data
     nasServer:
       port: a0a-4
       subnetName: root-svm-data
     svmNetwork:
       port: e0M
       subnetName: Default
   

4. Aplícalo al clúster:

   kubectl create -f svm.yaml
   

5. Espera a que el nuevo SVM esté listo. Observa periódicamente el resultado de lo siguiente:

   kubectl get storagevirtualmachines -n gpc-system test-svm
   

   El éxito se indica de la siguiente manera:

     Conditions:
       Last Transition Time:  2022-03-30T21:30:27Z
       Message:
       Observed Generation:   1
       Reason:                SVMCreated
       Status:                True
       Type:                  Ready
   

   o AnsibleJobSucceed.

6. Elimina el recurso de SVM:

   kubectl delete storagevirtualmachines -n gpc-system test-svm
   

7. Eliminarlo por completo de ONTAP. Si elimina el recurso, no se quitará de ONTAP.

   Inicia sesión en la consola de NetApp y elimina el SVM:

   alatl12-gpcstge02::> vserver delete test-svm
   

   Resultado:

   Warning: When Vserver "test-svm" is deleted,
           the following objects are automatically removed as well:
           LIFs: 7
           Routes: 2
           Admin-created login accounts: 2
           Do you want to continue? {y|n}: y
   [Job 3633] Success
   

Sigue estas instrucciones para rotar manualmente el certificado de ONTAP si detectas algún error durante la validación.

Instrucciones

Si el nombre del certificado de ONTAP anterior no es aplicable, no es necesario rotar nada en ONTAP. Inspecciona el certificado y el secreto en Kubernetes y elimina el secreto.

1. Genera un nuevo certificado. Consulta la tabla anterior para ver el nombre del secreto:

   kubectl get certificates -n <namespace>
   

   $ kubectl patch Certificates <cert_name> -n gpc-system \
    --type=merge -p "{\"spec\":{\"privateKey\": {\"rotationPolicy\": \"Always\"}}}"
   $ kubectl delete secret -n <namespace> <secret_name>
   

2. Para ver los certificados instalados en un vserver determinado (los que no están marcados como no aplicables):

   cluster::> security certificate show -vserver <svm_name> -type server
   

3. Inspecciona el secreto correspondiente en Kubernetes (consulta la tabla anterior):

   kubectl get certificates -n <namespace>
   

4. Cuando estés conforme con la coincidencia, genera un nuevo certificado eliminando el secreto:

   kubectl delete secret -n <namespace> <secret_name>
   

5. Vuelve a inspeccionar el secreto para ver que se ha regenerado un nuevo certificado. Una vez que se haya confirmado, crea un certificado de servidor en ONTAP. Solo sigue estos pasos para los certificados anteriores con el sufijo "server-cert".

6. Extrae el cuerpo del nuevo certificado TLS con kubectl y otras herramientas directamente e instálalo en ONTAP:

   $ gdch_cert_details -n <namespace> -s <secret_name>
   
   cluster::> security certificate install -vserver <svm_name> -type server
   

   La primera petición será la siguiente:

   Please enter Certificate: Press <Enter> when done

   En él, debes introducir tls.crt. Si hay varios bloques de certificados en tls.crt, introduce el primero y deja los demás como certificados intermedios para consultarlos en el siguiente paso.

7. El sistema te pedirá que Please enter Private Key: Press <Enter> when done. Pega el contenido del archivo tls.key y pulsa Intro.

   A continuación, se te pedirá lo siguiente: Do you want to continue entering root and/or intermediate certificates {y|n}: Si tu archivo tls.crt contiene solo un certificado, escribe N y pulsa Intro. De lo contrario, escribe Y y pulsa Intro.

   Si has escrito Y: se te pedirá que introduzcas los certificados intermedios. Pégalas una a una desde tu archivo tls.crt y pulsa Intro después de cada una. Por último, pega el certificado raíz del archivo ca.crt y pulsa Intro.

   Si has escrito N: (no tienes que hacer nada más con respecto a los certificados en esta petición)

   A continuación, ONTAP devolverá un número de serie. Anota este número, ya que representa el número de serie del nuevo certificado y de la AC. En los pasos siguientes, se hará referencia a este número de serie como <new\_server\_serial> y <new\_ca>. No sigas estos pasos si vas a configurar un certificado de servidor S3.

8. Consulta el estado actual de las configuraciones SSL del servidor virtual y del clúster. Ten a mano la AC emisora del certificado del servidor, el nombre común del certificado del servidor y el número de serie del certificado del servidor,<old\_server\_common\_name>, <old\_ca> y <old\_server\_serial> respectivamente:

   cluster::> security ssl show -vserver <vserver>
   

   De esta forma, se devuelve la información de SSL, con la información del certificado del servidor antiguo. Puedes hacer referencia a ella más adelante para asegurarte de que se ha actualizado después de modificar la configuración de SSL.

9. Modifica la configuración de SSL:

   cluster::> security ssl modify -server-enabled -client-enabled true -vserver <svm_name> -serial <new_server_serial> -ca <new_ca>
   

10. Consulta el nuevo estado de las configuraciones SSL del servidor virtual y del clúster. Debería tener el número de serie actualizado del certificado del servidor ahora instalado:

    cluster::> security ssl show -vserver <vserver>
    

11. Elimina el certificado de servidor antiguo después de verificar el paso anterior:

    cluster::> security certificate delete -vserver <svm_name> -common-name <old_server_common_name> -ca <old_ca> -type server -serial <old_server_serial>
    

Certificados de AC de cliente

1. Obtén todos los certificados de AC del trust-store-internal-only ConfigMap en el espacio de nombres gpc-system con el siguiente comando:

   kubectl get cm -n gpc-system trust-store-internal-only -o jsonpath='{.data.ca\.crt}'
   

2. Por cada certificado de CA obtenido en el paso anterior, ejecuta el siguiente comando en tu clúster de ONTAP:

   cluster::> security certificate install -vserver <svm_name> -type client-ca
   

   Se te pedirá lo siguiente: Please enter Certificate: Press <Enter> when done. Pega cada bloque de certificado obtenido en el paso 1 y pulsa Intro. Repite este comando de instalación para cada certificado de CA.

Rotar certificados de Harvest

La generación de certificados de cosecha depende de <hostname>-read-only-cert-secret. Asegúrate de que <hostname>-read-only-cert-secret esté girado antes de continuar.

1. Consulta los certificados instalados del pod de Harvest:

   export KUBECONFIG= #path to root-admin kubeconfig
   

   cluster_name="$(kubectl get storagecluster -A -o jsonpath='{.items[0].metadata.name}')"
   secret_name="$cluster_name"-read-only-cert-secret
   

   export TLS_CRT="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.tls\.crt}')"
   

   export TLS_KEY="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.tls\.key}')"
   

   export CA_CRT="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.ca\.crt}')"
   

2. Aplica un parche al secreto de las credenciales de Harvest para proporcionar los certificados actualizados:

   $ kubectl patch secret \
   -n gpc-system netapp-harvest-configuration-credential \
   -p "{\"data\":{\"tls.crt\":\"${TLS_CRT:?}\",\"tls.key\":\"${TLS_KEY:?}\",\"ca.crt\":\"${CA_CRT:?}\"}}"
   

3. Reinicia el servicio Harvest para cargar la configuración actualizada:

   kubectl delete pod -n gpc-system -l 'app=harvest.netapp.io'
   

Rotar certificados del sistema de archivos

Ejecuta el siguiente comando para volver a generar el certificado file-storage-webhooks-serving-cert y el file-observability-backend-target-cert:

kubectl delete secret file-storage-webhooks-serving-cert -n file-system
kubectl delete secret file-observability-backend-target-cert -n file-system

Reinicia los pods para cargar la configuración actualizada:

kubectl delete pod -n file-system -l 'app=file-observability-backend-controller'
kubectl delete pod file-storage-backend-controller -n file-system

Rotar certificados de Trident y ONTAP

Trident debe comunicarse con ONTAP. Se configura con el backend de Trident, que usa el certificado de cliente <svm\_name>-client-cert-secret> definido anteriormente. La rotación de certificados de cliente no forma parte de Trident, pero Trident depende de partes de este certificado, que deben actualizarse.

Instrucciones

Para actualizar el certificado de CA:

1. Exporta KUBECONFIG para que apunte al archivo kubeconfig del clúster específico de los componentes de Trident en cuestión. Cada clúster tendrá Trident configurado.

2. Obtén el certificado de CA, codificado en base64, del secreto client-cert y almacénalo como una variable:

   ca_cert=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.ca\.crt}')
   

3. Aplica un parche al objeto tridentBackendConfig:

   kubectl patch tridentBackendConfigs netapp-trident-backend-tbc-ontap-san -n netapp-trident --type=merge -p "{\"spec\":{\"trustedCACertificate\":\"$ca_cert\"}}"
   

Para el certificado y la clave del cliente:

1. Obtén el certificado TLS, codificado en base64, del secreto client-cert y almacénalo como una variable:

   tls_cert=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.tls\.crt}')
   

2. Obtén la clave TLS, codificada dos veces en base64 a partir del secreto de client-cert, y guárdala como una variable:

   tls_key=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.tls\.key}' | base64 -w 0)
   

3. Actualiza el secreto de backend con la clave privada:

   kubectl patch secrets netapp-trident-backend-tbc-ontap -n netapp-trident --type=merge -p "{\"data\":{\"clientPrivateKey\": \"$tls_key\"}}"
   

4. Aplica un parche a la configuración del backend con el certificado TLS:

   kubectl patch tridentBackendConfigs netapp-trident-backend-tbc-ontap-san -n netapp-trident --type=merge -p "{\"spec\":{\"clientCertificate\":\"$tls_cert\"}}"
   

Rotar los certificados del controlador de Trident

Los contenedores de Trident deben comunicarse con el operador de Trident. Esta comunicación se realiza a través de HTTPS y los certificados de servidor y cliente deben gestionarse como parte de este proceso.

Validación

Confirma que tanto el daemonset como la implementación (si procede) se inician correctamente.

Sigue estas instrucciones para rotar manualmente los certificados del servidor y del cliente si detectas algún error durante la validación.

Instrucciones

Tanto el certificado del servidor como el del cliente no tienen el certificado correspondiente en ONTAP. Estos datos se incluyen estrictamente en los clústeres.

1. Elimina el secreto correspondiente al certificado que va a caducar.

   kubectl delete secret -n netapp-trident <secret_name>
   

2. Reinicia el daemonset netapp-trident-csi:

   kubectl rollout restart daemonset netapp-trident-csi -n netapp-trident
   

3. Para las rotaciones de certificados de servidor, también tendrás que reiniciar la implementación de netapp-trident-csi:

   kubectl rollout restart deployments netapp-trident-csi -n netapp-trident
   

Certificado de AC de Trident

El certificado de CA se usa para proporcionar la autoridad de certificación para firmar los certificados del servidor y del cliente de Trident.

Nombre del certificado	Espacio de nombres	Secreto	Descripción
netapp-trident-csi-cert	netapp-trident	netapp-trident-csi-cert	Certificado de AC de Trident

Validación

Verás que el secreto se ha vuelto a generar. Para que los certificados de cliente y de servidor surtan efecto, también puedes seguir las instrucciones anteriores para rotar los certificados del controlador Trident después de rotar este certificado.

Sigue estas instrucciones para rotar manualmente el certificado de CA si detectas algún error durante la validación.

Instrucciones

Para rotar esta clave, solo tienes que eliminar el secreto de Kubernetes:

kubectl delete secret -n netapp-trident <secret_name>

Nodos CSI de Trident y SVMs (datos)

Se trata de un conjunto de credenciales CHAP de iSCSI de todo el SVM para habilitar el acceso al plano de datos para el acceso a bloques. Esto no se aplica a los protocolos de archivos.

Servidor de la API Management

Espacio de nombres	Secreto	Descripción
gpc-system	<organization>-<type>-svm-credential	Se necesita la configuración de SVM para la configuración de Trident

Servidor de API de gestión y administrador de la organización

Espacio de nombres	Secreto	Descripción
gpc-system	<organization>-<type>-svm-credential	Se necesita la configuración de SVM para la configuración de Trident
netapp-trident	netapp-trident-backend-tbc-ontap	Secreto necesario para gestionar el backend de Trident

Validación

1. Verifica que el backend siga configurado correctamente:

   #export kubeconfig of org cluster
   export KUBECONFIG= #path to root-admin kubeconfig
   
   kubectl get tridentBackendConfigs -n netapp-trident
   

2. Verifica que el estado del backend sea Success.

Sigue las instrucciones que se indican a continuación para rotar manualmente los secretos si detectas algún error durante la validación.

Instrucciones

Genera una nueva cadena aleatoria de 16 caracteres sin caracteres especiales para el secreto del iniciador y el secreto del iniciador de destino:

#export kubeconfig of Management API server
export KUBECONFIG= #path to root-admin kubeconfig

initiator_secret=$(head /dev/random | tr -dc A-Za-z0-9 | head -c16 | base64)

target_secret=$(head /dev/random | tr -dc A-Za-z0-9 | head -c16 | base64)

kubectl patch secrets -n gpc-system "$org-$type-svm-credential" --type=merge -p "{\"data\":{\"initiatorSecret\": \"$initiator_secret\", \"targetSecret\": \"$target_secret\"}}"

#export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

kubectl patch secrets -n netapp-trident netapp-trident-backend-tbc-ontap --type=merge -p "{\"data\":{\"chapInitiatorSecret\": \"$initiator_secret\", \"chapTargetInitiatorSecret\": \"$target_secret\"}}"

Clave AES de Trident

Trident usa la clave AES internamente para cifrar las credenciales CHAP de iSCSI para su uso interno. Es una secuencia aleatoria de caracteres que debe tener una longitud de 32 bytes.

Clústeres que ejecutan Trident (podrían ser clústeres raíz, de administrador de organización, de usuario o de sistema)

Espacio de nombres	Secreto	Descripción
netapp-trident	netapp-trident-aes-key	Clave AES que necesita Trident para cifrar las credenciales CHAP de iSCSI

Validación

1. Comprueba que el backend sigue configurado correctamente:

   #export kubeconfig of org cluster
   export KUBECONFIG= #path to root-admin kubeconfig
   
   kubectl get tridentBackendConfigs -n netapp-trident
   

2. Verifica que el estado del backend sea Success.

3. Intenta crear un volumen de prueba:

   1. Crea un archivo YAML con la información de la PVC:

      echo "
      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: block-pvc
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 5Gi
        storageClassName: standard-rwo" > pvc.yaml
      

   2. Aplícalo al clúster de Kubernetes:

      kubectl apply -f pvc.yaml
      

4. Comprueba que no haya errores en los registros de CSI debido al cifrado iSCSI:

   kubectl logs deploy/netapp-trident-csi -n netapp-trident -c trident-main | grep "Error encrypting"
   

   Si no hay errores, no se devolverá ningún registro.

5. Limpiar el archivo y el PVC:

   kubectl delete -f pvc.yaml
   rm -f pvc.yaml
   

Sigue estas instrucciones para rotar la clave manualmente si detectas algún error durante la validación.

Instrucciones

Antes de rotar esta clave, asegúrate de que no haya pods pendientes con PVs en el clúster. Si hay alguna, espera a que se aprovisionen por completo antes de rotar la clave.

Genera una nueva cadena aleatoria de 32 caracteres sin caracteres especiales para aesKey:

#export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

aes_key=$(head /dev/random | tr -dc A-Za-z0-9 | head -c32 | base64)

#save old key just in case of errors
old_key=$(kubectl get secrets -n netapp-trident "netapp-trident-aes-key" -o jsonpath='{.data.aesKey}')

kubectl patch secrets -n netapp-trident "netapp-trident-aes-key" --type=merge -p "{\"data\":{\"aesKey\": \"$aes_key\"}}"

kubectl rollout restart deployment netapp-trident-csi -n netapp-trident

Restauración

1. Restaurar las últimas credenciales usadas si hay errores:

   kubectl patch secrets -n netapp-trident "netapp-trident-aes-key" --type=merge -p "{\"data\":{\"aesKey\": \"$old_key\"}}"
   
   kubectl rollout restart deployment netapp-trident-csi -n netapp-trident
   

2. Vuelve a realizar los pasos de verificación.