Rota las claves y los certificados de autenticación de almacenamiento

El dispositivo aislado 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 para rotar las claves y los certificados de autenticación que se deben realizar para lo siguiente:

• rotación de claves programada con regularidad para garantizar que el dispositivo sea seguro y cumpla con los requisitos
• exposición de la llave Debes rotar la clave expuesta lo antes posible.

Antes de comenzar

Asegúrate de tener el siguiente acceso:

• Acceso a la Consola del administrador del clúster de ONTAP
• Kubeconfig para el servidor de la API de administración

Rota las credenciales de IPsec (PSK)

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

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

• Tráfico externo entre hosts de metal desnudo y SVM.
• Tráfico interno entre nodos trabajadores

Los analizaremos por separado.

Requisitos previos

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

Impacto

Mientras se rotan las políticas de IPsec, los hosts experimentarán una pérdida de conectividad IP con el sistema de almacenamiento. Las conexiones se detendrán o, posiblemente, fallarán según el comportamiento de la aplicación. Si es posible, puedes pausar las cargas de trabajo del usuario durante la rotación, pero no es obligatorio. Las conexiones deberían restablecerse poco después de que se restablezcan los secretos.

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

Para validar la rotación, usa el siguiente comando y compara tu 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 ejecutaste la secuencia de comandos anteriormente.

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

1. Ejecuta el siguiente comando:

   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, haz lo siguiente:

   echo $password
   

3. Accede a la consola de ONTAP:

   ssh $username@$mgmt_ip
   

   Cuando se te solicite la contraseña, pega la que copiaste 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
   

   Para cada host que desees 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 encriptación del almacenamiento. Para las conexiones de clúster de administrador, ya sea root-admin o organization-admin, debes usar el clúster de root-admin.

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

   Si ambos elementos están presentes, puedes continuar con el siguiente paso. Si no es así, detente y no continúes con la modificación de IPsec. Comunícate con el equipo de asistencia técnica.

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

   Ahora usa el servidor de la API de Management para borrar el objeto 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 tu 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 verdadero para todos los hosts.

1. Borra todos los CR del paso 2 en el orden indicado.

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

   • Borra los tres trabajos de política del 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

   • Borra los tres objetos 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). Repite el paso 2 hasta que todos los CR estén en estado READY o Complete.

Rotar las teclas de volumen

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

Antes de comenzar

Completa los siguientes pasos:

1. Verifica que cumplas con los requisitos de la laptop.
2. Asegúrate de poder acceder a la consola del clúster de OTS a través de BM01 o BM02.

Inicia la rotación de claves de volumen

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

volume encryption rekey start -vserver SVM_name -volume volume_name

El siguiente comando cambia la clave de encriptación de vol1 en 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

Verifica la rotación de claves de volumen

Después de iniciar la rotación de claves, verifica el estado de la nueva clave:

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 complete la operación de cambio de clave, verifica que el volumen esté habilitado para la encriptación:

volume show -is-encrypted true

Muestra los volúmenes encriptados 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%

Rota los certificados de HSM externos

En esta sección, se describe cómo rotar y actualizar los certificados del HSM externo para ONTAP.

Requisitos previos

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

Instrucciones

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

   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 del HSM en Kubernetes:

   1. Copia el archivo YAML secreto anterior: 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 del HSM, incluido el certificado de la CA 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. Accede a la CLI de ONTAP.

   2. Instala el nuevo certificado de la 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 administrador 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 administrador de claves:

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

   Verifica si los servidores de claves siguen en estado Available.

Rota la credencial de administrador de almacenamiento

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

Requisitos previos

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

Instrucciones

1. Comienza con el siguiente comando y, luego, sigue las indicaciones resultantes:

   cluster::> security login password
   

2. Actualiza el secreto para que coincida con lo siguiente:

   • Opción 1 (interactiva):

     kubectl edit secret -n <netapp_namespace> netapp_credential
     

     Usa el editor para cambiar la contraseña al 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 -
     

Rota las credenciales de acceso de emergencia de ONTAP

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

Durante la configuración, se crean dos tipos de secretos: nivel 1 y 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. Si bien el software controla la eliminación de los secretos normales y de copia de seguridad de forma simultánea, recomendamos rotar solo uno de estos secretos de socios a la vez como una capa adicional de seguridad.

Si bien los secretos de nivel 1 se rotan automáticamente después de un período de 90 días, los secretos de nivel 2 no lo hacen. Cualquiera de los dos tipos de secretos se debe rotar manualmente con el siguiente proceso si se usa.

Requisitos previos

• Acceso requerido: Servidor de la API de Management

Validación

1. La rotación de secretos se puede validar verificando si el secreto aún está marcado para su eliminación. Si no es así, significa que se rotó el secreto. Sigue el paso uno de las siguientes instrucciones para verificarlo.

2. Si el secreto es de nivel 2, cópialo en un medio físico y guárdalo en la caja fuerte. Luego, el secreto se debe marcar como persistente con 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 encuentras algún error durante la validación.

Instrucciones

1. Verifica si un secreto está marcado para su eliminación:

   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. Verifica si existen las credenciales del socio y si no están marcadas para su eliminación. No continúes y vuelve a estos pasos en el futuro si se marca para su eliminación.

   2. Si se rota el secreto de nivel 2, el secreto del socio debe marcarse como persistente agregando la anotación disk.gdc.goog/persisted:

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

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

      kubectl delete
      secret <secret_name> -n gpc-system
      

   4. En este punto, comenzará el proceso de eliminación (y se puede confirmar si el secreto está marcado para su eliminación). Puede tardar casi una hora en borrarse y regenerarse.

Rota los certificados del administrador de almacenamiento y de la SVM

Estos son los certificados de servidor que GDC instala en el sistema ONTAP.

Hay un certificado para el administrador de almacenamiento, también conocido como la 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 servidor virtual de administrador del clúster. GDC usa este certificado de forma interna para tareas administrativas.

También hay varios certificados del servidor definidos para las SVM de ONTAP. Estos establecen la autenticidad para los clientes que se comunican con las SVM.

Todos los certificados se pueden rotar con el mismo proceso. Debido a una discrepancia en el certificado de la CA raíz en el clúster de administrador raíz, para los certificados de clúster y SVM, que se enumeran en las siguientes tablas, la rotación requiere rotar todos los certificados dentro de la lista respectiva. Esto significa que, si se debe rotar algún certificado del clúster, también se deben rotar todos los demás. Lo mismo se aplica a los certificados de SVM. Esta limitación se solucionará cuando se implemente la administración automática de certificados.

Requisitos previos

• Acceso de administrador al clúster de ONTAP o a las SVM pertinentes
• Acceso de kubectl a los clústeres de Kubernetes correspondientes
• Reinstala los certificados de client-ca que se describen en los pasos para instalar los certificados de client-ca.

Asignación entre certificados y secretos de Kubernetes

Para cada certificado instalado en ONTAP, hay un secreto de Kubernetes correspondiente en el servidor de la API de Management que contiene los detalles del certificado. GDC genera los certificados, y el proceso para reemplazar un certificado es simple: borra el secreto que corresponde a un certificado determinado, y el certificado se volverá a generar de inmediato. Luego, ese certificado nuevo se puede instalar en ONTAP de forma manual para reemplazar el anterior.

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

También puedes ver la asignación del certificado al secreto de la siguiente manera:

kubectl get certificates -n <namespace>

Certificados de clúster relevantes

Nombre común de ONTAP	Vserver	Nombre del certificado de K8S	Nombre del Secret de Kubernetes	Descripción
N/A	<hostname>	<hostname>-admin-cert	<hostname>-admin-cert-secret	Certificado de administrador del clúster
N/A	<hostname>	<hostname>-server-cert	<hostname>-server-cert-secret	Certificado del servidor firmado por la entidad emisora de GDC que se usa como certificado del servidor de ONTAP
N/A	<hostname>	<hostname>-read-only-cert	<hostname>-read-only-cert-secret	Acceso de supervisión de solo lectura

Certificados de SVM pertinentes

Vserver	Nombre del certificado de K8S	Nombre del Secret de Kubernetes	Descripción
root-admin	root-admin-server-cert	root-admin-server-cert-secret	Certificado del servidor firmado por la entidad emisora de GDC que se usa como certificado del servidor de SVM
root-admin	root-admin-s3-server-cert	root-admin-s3-server-cert-secret	Certificado del servidor firmado por la entidad emisora de GDC que se usa como certificado del servidor de ONTAP S3
root-admin	root-admin-client-cert	root-admin-client-cert-secret	Acceso de administrador de SVM
root-admin	root-admin-s3-identity-client-cert	root-admin-s3-identity-client-cert-secret	Acceso de identidad a S3

Validación

Certificado de Vserver

Después de rotar todos los certificados, verifica que el backend de Trident siga conectado correctamente para cada clúster asociado con el certificado del servidor rotado.

1. Ejecuta lo siguiente:

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl get tridentbackendconfigs -n netapp-trident
   

   El resultado debería verse así:

   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 PHASE sea Bound y que Status sea Success.

Certificado de administrador raíz

Para probar el certificado de administrador, podemos crear una nueva StorageVirtualMachine de prueba y ver que GDC puede conciliarla de forma adecuada. Los pasos para hacerlo son los siguientes:

1. Enumera las StorageVirtualMachines existentes y elige una para clonar como prueba.
2. Extrae la especificación de Kubernetes para él.
3. Edita la definición para cambiar el nombre y borrar los campos innecesarios.
4. Aplica la definición de la prueba.
5. Espera a que el estado de StorageVirtualMachine sea Ready.
6. Borra el StorageVirtualMachine de prueba.
7. Borra la SVM real de ONTAP.

Ejemplo

En este ejemplo, se usa un espacio de nombres de NetApp de GDC gpc-system y se clona organization-root-user de forma temporal en una nueva SVM llamada test-svm.

1. Enumera las SVM:

   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 se vea 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 la nueva SVM esté lista. Observa periódicamente el resultado de los siguientes comandos:

   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. Borra el recurso de SVM:

   kubectl delete storagevirtualmachines -n gpc-system test-svm
   

7. Borra el archivo por completo de ONTAP. Borrar el recurso no lo quita de ONTAP.

   Accede a la consola de NetApp y borra la 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 las instrucciones que se indican a continuación para rotar manualmente el certificado de ONTAP si encuentras 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 borra el secreto.

1. Genera un certificado nuevo y haz referencia a la tabla anterior para 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 servidor virtual determinado, en el caso de los certificados instalados en ONTAP (no marcados como no aplicables), haz lo siguiente:

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

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

   kubectl get certificates -n <namespace>
   

4. Cuando esté conforme con la coincidencia, borra el secreto para generar un certificado nuevo:

   kubectl delete secret -n <namespace> <secret_name>
   

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

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

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

   La primera instrucción será la siguiente:

   Please enter Certificate: Press <Enter> when done

   En el que debes ingresar tls.crt En caso de que haya varios bloques de certificados en tls.crt, ingresa el primer bloque y conserva los bloques de certificados restantes como certificados intermedios para referencia en el siguiente paso.

7. El sistema mostrará el mensaje: Please enter Private Key: Press <Enter> when done. Pega el contenido de tu archivo tls.key y presiona Intro.

   A continuación, aparecerá el siguiente mensaje: 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 presiona Intro. De lo contrario, escribe Y y presiona Intro.

   Si escribiste Y: Se te pedirá que ingreses certificados intermedios. Pégalos uno por uno desde tu archivo tls.crt y presiona Intro después de cada uno. Por último, pega el certificado raíz de tu archivo ca.crt y presiona Intro.

   Si escribiste N: (no es necesario realizar ninguna otra acción con respecto a los certificados en esta solicitud)

   Luego, ONTAP devolverá un número de serie. Registra este número, ya que representa el número de serie del nuevo certificado y la CA. En los pasos posteriores, se hará referencia a este número de serie como <new\_server\_serial> y <new\_ca>. No sigas estos pasos relacionados con el certificado si estás configurando un certificado de servidor de S3.

8. Consulta el estado actual de las configuraciones de SSL para el servidor virtual y el clúster. Ten a mano la CA emisora del certificado del servidor, el nombre común del certificado del servidor y el número de serie del certificado del servidor, ya que se hará referencia a ellos como <old\_server\_common\_name>, <old\_ca> y <old\_server\_serial>, respectivamente:

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

   Esto devuelve la información de SSL, con la información del certificado del servidor anterior. Puedes consultar esto más adelante para asegurarte de que se haya 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 la configuración de SSL para el servidor virtual y el clúster. Debería tener el número de serie actualizado del certificado del servidor ahora instalado:

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

11. Borra el certificado del servidor anterior 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 CA de cliente

1. Recupera todos los certificados de CA del ConfigMap trust-store-internal-only 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. Para cada certificado de CA recuperado 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á que hagas lo siguiente: Please enter Certificate: Press <Enter> when done. Pega cada bloque de certificado recuperado en el paso 1 y presiona Intro. Repite este comando de instalación para cada certificado de CA.

Rota los 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. Visualiza los certificados instalados para el 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 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 de Harvest para cargar la configuración actualizada:

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

Rota los certificados del sistema de archivos

Ejecuta el siguiente comando para volver a generar el certificado de file-storage-webhooks-serving-cert y 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

Rota los certificados de Trident y ONTAP

Trident debe comunicarse con ONTAP. Esto 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 la CA:

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

2. Toma el certificado de CA, codificado en Base64 desde el 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 reales, haz lo siguiente:

1. Toma 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. Toma la clave de TLS, codificada dos veces en base64 desde el secreto de certificado del cliente, y almacénala 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\"}}"
   

Rota 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 del servidor y del cliente deben administrarse como parte de este proceso.

Validación

Confirma que el DaemonSet y la implementación (cuando corresponda) se ejecuten correctamente.

Sigue las instrucciones que se indican a continuación para rotar manualmente los certificados del servidor y del cliente si encuentras algún error durante la validación.

Instrucciones

Ni el servidor ni los certificados de cliente tienen un certificado correspondiente en el lado de ONTAP. Estos datos se encuentran estrictamente contenidos en los clústeres.

1. Borra el secreto correspondiente al certificado que vencerá.

   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 deberás reiniciar la implementación de netapp-trident-csi:

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

Certificado de CA de Trident

El certificado de CA se usa para proporcionar la autoridad certificadora 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 CA de Trident

Validación

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

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

Instrucciones

Para rotar esta clave, solo debes borrar el secreto de Kubernetes:

kubectl delete secret -n netapp-trident <secret_name>

Nodos de CSI y SVM de Trident (datos)

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

Servidor de la API de Management

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

Servidor de la API de administració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 instalación de Trident
netapp-trident	netapp-trident-backend-tbc-ontap	Secreto necesario para administrar el backend de Trident

Validación

1. Verifica que el backend aún esté 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 estas instrucciones para rotar los secretos de forma manual si encuentras 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 internamente la clave AES para encriptar las credenciales de CHAP de iSCSI para su uso interno. Es una secuencia aleatoria de caracteres que debe tener 32 bytes de longitud.

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

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

Validación

1. Verifica que el backend aún esté 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 del 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. Verifica que no haya errores en los registros de CSI debido a la encriptación de iSCSI:

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

   Si no hubo errores, no verás ningún registro.

5. Limpia el archivo y el PVC:

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

Sigue estas instrucciones para rotar la clave de forma manual si encuentras algún error durante la validación.

Instrucciones

Antes de rotar esta clave, asegúrate de que no haya pods pendientes con PV 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

Revertir

1. Si hay errores, revierte a las credenciales que se usaron por última vez:

   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.