Effectuer une rotation des clés et des certificats d'authentification du stockage

L'appliance Google Distributed Cloud (GDC) isolée adopte ONTAP Select (OTS) comme fournisseur de stockage défini par logiciel. OTS dispose de son propre système d'authentification, dans lequel chaque identité (service principal ou client) est associée à un nom et à une clé.

Ce document décrit les étapes à suivre pour effectuer la rotation des clés et des certificats d'authentification pour :

• une rotation des clés planifiée régulièrement pour s'assurer que l'appareil est conforme et sécurisé.
• l'exposition de la clé. Vous devez effectuer une rotation de la clé exposée dès que possible.

Avant de commencer

Assurez-vous de disposer des accès suivants :

• Accès à la console d'administration du cluster ONTAP
• Kubeconfig pour le serveur de l'API Management

Effectuer une rotation des identifiants IPsec (PSK)

ONTAP est compatible avec l'authentification basée sur les certificats pour IPsec à partir de la version 9.10.1. Cette version de GDC est la 9.14.1 et utilise des clés prépartagées.

Pour Appliance, IPsec est implémenté pour deux types de trafic OTS :

• Trafic externe entre les hôtes bare metal et les SVM.
• Trafic interne entre les nœuds de calcul.

Nous les examinerons séparément.

Prérequis

• Accès à la console d'administration du cluster ONTAP
• Une nouvelle clé prépartagée
• Kubeconfig pour le serveur de l'API Management
• Accès aux hôtes pour mettre à jour la configuration StrongSwan

Impact

Pendant la rotation des règles IPsec, les hôtes perdent la connectivité IP au système de stockage. Les connexions seront bloquées ou échoueront peut-être, selon le comportement de l'application. Si possible, vous pouvez suspendre les charges de travail des utilisateurs pendant la rotation, mais ce n'est pas obligatoire. Les connexions devraient être rétablies peu de temps après la réinitialisation des secrets.

Rotation des clés pour le trafic externe OTS

Pour valider la rotation, utilisez la commande suivante et comparez votre résultat :

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get StorageEncryptionConnections -n gpc-system

Sortie :

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

Vérifiez que le champ READY est défini sur "true" pour l'hôte spécifique sur lequel vous avez exécuté le script précédemment.

Faites manuellement la rotation de la clé PSK si vous détectez une erreur lors de la validation.

1. Exécutez la commande suivante :

   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. Affichez le mot de passe et copiez-le dans le presse-papiers :

   echo $password
   

3. Connectez-vous à la console ONTAP :

   ssh $username@$mgmt_ip
   

   Lorsque vous êtes invité à saisir un mot de passe, collez celui que vous avez copié à l'étape précédente.

4. Utilisez le script suivant pour la rotation des identifiants :

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl get StorageEncryptionConnections -n gpc-system
   

   Sortie :

   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
   

   Pour chaque hôte que vous souhaitez faire pivoter, vous pouvez exécuter la commande suivante :

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

   Vérifiez maintenant que tous les composants de la connexion de chiffrement du stockage sont visibles. Pour les connexions au cluster d'administrateur (administrateur racine ou administrateur de l'organisation), vous devez utiliser le cluster d'administrateur racine.

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

   Si ces deux éléments sont présents, vous pouvez passer à l'étape suivante. Si ce n'est pas le cas, arrêtez-vous et ne modifiez pas ipsec. Contactez l'assistance technique.

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

   Utilisez maintenant le serveur de l'API Management pour supprimer 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\"}]"
   

   Rotation des clés pour le trafic interne OTS

De même, pour valider la rotation, utilisez la commande suivante et comparez votre résultat :

export KUBECONFIG= #path to root-admin kubeconfig

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

Sortie :

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

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

Sortie :

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

Vérifiez que tous les jobs sont à l'état Complete.

kubectl get StorageEncryptionConnections -n gpc-system

Sortie :

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

Vérifiez que le champ READY est défini sur "true" pour tous les hôtes.

1. Supprimez tous les CR de l'étape 2 dans l'ordre indiqué.

   • Supprimez le secret pour le trafic interne. sh kubectl delete secret ots-internal-pre-shared-key -n gpc-system

   • Supprimez les trois tâches de règles d'OS. 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

   • Supprimez les trois 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. Patientez quelques minutes (environ trois à cinq minutes). Répétez l'étape 2 jusqu'à ce que chaque demande de modification soit à l'état "PRÊTE" ou "Terminée".

Tourner les boutons de volume

Cette section décrit les étapes manuelles à suivre pour alterner les identifiants de volume OTS.

Avant de commencer

Procédez comme suit :

1. Vérifiez que vous remplissez les conditions préalables concernant les ordinateurs portables.
2. Assurez-vous de pouvoir vous connecter à la console du cluster OTS via BM01 ou BM02.

Lancer la rotation des clés de volume

Dans la console OTS, déclenchez la rotation ponctuelle des clés :

volume encryption rekey start -vserver SVM_name -volume volume_name

La commande suivante modifie la clé de chiffrement pour vol1 sur SVMvs1 :

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

Pour afficher les noms des serveurs virtuels et des volumes, vous pouvez utiliser la commande show :

vserver show
volume show

Vérifier la rotation des clés de volume

Une fois la rotation des clés lancée, vérifiez l'état du re-cléage :

volume encryption rekey show

Affichez l'état de l'opération de re-clé :

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.

Une fois l'opération de nouvelle clé terminée, vérifiez que le volume est activé pour le chiffrement :

volume show -is-encrypted true

Affichez les volumes chiffrés sur cluster1 :

cluster1::> volume show -is-encrypted true

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

Effectuer une rotation des certificats HSM externes

Cette section explique comment faire tourner et mettre à jour les certificats HSM externes pour ONTAP.

Prérequis

• Accès administrateur au cluster ONTAP ou aux SVM concernées
• Mot de passe actuel
• Accès kubectl aux clusters appropriés

Instructions

1. Sauvegardez les anciens certificats HSM :

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

2. Mettez à jour le secret des certificats HSM dans Kubernetes :

   1. Copiez l'ancien fichier YAML secret : sh cp external-hsm-creds-old.yaml external-hsm-creds-new.yaml

   2. Mettez à jour le nouveau fichier external-hsm-creds-new.yaml avec les nouveaux identifiants HSM, y compris le certificat CA du serveur, le certificat client public et la clé privée du client.

   3. Appliquez la modification et mettez à jour l'objet secret HSM.

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

3. Mettez à jour les certificats HSM dans ONTAP :

   1. Connectez-vous à l'interface de ligne de commande ONTAP.

   2. Installez le nouveau certificat CA du serveur :

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

   3. Installez le nouveau certificat client :

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

   4. Mettez à jour la configuration du gestionnaire de clés pour utiliser les certificats nouvellement installés :

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

Validation

1. Vérifiez la modification avec l'état du gestionnaire de clés :

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

   Vérifiez si les serveurs de clés sont toujours à l'état Available.

Alterner les identifiants d'administrateur du stockage

Cette section explique comment faire tourner et définir le nom d'utilisateur et le mot de passe de l'administrateur du stockage.

Prérequis

• Accès administrateur au cluster ONTAP ou aux SVM concernées
• Mot de passe actuel
• Accès kubectl aux clusters appropriés

Instructions

1. Commencez par la commande suivante, puis suivez les invites qui s'affichent :

   cluster::> security login password
   

2. Mettez à jour le secret pour qu'il corresponde :

   • Option 1 (interactive) :

     kubectl edit secret -n <netapp_namespace> netapp_credential
     

     Utilisez l'éditeur pour remplacer le mot de passe par la nouvelle valeur encodée en base64.

   • Option 2 (corriger avec la dépendance jq) :

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

Effectuer une rotation des identifiants d'accès d'urgence ONTAP

Lors de la configuration du stockage de fichiers et par blocs, quatre comptes utilisateur avec accès d'urgence sont créés. Ils peuvent être utilisés pour accéder directement à ONTAP. Ces identifiants peuvent être obtenus en tant que secrets sur le serveur de l'API Management. Une fois ces identifiants utilisés, ils doivent être alternés.

Deux types de secrets sont créés lors de la configuration : le secret de niveau 1 et le secret de niveau 2. Le niveau 1 est storage-root-level1 and storage-root-level1-backup. Le niveau 2 est storage-root-level2 and storage-root-level2-backup. Les secrets de niveau 2 doivent être stockés dans le coffre-fort. Chaque niveau comporte deux secrets : un secret normal et un secret de sauvegarde. Bien que le logiciel gère la suppression simultanée des codes secrets normaux et de sauvegarde, nous vous recommandons de n'en faire tourner qu'un seul à la fois pour renforcer la sécurité.

Les secrets de niveau 1 sont alternés automatiquement au bout de 90 jours, contrairement à ceux de niveau 2. Si l'un ou l'autre type de secret est utilisé, il doit être permuté manuellement à l'aide de la procédure suivante.

Prérequis

• Accès requis : serveur de l'API Management

Validation

1. Vous pouvez valider la rotation des secrets en vérifiant si le secret est toujours marqué pour suppression. Si ce n'est pas le cas, cela signifie que le secret a été permuté. Suivez la première étape des instructions ci-dessous pour vérifier.

2. Si le secret est de niveau 2, copiez-le sur un support physique et stockez-le dans le coffre-fort. Le secret doit ensuite être marqué comme persistant à l'aide de l'annotation "disk.gdc.goog/persisted".

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

Suivez les instructions ci-dessous pour faire pivoter manuellement le secret si vous rencontrez une erreur lors de la validation.

Instructions

1. Pour vérifier si un secret est marqué pour suppression :

   1. Exécutez la commande suivante :

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

   2. Si le champ deletionTimestamp est présent dans la réponse, comme dans cet exemple, le secret est marqué pour suppression. Sinon, ce n'est pas le cas.

      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. Faites pivoter le secret après l'avoir utilisé pour accéder à ONTAP :

   1. Vérifiez si les identifiants du partenaire existent et ne sont pas marqués pour suppression. Ne passez pas à l'étape suivante et revenez à ces étapes ultérieurement si elle est marquée comme devant être supprimée.

   2. Si le secret de niveau 2 est en cours de rotation, le secret du partenaire doit être marqué comme persistant en ajoutant l'annotation disk.gdc.goog/persisted :

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

   3. Supprimez le secret du cluster à l'aide de la commande suivante :

      kubectl delete
      secret <secret_name> -n gpc-system
      

   4. À ce stade, le processus de suppression commence (vous pouvez vérifier si le secret est marqué comme devant être supprimé). La suppression et la régénération du secret peuvent prendre près d'une heure.

Effectuer une rotation des certificats d'administrateur du stockage et de SVM

Ces certificats sont les certificats serveur installés dans le système ONTAP par GDC.

Il existe un certificat pour l'administrateur du stockage, également appelé compte administrateur du cluster. Son nom est précédé du nom d'hôte du système ONTAP et comporte un hachage unique à la fin. Il est installé dans le serveur virtuel d'administration du cluster. GDC utilise ce certificat en interne pour les tâches administratives.

Plusieurs certificats côté serveur sont également définis pour les SVM ONTAP. Elles permettent d'établir l'authenticité des clients qui communiquent avec les SVM.

Tous les certificats peuvent être renouvelés à l'aide de la même procédure. En raison d'une incompatibilité de certificat CA racine dans le cluster root-admin, pour les certificats de cluster et de SVM listés dans les tableaux suivants, la rotation nécessite de faire tourner tous les certificats de la liste correspondante. Cela signifie que si un certificat de cluster doit être renouvelé, tous les autres certificats de cluster doivent également l'être. Il en va de même pour les certificats SVM. Cette limitation sera résolue une fois la gestion automatisée des certificats implémentée.

Prérequis

• Accès administrateur au cluster ONTAP ou aux SVM concernées
• Accès kubectl aux clusters Kubernetes appropriés
• réinstallez les certificats client-ca décrits dans la procédure d'installation des certificats client-ca.

Mappage entre les certificats et les secrets Kubernetes

Pour chaque certificat installé dans ONTAP, il existe un secret Kubernetes correspondant dans le serveur de l'API Management qui contient les détails du certificat. GDC génère les certificats, et le processus de remplacement d'un certificat est simple : supprimez le secret qui correspond à un certificat donné, et le certificat sera immédiatement régénéré. Ce nouveau certificat peut ensuite être installé manuellement dans ONTAP, en remplacement de l'ancien.

Utilisez kubectl get secrets -n <namespace> -s <secret> -o yaml pour inspecter le certificat dans Kubernetes et vérifier qu'il correspond aux détails dans ONTAP vus depuis security certificate show -vserver <svm_name>. L'espace de noms sera toujours "gpc-system". Vous pouvez consulter le tableau ci-dessus pour connaître le nom du secret.

Vous pouvez également consulter le mappage du certificat à la clé secrète en vérifiant les éléments suivants :

kubectl get certificates -n <namespace>

Certificats de cluster pertinents

Nom commun ONTAP	Vserver	Nom du certificat K8S	Nom du secret Kubernetes	Description
ND	<hostname>	<hostname>-admin-cert	<hostname>-admin-cert-secret	Certificat d'administrateur de cluster
ND	<hostname>	<hostname>-server-cert	<hostname>-server-cert-secret	Certificat de serveur signé par l'émetteur GDC utilisé comme certificat de serveur ONTAP
ND	<hostname>	<hostname>-read-only-cert	<hostname>-read-only-cert-secret	Accès à la surveillance en lecture seule

Certificats SVM pertinents

Vserver	Nom du certificat K8S	Nom du secret Kubernetes	Description
root-admin	root-admin-server-cert	root-admin-server-cert-secret	Certificat de serveur signé par l'émetteur GDC utilisé comme certificat de serveur SVM
root-admin	root-admin-s3-server-cert	root-admin-s3-server-cert-secret	Certificat de serveur signé par l'émetteur GDC utilisé comme certificat de serveur ONTAP S3
root-admin	root-admin-client-cert	root-admin-client-cert-secret	Accès administrateur SVM
root-admin	root-admin-s3-identity-client-cert	root-admin-s3-identity-client-cert-secret	Accès à l'identité S3

Validation

Certificat Vserver

Une fois tous les certificats renouvelés, vérifiez que le backend Trident est toujours connecté pour chaque cluster associé au certificat de serveur renouvelé.

1. Exécutez la commande suivante :

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl get tridentbackendconfigs -n netapp-trident
   

   Le résultat doit se présenter comme suit :

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

2. Vérifiez que la valeur de PHASE est Bound et que la valeur de Status est Success.

Certificat d'administrateur racine

Pour tester le certificat d'administrateur, nous pouvons créer une StorageVirtualMachine de test et vérifier que GDC est en mesure de la réconcilier correctement. Voici comment procéder :

1. Listez les StorageVirtualMachines existantes et choisissez-en une à cloner pour le test.
2. Extrayez la spécification Kubernetes.
3. Modifiez la définition pour changer le nom et supprimer les champs inutiles.
4. Appliquez la définition du test.
5. Attendez que l'état de StorageVirtualMachine devienne Ready.
6. Supprimez le StorageVirtualMachine de test.
7. Supprimez la SVM réelle d'ONTAP.

Exemple

Cet exemple utilise un espace de noms GDC NetApp gpc-system et clone organization-root-user temporairement dans un nouveau SVM appelé test-svm.

1. Lister les SVM :

   kubectl get storagevirtualmachines -n ngpc-system
   

   Sortie :

   NAME                      AGE
   organization-root-admin   13d
   

2. Extrayez la spécification :

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

3. Modifiez la spécification pour qu'elle ressemble à ce qui suit :

   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. Appliquez-le au cluster :

   kubectl create -f svm.yaml
   

5. Attendez que la nouvelle SVM soit prête. Observez régulièrement le résultat de :

   kubectl get storagevirtualmachines -n gpc-system test-svm
   

   La réussite est indiquée par :

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

   ou AnsibleJobSucceed.

6. Supprimez la ressource SVM :

   kubectl delete storagevirtualmachines -n gpc-system test-svm
   

7. Supprimez-le complètement d'ONTAP. La suppression de la ressource ne l'élimine pas d'ONTAP.

   Connectez-vous à la console NetApp et supprimez la SVM :

   alatl12-gpcstge02::> vserver delete test-svm
   

   Sortie :

   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
   

Suivez les instructions ci-dessous pour faire manuellement pivoter le certificat ONTAP si vous rencontrez une erreur lors de la validation.

Instructions

Si le nom de certificat ONTAP précédent ne s'applique pas, rien ne doit être permuté dans ONTAP. Inspectez le certificat et le secret dans Kubernetes, puis supprimez le secret.

1. Générez un certificat en faisant référence au tableau précédent pour le nom du secret :

   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. Affichez les certificats installés pour un serveur virtuel donné, pour les certificats installés dans ONTAP (non marqués comme non applicables) :

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

3. Inspectez le secret correspondant dans Kubernetes (reportez-vous au tableau précédent) :

   kubectl get certificates -n <namespace>
   

4. Lorsque vous êtes satisfait de la correspondance, générez un nouveau certificat en supprimant le secret :

   kubectl delete secret -n <namespace> <secret_name>
   

5. Réinspectez le secret pour vérifier qu'un nouveau certificat a été régénéré. Une fois cette opération confirmée, créez un certificat de serveur dans ONTAP. Ne suivez les étapes ci-dessous que pour les certificats précédents portant le suffixe "server-cert".

6. Extrayez le corps du nouveau certificat TLS à l'aide de kubectl et d'autres outils directement, puis installez-le dans ONTAP :

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

   La première requête sera la suivante :

   Please enter Certificate: Press <Enter> when done

   Vous devez saisir tls.crt. S'il existe plusieurs blocs de certificats dans tls.crt, saisissez le premier bloc et conservez les blocs de certificats restants en tant que certificats intermédiaires pour référence à l'étape suivante.

7. Le système vous invite à saisir Please enter Private Key: Press <Enter> when done. Collez le contenu de votre fichier tls.key et appuyez sur Entrée.

   L'invite suivante s'affiche : Do you want to continue entering root and/or intermediate certificates {y|n}: Si votre fichier tls.crt ne contient qu'un seul certificat, saisissez N et appuyez sur Entrée. Sinon, saisissez Y et appuyez sur Entrée.

   Si vous avez saisi Y : vous serez invité à saisir les certificats intermédiaires. Collez-les un par un à partir de votre fichier tls.crt, en appuyant sur Entrée après chaque saisie. Enfin, collez le certificat racine de votre fichier ca.crt et appuyez sur Entrée.

   Si vous avez saisi N : (aucune autre action n'est requise concernant les certificats à cette invite)

   ONTAP renverra alors un numéro de série. Notez ce numéro, car il représente le numéro de série du nouveau certificat et de la nouvelle AC. Ce numéro de série sera appelé <new\_server\_serial> et <new\_ca> dans les étapes suivantes. Ne suivez pas ces étapes concernant les certificats si vous configurez un certificat de serveur S3.

8. Affichez l'état actuel des configurations SSL pour le serveur virtuel et le cluster. Gardez à portée de main l'autorité de certification émettrice du certificat de serveur, le nom commun du certificat de serveur et le numéro de série du certificat de serveur, car ils seront respectivement désignés par <old\_server\_common\_name>, <old\_ca> et <old\_server\_serial> :

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

   Cette commande renvoie les informations SSL, y compris celles de l'ancien certificat de serveur. Vous pourrez vous y référer ultérieurement pour vous assurer qu'elles ont été mises à jour après avoir modifié la configuration SSL.

9. Modifiez la configuration SSL :

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

10. Affichez le nouvel état des configurations SSL pour le serveur virtuel et le cluster. Il devrait contenir le numéro de série mis à jour du certificat de serveur désormais installé :

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

11. Supprimez l'ancien certificat de serveur après avoir vérifié l'étape précédente :

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

Certificats client-CA

1. Récupérez tous les certificats d'autorité de certification à partir du ConfigMap trust-store-internal-only dans l'espace de noms gpc-system à l'aide de la commande suivante :

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

2. Pour chaque certificat d'autorité de certification récupéré à l'étape précédente, exécutez la commande suivante sur votre cluster ONTAP :

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

   L'invite suivante s'affiche : Please enter Certificate: Press <Enter> when done. Collez chaque bloc de certificat récupéré à l'étape 1, puis appuyez sur Entrée. Répétez cette commande d'installation pour chaque certificat d'autorité de certification.

Effectuer une rotation des certificats Harvest

La génération de certificats de récolte dépend de <hostname>-read-only-cert-secret. Assurez-vous que <hostname>-read-only-cert-secret a été permuté avant de continuer.

1. Affichez les certificats installés pour le pod 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. Corrigez le secret des identifiants Harvest pour fournir les certificats mis à jour :

   $ 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. Redémarrez le service Harvest pour charger la configuration mise à jour :

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

Effectuer une rotation des certificats du système de fichiers

Exécutez la commande suivante pour régénérer le certificat file-storage-webhooks-serving-cert et 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

Redémarrez les pods pour charger la configuration mise à jour :

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

Effectuer une rotation des certificats Trident et ONTAP

Trident doit communiquer avec ONTAP. Il est configuré avec le backend Trident qui utilise le certificat client <svm\_name>-client-cert-secret> défini précédemment. La rotation des certificats client ne fait pas partie de Trident, mais Trident s'appuie sur des éléments de ce certificat, qui doivent être mis à jour.

Instructions

Pour la mise à jour du certificat d'autorité de certification :

1. Exportez KUBECONFIG pour qu'il pointe vers le fichier kubeconfig du cluster spécifique aux composants Trident en question. Trident sera configuré sur chaque cluster.

2. Récupérez le certificat d'autorité de certification encodé en base64 à partir du secret client-cert et stockez-le en tant que variable :

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

3. Appliquez le correctif à l'objet tridentBackendConfig :

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

Pour le certificat et la clé client réels :

1. Récupérez le certificat TLS encodé en base64 à partir du secret client-cert et stockez-le en tant que variable :

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

2. Récupérez la clé TLS, doublement encodée en base64 à partir du secret client-cert, et stockez-la en tant que variable :

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

3. Mettez à jour le secret de backend avec la clé privée :

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

4. Corrigez la configuration du backend avec le certificat TLS :

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

Effectuer une rotation des certificats du contrôleur Trident

Les conteneurs Trident doivent communiquer avec l'opérateur Trident. Cette communication s'effectue via HTTPS, et les certificats de serveur et de client doivent être gérés dans le cadre de cette communication.

Validation

Vérifiez que le DaemonSet et le déploiement (le cas échéant) sont dans un état sain.

Suivez les instructions ci-dessous pour faire manuellement pivoter les certificats de serveur et de client si vous détectez une erreur lors de la validation.

Instructions

Les certificats de serveur et de client n'ont pas de certificat correspondant côté ONTAP. Ils sont strictement contenus dans les clusters.

1. Supprimez le secret correspondant au certificat qui expire.

   kubectl delete secret -n netapp-trident <secret_name>
   

2. Redémarrez le DaemonSet netapp-trident-csi :

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

3. Pour les rotations de certificats de serveur, vous devrez également redémarrer le déploiement netapp-trident-csi :

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

Certificat CA Trident

Le certificat CA est utilisé pour fournir l'autorité de certification pour la signature des certificats du serveur et du client Trident.

Nom du certificat	Namespace	Secret	Description
netapp-trident-csi-cert	netapp-trident	netapp-trident-csi-cert	Certificat d'autorité de certification Trident

Validation

Vous pouvez voir que le code secret est régénéré. Pour que les certificats client et serveur prennent effet, vous pouvez également suivre les instructions précédentes pour faire tourner les certificats du contrôleur Trident après avoir fait tourner ce certificat.

Suivez les instructions ci-dessous pour faire manuellement pivoter le certificat de l'autorité de certification si vous rencontrez une erreur lors de la validation.

Instructions

Pour faire pivoter cette clé, il vous suffit de supprimer le secret de Kubernetes :

kubectl delete secret -n netapp-trident <secret_name>

Nœuds CSI et SVM Trident (données)

Il s'agit d'un ensemble d'identifiants CHAP iSCSI à l'échelle du SVM pour permettre l'accès au plan de données pour l'accès aux blocs. Cela ne s'applique pas aux protocoles de fichier.

Serveur de l'API Management

Namespace	Secret	Description
gpc-system	<organization>-<type>-svm-credential	Configuration SVM requise pour la configuration de Trident

Administrateur de l'organisation et serveur de l'API Management

Namespace	Secret	Description
gpc-system	<organization>-<type>-svm-credential	Configuration SVM requise pour la configuration de Trident
netapp-trident	netapp-trident-backend-tbc-ontap	Secret nécessaire pour gérer le backend Trident

Validation

1. Vérifiez que le backend est toujours configuré correctement :

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

2. Vérifiez que l'état du backend est Success.

Suivez les instructions ci-dessous pour faire pivoter manuellement les secrets si vous rencontrez une erreur lors de la validation.

Instructions

Générez une nouvelle chaîne aléatoire de 16 caractères sans caractères spéciaux pour le secret de l'initiateur et le secret de l'initiateur cible :

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

Clé AES Trident

La clé AES est utilisée en interne par Trident pour chiffrer les identifiants CHAP iSCSI pour son usage interne. Il s'agit d'une séquence aléatoire de caractères qui doit comporter 32 octets.

Cluster exécutant Trident (peut être un cluster racine, d'administrateur d'organisation, d'utilisateur ou système)

Namespace	Secret	Description
netapp-trident	netapp-trident-aes-key	Clé AES requise par Trident pour chiffrer les identifiants CHAP iSCSI

Validation

1. Vérifiez que le backend est toujours configuré correctement :

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

2. Vérifiez que l'état du backend est Success.

3. Essayez de créer un volume de test :

   1. Créez un fichier YAML contenant les informations du PVC :

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

   2. Appliquez-le au cluster Kubernetes :

      kubectl apply -f pvc.yaml
      

4. Vérifiez qu'il n'y a pas d'erreurs dans les journaux CSI en raison du chiffrement iSCSI :

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

   Si aucune erreur ne s'est produite, aucun journal ne s'affiche.

5. Nettoyez le fichier et le PVC :

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

Suivez les instructions ci-dessous pour effectuer manuellement la rotation de la clé si vous détectez une erreur lors de la validation.

Instructions

Avant de remplacer cette clé, assurez-vous qu'aucun pod n'est en attente avec des volumes persistants dans le cluster. Si c'est le cas, attendez qu'ils soient entièrement provisionnés avant de faire pivoter la clé.

Générez une nouvelle chaîne aléatoire de 32 caractères sans caractères spéciaux pour 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

Rollback

1. Effectuez un rollback vers les identifiants utilisés en dernier en cas d'erreurs :

   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. Recommencez les étapes de validation.