Ruotare le chiavi di autenticazione e i certificati di archiviazione

L'appliance con air gap di Google Distributed Cloud (GDC) adotta ONTAP Select (OTS) come fornitore di storage software-defined. OTS ha un proprio sistema di autenticazione in cui ogni identità (servizio principale o client) ha un nome e una chiave associati.

Questo documento descrive i passaggi per la rotazione delle chiavi e dei certificati di autenticazione che devono essere eseguiti per:

• rotazione della chiave pianificata regolarmente per garantire che il dispositivo sia conforme e sicuro.
• esposizione della chiave. Devi ruotare la chiave esposta il prima possibile.

Prima di iniziare

Assicurati di disporre dei seguenti accessi:

• Accesso alla Console di amministrazione al cluster ONTAP
• Kubeconfig per il server API di gestione

Ruota le credenziali IPsec (PSK)

ONTAP supporta l'autenticazione basata su certificati per IPsec a partire dalla versione 9.10.1. Questa versione di GDC è la 9.14.1 e utilizza chiavi precondivise.

Per Appliance, IPsec viene implementato per due tipi di traffico OTS:

• Traffico esterno tra host bare metal e SVM.
• Traffico interno tra i nodi worker.

Li esamineremo separatamente.

Prerequisiti

• Accesso alla Console di amministrazione al cluster ONTAP
• Una nuova chiave precondivisa
• Kubeconfig per il server API di gestione
• Accesso agli host per aggiornare la configurazione di StrongSwan

Impatto

Durante la rotazione delle policy IPsec, gli host perderanno la connettività IP al sistema di archiviazione. Le connessioni si bloccheranno o potrebbero non riuscire a seconda del comportamento dell'applicazione. Se possibile, puoi mettere in pausa i carichi di lavoro degli utenti durante la rotazione, ma non è obbligatorio. Le connessioni dovrebbero essere ripristinate poco dopo il reset dei secret.

Rotazione delle chiavi per il traffico esterno OTS

Per convalidare la rotazione, utilizza il seguente comando e confronta l'output:

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get StorageEncryptionConnections -n gpc-system

Output:

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 che il campo READY sia true per l'host specifico per cui hai eseguito lo script in precedenza.

Ruota manualmente la PSK se trovi errori durante la convalida.

1. Esegui questo 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. Visualizza la password e copiala negli appunti:

   echo $password
   

3. Accedi alla console ONTAP:

   ssh $username@$mgmt_ip
   

   Quando ti viene richiesta la password, incolla quella copiata dal passaggio precedente.

4. Utilizza il seguente script per la rotazione delle credenziali:

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl get StorageEncryptionConnections -n gpc-system
   

   Output:

   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
   

   Per ogni host che vuoi ruotare, puoi eseguire le seguenti operazioni:

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

   Ora conferma di visualizzare tutti i componenti della connessione di crittografia dell'archiviazione. Per le connessioni al cluster di amministrazione, root-admin o organization-admin, devi utilizzare il cluster root-admin.

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

   Se sono presenti entrambi gli elementi, puoi procedere al passaggio successivo. In caso contrario, interrompi e non procedere con la modifica di IPsec. Contatta l'assistenza tecnica.

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

   Ora utilizza il server dell'API Management per eliminare 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\"}]"
   

   Rotazione delle chiavi per il traffico interno OTS

Analogamente, per convalidare la rotazione, utilizza il seguente comando e confronta l'output:

export KUBECONFIG= #path to root-admin kubeconfig

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

Output:

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

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

Output:

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 che tutti i job siano nello stato Complete.

kubectl get StorageEncryptionConnections -n gpc-system

Output:

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 che il campo READY sia impostato su true per tutti gli host.

1. Elimina tutte le CR nel passaggio 2 con l'ordine elencato

   • Elimina il secret per il traffico interno sh kubectl delete secret ots-internal-pre-shared-key -n gpc-system

   • Elimina tutti e tre i job della policy del sistema operativo 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

   • Elimina tutte e tre le connessioni 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. Attendi qualche minuto (circa 3-5 minuti). Ripeti il passaggio 2 finché ogni CR non è in stato PRONTO o Completato.

Ruota i tasti del volume

Questa sezione descrive i passaggi manuali per la rotazione delle credenziali del volume OTS.

Prima di iniziare

Completa i seguenti passaggi:

1. Verifica di soddisfare i prerequisiti per il laptop.
2. Assicurati di poter accedere alla console del cluster OTS tramite BM01 o BM02.

Avviare rotazione della chiave del volume

Nella console OTS, attiva la rotazione una tantum delle chiavi:

volume encryption rekey start -vserver SVM_name -volume volume_name

Il seguente comando modifica la chiave di crittografia per vol1 il giorno SVMvs1:

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

Per visualizzare i nomi dei vserver e dei volumi, puoi utilizzare il comando show:

vserver show
volume show

Verificare la rotazione della chiave del volume

Una volta avviata la rotazione delle chiavi, controlla lo stato della nuova chiave:

volume encryption rekey show

Visualizza lo stato dell'operazione di riassegnazione della chiave:

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.

Una volta completata l'operazione di riassegnazione della chiave, verifica che il volume sia abilitato per la crittografia:

volume show -is-encrypted true

Visualizza i volumi criptati su cluster1:

cluster1::> volume show -is-encrypted true

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

Ruota i certificati HSM esterni

Questa sezione descrive come ruotare e aggiornare i certificati HSM esterni per ONTAP.

Prerequisiti

• Accesso amministrativo al cluster ONTAP o alle SVM pertinenti
• Password corrente
• Accesso kubectl ai cluster appropriati

Istruzioni

1. Esegui il backup dei vecchi certificati HSM:

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

2. Aggiorna il secret dei certificati HSM in Kubernetes:

   1. Copia il vecchio file YAML dei secret: sh cp external-hsm-creds-old.yaml external-hsm-creds-new.yaml

   2. Aggiorna il nuovo file external-hsm-creds-new.yaml con le nuove credenziali HSM, inclusi il certificato CA del server, il certificato client pubblico e la chiave privata per il client.

   3. Applica la modifica e aggiorna l'oggetto secret HSM.

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

3. Aggiorna i certificati HSM in ONTAP:

   1. Accedi alla CLI ONTAP.

   2. Installa il nuovo certificato CA del server:

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

   3. Installa il nuovo certificato client:

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

   4. Aggiorna la configurazione di Key Manager in modo che utilizzi i certificati appena installati:

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

Convalida

1. Verifica la modifica con lo stato di Key Manager:

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

   Controlla se i server delle chiavi sono ancora nello stato Available.

Ruota le credenziali di amministratore dello spazio di archiviazione

Questa sezione descrive come ruotare e impostare l'utente e la password dell'amministratore dello spazio di archiviazione.

Prerequisiti

• Accesso amministrativo al cluster ONTAP o alle SVM pertinenti
• Password corrente
• Accesso kubectl ai cluster appropriati

Istruzioni

1. Inizia con il seguente comando e segui le istruzioni risultanti:

   cluster::> security login password
   

2. Aggiorna il secret in modo che corrisponda a:

   • Opzione 1 (interattiva):

     kubectl edit secret -n <netapp_namespace> netapp_credential
     

     Utilizza l'editor per modificare la password con il nuovo valore codificato in base64.

   • Opzione 2 (patch con dipendenza jq):

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

Ruota le credenziali di accesso di emergenza ONTAP

Durante la configurazione dell'archiviazione di file e blocchi, vengono creati quattro account utente di accesso di emergenza che possono essere utilizzati per accedere direttamente a ONTAP. Queste credenziali possono essere ottenute come secret nel server dell'API Management. Una volta utilizzate, queste credenziali devono essere ruotate.

Durante la configurazione vengono creati due tipi di secret: livello 1 e livello 2. Il livello 1 è storage-root-level1 and storage-root-level1-backup. Il livello 2 è storage-root-level2 and storage-root-level2-backup. I secret di livello 2 devono essere memorizzati nella cassaforte e ogni livello ha due secret, normale e di backup. Sebbene il software gestisca l'eliminazione simultanea dei secret normali e di backup, ti consigliamo di ruotare solo uno di questi secret partner alla volta come livello di sicurezza aggiuntivo.

Mentre i secret di livello 1 vengono ruotati automaticamente dopo un periodo di 90 giorni, quelli di livello 2 no. Se viene utilizzato, entrambi i tipi di secret devono essere ruotati manualmente seguendo la procedura riportata di seguito.

Prerequisiti

• Accesso richiesto: server API Management

Convalida

1. La rotazione dei secret può essere convalidata controllando se il secret è ancora contrassegnato per l'eliminazione. In caso contrario, il secret è stato ruotato. Per verificare, segui il passaggio 1 delle istruzioni riportate di seguito.

2. Se il segreto è di livello 2, copialo su un supporto fisico e conservalo nella cassaforte. Il segreto deve quindi essere contrassegnato come persistente utilizzando l'annotazione "disk.gdc.goog/persisted".

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

Segui queste istruzioni per ruotare manualmente il secret se riscontri errori durante la convalida.

Istruzioni

1. Controlla se un secret è contrassegnato per l'eliminazione:

   1. Esegui questo comando:

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

   2. Se il campo deletionTimestamp è presente nella risposta come in questo esempio, il segreto è contrassegnato per l'eliminazione. In caso contrario, non lo è.

      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. Ruota il secret dopo averlo utilizzato per accedere a ONTAP:

   1. Verifica se le credenziali del partner esistono e non sono contrassegnate per l'eliminazione. Non procedere e torna a questi passaggi in futuro se è contrassegnato per l'eliminazione.

   2. Se il segreto di livello 2 viene ruotato, il segreto del partner deve essere contrassegnato come persistente aggiungendo l'annotazione disk.gdc.goog/persisted:

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

   3. Elimina il secret dal cluster utilizzando il seguente comando:

      kubectl delete
      secret <secret_name> -n gpc-system
      

   4. A questo punto, viene avviato il processo di eliminazione (che può essere confermato controllando se il secret è contrassegnato per l'eliminazione). L'eliminazione e la rigenerazione del secret possono richiedere quasi un'ora.

Ruota i certificati di amministratore dello spazio di archiviazione e SVM

Questi certificati sono i certificati server installati nel sistema ONTAP da GDC.

Esiste un certificato per l'amministratore dell'archiviazione, noto anche come account amministratore del cluster. Il suo nome ha come prefisso il nome host del sistema ONTAP e un hash univoco finale. Viene installato nel vserver di amministrazione del cluster. GDC utilizza questo certificato internamente per le attività amministrative.

Sono definiti anche diversi certificati lato server per le SVM ONTAP. Questi stabiliscono l'autenticità per i client che comunicano con le SVM.

Tutti i certificati possono essere ruotati utilizzando la stessa procedura. A causa di una mancata corrispondenza del certificato root-ca nel cluster root-admin, per i certificati del cluster e della SVM, elencati nelle tabelle seguenti, la rotazione richiede la rotazione di tutti i certificati all'interno dell'elenco corrispondente. Ciò significa che se è necessario ruotare un certificato del cluster, devono essere ruotati anche tutti gli altri certificati del cluster. Lo stesso vale per i certificati SVM. Questa limitazione verrà risolta una volta implementata la gestione automatica dei certificati.

Prerequisiti

• Accesso amministrativo al cluster ONTAP o alle SVM pertinenti
• Accesso kubectl ai cluster Kubernetes appropriati
• reinstalla i certificati client-ca descritti nei passaggi di installazione dei certificati client-ca.

Mapping tra certificati e secret Kubernetes

Per ogni certificato installato in ONTAP, esiste un secret Kubernetes corrispondente nel server API di gestione che contiene i dettagli del certificato. GDC genera i certificati e la procedura per sostituirne uno è semplice: elimina il secret corrispondente a un determinato certificato e il certificato verrà rigenerato immediatamente. Il nuovo certificato può quindi essere installato manualmente in ONTAP, sostituendo quello precedente.

Utilizza kubectl get secrets -n <namespace> -s <secret> -o yaml per ispezionare il certificato in Kubernetes e verificare che corrisponda ai dettagli in ONTAP visualizzati da security certificate show -vserver <svm_name>. Lo spazio dei nomi sarà sempre "gpc-system" e puoi fare riferimento alla tabella precedente per il nome del secret.

Puoi anche visualizzare la mappatura del certificato al secret controllando:

kubectl get certificates -n <namespace>

Certificati cluster pertinenti

Nome comune ONTAP	Vserver	Nome certificato K8S	Nome secret Kubernetes	Descrizione
N/D	<hostname>	<hostname>-admin-cert	<hostname>-admin-cert-secret	Certificato di amministratore del cluster
N/D	<hostname>	<hostname>-server-cert	<hostname>-server-cert-secret	Certificato del server firmato dall'emittente GDC utilizzato come certificato del server ONTAP
N/D	<hostname>	<hostname>-read-only-cert	<hostname>-read-only-cert-secret	Accesso di monitoraggio di sola lettura

Certificati SVM pertinenti

Vserver	Nome certificato K8S	Nome secret Kubernetes	Descrizione
root-admin	root-admin-server-cert	root-admin-server-cert-secret	Certificato del server firmato dall'emittente GDC utilizzato come certificato del server SVM
root-admin	root-admin-s3-server-cert	root-admin-s3-server-cert-secret	Certificato del server firmato dall'emittente GDC utilizzato come certificato del server ONTAP S3
root-admin	root-admin-client-cert	root-admin-client-cert-secret	Accesso amministratore SVM
root-admin	root-admin-s3-identity-client-cert	root-admin-s3-identity-client-cert-secret	Accesso all'identità S3

Convalida

Certificato Vserver

Dopo la rotazione di tutti i certificati, verifica che il backend di Trident sia ancora connesso correttamente per ogni cluster associato al certificato del server ruotato.

1. Esegui questo comando:

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl get tridentbackendconfigs -n netapp-trident
   

   L'output dovrebbe essere simile al seguente:

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

2. Verifica che PHASE sia Bound e che Status sia Success.

Certificato amministratore radice

Per testare il certificato amministratore, possiamo creare una nuova StorageVirtualMachine di test e verificare che GDC sia in grado di riconciliarla in modo appropriato. I passaggi da seguire sono i seguenti:

1. Elenca le StorageVirtualMachine esistenti e scegli quella da clonare come test.
2. Estrai le specifiche Kubernetes.
3. Modifica la definizione per cambiare il nome ed eliminare i campi non necessari.
4. Applica la definizione del test.
5. Attendi che lo stato di StorageVirtualMachine diventi Ready.
6. Elimina StorageVirtualMachine di test.
7. Elimina l'SVM effettiva da ONTAP.

Esempio

Questo esempio utilizza uno spazio dei nomi GDC NetApp gpc-system e clona temporaneamente organization-root-user in una nuova SVM chiamata test-svm.

1. Elenca SVM:

   kubectl get storagevirtualmachines -n ngpc-system
   

   Output:

   NAME                      AGE
   organization-root-admin   13d
   

2. Estrai la specifica:

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

3. Modifica la specifica in modo che sia simile alla seguente:

   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. Applica il file al cluster:

   kubectl create -f svm.yaml
   

5. Attendi che la nuova SVM sia pronta. Osserva periodicamente l'output di:

   kubectl get storagevirtualmachines -n gpc-system test-svm
   

   Il successo è indicato da:

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

   o AnsibleJobSucceed.

6. Elimina la risorsa SVM:

   kubectl delete storagevirtualmachines -n gpc-system test-svm
   

7. Eliminalo completamente da ONTAP. L'eliminazione della risorsa non la rimuove da ONTAP.

   Accedi alla console NetApp ed elimina l'SVM:

   alatl12-gpcstge02::> vserver delete test-svm
   

   Output:

   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
   

Segui queste istruzioni per ruotare manualmente il certificato ONTAP se riscontri errori durante la convalida.

Istruzioni

Se il nome del certificato ONTAP precedente non è applicabile, non è necessario ruotare nulla in ONTAP. Ispeziona il certificato e il secret in Kubernetes ed elimina il secret.

1. Genera un nuovo certificato, facendo riferimento alla tabella precedente per il nome del 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. Visualizza i certificati installati per un determinato vserver, per i certificati installati in ONTAP (non contrassegnati come non applicabili):

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

3. Ispeziona il secret corrispondente in Kubernetes (fai riferimento alla tabella precedente):

   kubectl get certificates -n <namespace>
   

4. Quando la corrispondenza è soddisfacente, genera un nuovo certificato eliminando il segreto:

   kubectl delete secret -n <namespace> <secret_name>
   

5. Ispeziona nuovamente il secret per verificare che sia stato rigenerato un nuovo certificato. Una volta confermato, crea un nuovo certificato server in ONTAP. Solo esegui i seguenti passaggi per i certificati precedenti con il suffisso "server-cert".

6. Estrai il corpo del nuovo certificato TLS utilizzando kubectl e altri strumenti direttamente e installalo in ONTAP:

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

   Il primo prompt sarà:

   Please enter Certificate: Press <Enter> when done

   In cui devi inserire tls.crt. Se in tls.crt sono presenti più blocchi di certificati, inserisci il primo e mantieni i restanti blocchi di certificati come certificati intermedi per riferimento nel passaggio successivo.

7. Il sistema ti chiederà: Please enter Private Key: Press <Enter> when done. Incolla i contenuti del file tls.key e premi Invio.

   Successivamente, verrà visualizzato il prompt: Do you want to continue entering root and/or intermediate certificates {y|n}: Se il file tls.crt contiene un solo certificato, digita N e premi Invio. In caso contrario, digita Y e premi Invio.

   Se hai digitato Y: ti verrà chiesto di inserire i certificati intermedi. Incollali uno alla volta dal file tls.crt, premendo Invio dopo ciascuno. Infine, incolla il certificato radice dal file ca.crt e premi Invio.

   Se hai digitato N: (non sono necessarie ulteriori azioni in merito ai certificati in questa richiesta)

   ONTAP restituirà quindi un numero di serie. Prendi nota di questo numero, in quanto rappresenta il numero di serie del nuovo certificato e della nuova CA. Questo numero di serie verrà indicato come <new\_server\_serial> e <new\_ca> nei passaggi successivi. Non seguire questi passaggi per il certificato se stai configurando un certificato server S3.

8. Visualizza lo stato attuale delle configurazioni SSL per il vserver e il cluster. Tieni a portata di mano la CA di emissione del certificato server, il nome comune del certificato server e il numero di serie del certificato server, in quanto verranno indicati rispettivamente come <old\_server\_common\_name>, <old\_ca> e <old\_server\_serial>:

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

   Vengono restituite le informazioni SSL, con le informazioni del vecchio certificato del server. Puoi farvi riferimento in un secondo momento per assicurarti che siano state aggiornate, dopo aver modificato la configurazione SSL.

9. Modifica la configurazione SSL:

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

10. Visualizza il nuovo stato delle configurazioni SSL per il vserver e il cluster. Dovrebbe essere presente il numero di serie aggiornato del certificato del server ora installato:

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

11. Elimina il vecchio certificato del server dopo aver verificato il passaggio precedente:

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

Certificati client-CA

1. Recupera tutti i certificati CA da ConfigMap trust-store-internal-only nello spazio dei nomi gpc-system utilizzando il seguente comando:

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

2. Per ogni certificato CA recuperato nel passaggio precedente, esegui il seguente comando sul cluster ONTAP:

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

   Ti verrà chiesto: Please enter Certificate: Press <Enter> when done. Incolla ogni blocco di certificato recuperato nel passaggio 1 e premi Invio. Ripeti questo comando di installazione per ogni certificato CA.

Ruota i certificati Harvest

La generazione del certificato di raccolta dipende da <hostname>-read-only-cert-secret. Prima di procedere, assicurati che <hostname>-read-only-cert-secret sia ruotato.

1. Visualizza i certificati installati per il 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. Applica una patch al secret delle credenziali Harvest per fornire i certificati aggiornati:

   $ 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. Riavvia il servizio Harvest per caricare la configurazione aggiornata:

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

Ruota i certificati del file system

Esegui questo comando per rigenerare file-storage-webhooks-serving-cert e il certificato 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

Riavvia i pod per caricare la configurazione aggiornata:

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

Ruotare i certificati Trident e ONTAP

Trident deve comunicare con ONTAP. Questa opzione è configurata con il backend Trident, che utilizza il certificato client <svm\_name>-client-cert-secret> definito in precedenza. La rotazione dei certificati client non fa parte di Trident, ma Trident si basa su parti di questo certificato, che devono essere aggiornate.

Istruzioni

Per l'aggiornamento del certificato CA:

1. Esporta KUBECONFIG in modo che punti al file kubeconfig per il cluster specifico dei componenti Trident in questione. Su ogni cluster verrà configurato Trident.

2. Recupera il certificato CA con codifica Base64 dal secret client-cert e memorizzalo come variabile:

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

3. Applica la patch all'oggetto tridentBackendConfig:

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

Per il certificato e la chiave del client effettivi:

1. Recupera il certificato TLS, con codifica Base64 dal secret client-cert e memorizzalo come variabile:

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

2. Recupera la chiave TLS, con doppia codifica Base64 dal secret client-cert e memorizzala come variabile:

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

3. Aggiorna il secret di backend con la chiave privata:

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

4. Applica la patch alla configurazione del backend con il certificato TLS:

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

Ruota i certificati del controller Trident

I container Trident devono comunicare con l'operatore Trident. Questa comunicazione viene eseguita tramite HTTPS e i certificati server e client devono essere gestiti nell'ambito di questa operazione.

Convalida

Verifica che sia il DaemonSet sia il deployment (se applicabile) siano in uno stato integro.

Segui queste istruzioni per ruotare manualmente i certificati del server e del client se trovi errori durante la convalida.

Istruzioni

Nessuno dei certificati server e client ha un certificato corrispondente sul lato ONTAP. Questi sono strettamente contenuti nei cluster.

1. Elimina il secret corrispondente al certificato in scadenza.

   kubectl delete secret -n netapp-trident <secret_name>
   

2. Riavvia il daemonset netapp-trident-csi:

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

3. Per le rotazioni dei certificati server, dovrai anche riavviare il deployment di netapp-trident-csi:

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

Certificato CA Trident

Il certificato CA viene utilizzato per fornire l'autorità di certificazione per la firma dei certificati server e client Trident.

Nome certificato	Spazio dei nomi	Secret	Descrizione
netapp-trident-csi-cert	netapp-trident	netapp-trident-csi-cert	Certificato CA Trident

Convalida

Viene visualizzato il secret rigenerato. Affinché i certificati client e server abbiano effetto, puoi anche seguire la rotazione dei certificati del controller Trident nelle istruzioni precedenti dopo aver ruotato questo certificato.

Segui le istruzioni riportate di seguito per ruotare manualmente il certificato CA se trovi errori durante la convalida.

Istruzioni

Per ruotare questa chiave, devi solo eliminare il secret da Kubernetes:

kubectl delete secret -n netapp-trident <secret_name>

Nodi CSI Trident e SVM (dati)

Si tratta di un insieme di credenziali iSCSI CHAP a livello di SVM per consentire l'accesso al piano dati per l'accesso a blocchi. Questa limitazione non si applica ai protocolli di file.

Server API Management

Spazio dei nomi	Secret	Descrizione
gpc-system	<organization>-<type>-svm-credential	Configurazione SVM necessaria per la configurazione di Trident

Server API di amministrazione e gestione dell'organizzazione

Spazio dei nomi	Secret	Descrizione
gpc-system	<organization>-<type>-svm-credential	Configurazione SVM necessaria per la configurazione di Trident
netapp-trident	netapp-trident-backend-tbc-ontap	Secret necessario per gestire il backend di Trident

Convalida

1. Verifica che il backend sia ancora configurato correttamente:

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

2. Verifica che lo stato del backend sia Success.

Segui le istruzioni riportate di seguito per ruotare manualmente i secret se riscontri errori durante la convalida.

Istruzioni

Genera una nuova stringa casuale di 16 caratteri senza caratteri speciali per il secret dell'iniziatore e il secret dell'iniziatore di destinazione:

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

Chiave AES Trident

La chiave AES viene utilizzata internamente da Trident per criptare le credenziali iSCSI CHAP per l'uso interno di Trident. Si tratta di una sequenza casuale di caratteri che deve avere una lunghezza di 32 byte.

Cluster che eseguono Trident (potrebbero essere cluster root/org-admin/user/system)

Spazio dei nomi	Secret	Descrizione
netapp-trident	netapp-trident-aes-key	Chiave AES necessaria a Trident per criptare le credenziali CHAP iSCSI

Convalida

1. Verifica che il backend sia ancora configurato correttamente:

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

2. Verifica che lo stato del backend sia Success.

3. Tentativo di creare un volume di test:

   1. Crea un file YAML con le informazioni PVC:

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

   2. Applica il file al cluster Kubernetes:

      kubectl apply -f pvc.yaml
      

4. Verifica che non ci siano errori nei log CSI dovuti alla crittografia iSCSI:

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

   Se non si sono verificati errori, non vengono restituiti log.

5. Pulisci il file e il PVC:

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

Segui queste istruzioni per ruotare manualmente la chiave se riscontri errori durante la convalida.

Istruzioni

Prima di ruotare questa chiave, assicurati che non ci siano pod in attesa con PV nel cluster. In caso affermativo, attendi il completamento del provisioning prima di ruotare la chiave.

Genera una nuova stringa casuale di 32 caratteri senza caratteri speciali per 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

Esegui il rollback

1. Esegui il rollback alle credenziali utilizzate l'ultima volta se si verificano errori:

   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. Ripeti i passaggi di verifica.