Migrazione dei segreti del cluster e dei nodi worker da HPCS a Key Protect

Virtual Private Cloud Infrastruttura classica

È possibile migrare la crittografia segreta del cluster, il pool di lavoratori e la crittografia del disco del nodo lavoratore da Hyper Protect Crypto Services (HPCS) a IBM® Key Protect for IBM Cloud® utilizzando gli strumenti di migrazione di Key Protect. Questo processo aggiorna la chiave di crittografia e i riferimenti alle istanze e all'uso dei segreti del cluster, dei lavoratori crittografati e dei pool di lavoratori.

Il processo di migrazione può richiedere fino a un'ora o più, a seconda del numero di risorse da migrare. Assicuratevi di pianificare di conseguenza.

Prima di iniziare

Prima di eseguire la migrazione da HPCS a Key Protect, verificate i requisiti e le considerazioni seguenti.

È necessario creare un'istanza di Key Protect e una chiave di root. Per ulteriori informazioni, vedere Impostazione di un provider di servizi di gestione delle chiavi(KMS).
È necessario disporre delle autorizzazioni corrette in IBM Cloud Identity and Access Management (IAM) per abilitare KMS nel cluster. Per ulteriori informazioni, vedere Impostazione di un provider di servizi di gestione delle chiavi(KMS).
Le politiche di autorizzazione da servizio a servizio devono essere presenti e devono essere definite a livello di istanza o servizio Key Protect, non a livello di anello o chiave. Si tratta di una limitazione attuale che si applica sia alla crittografia del nodo lavoratore che a quella del segreto del cluster.

Non cancellare la chiave root HPCS finché la migrazione non è stata completata e non ne è stato verificato il successo.

Passo 1. Impostazione dell'autorizzazione da servizio a servizio

Prima di poter migrare da HPCS a Key Protect, è necessario impostare i criteri di autorizzazione da servizio a servizio richiesti in IBM Cloud IAM. Questo passaggio deve essere completato individualmente per i segreti del cluster e i nodi worker. È possibile che questi criteri siano già presenti, nel qual caso non è necessario ricrearli.

Autorizzazione per la crittografia segreta del cluster

Per migrare la crittografia segreta del cluster, è necessario un criterio di autorizzazione del servizio da IBM Cloud Kubernetes Service alla vostra istanza Key Protect.

Accedere alla pagina delle autorizzazioni del servizio nella console IBM Cloud.
Fai clic su Crea.
Impostare l'account Sorgente su Questo account se il cluster risiede nell'account corrente. Se il cluster si trova in un altro account, selezionare Altro account e fornire l'ID dell'account.
Impostare il servizio Sorgente su Kubernetes Service.
Impostare il servizio Target su Key Protect.
L'autorizzazione viene estesa al livello del servizio o dell'istanza di Key Protect. Non è possibile fissare un portachiavi o una chiave specifica.
Includere almeno l'accesso al servizio Reader.
Consentire la delega dell'autorizzazione da parte dei servizi di origine e dei servizi dipendenti.
Fai clic su Autorizza.

Autorizzazioni per la crittografia del disco del nodo worker

Per migrare la crittografia del disco del nodo worker per i cluster VPC, sono necessari i criteri di autorizzazione del servizio sia per IBM Cloud Kubernetes Service che per Cloud Block Storage nell'istanza Key Protect.

Procedere come segue per creare l'autorizzazione per IBM Cloud Kubernetes Service. Se questi criteri esistono già, non è necessario ricrearli.

Accedere alla pagina delle autorizzazioni del servizio nella console IBM Cloud.
Fai clic su Crea.
Impostare l'account Sorgente su Questo account se il cluster risiede nell'account corrente. Se il cluster si trova in un altro account, selezionare Altro account e fornire l'ID dell'account.
Impostare il servizio Sorgente su Kubernetes Service.
Impostare il servizio Target su Key Protect.
L'autorizzazione viene estesa al livello del servizio o dell'istanza di Key Protect. Non è possibile fissare un portachiavi o una chiave specifica.
Includere almeno l'accesso al servizio Reader.
Consentire la delega dell'autorizzazione da parte dei servizi di origine e dei servizi dipendenti.
Fai clic su Autorizza.

Procedere come segue per creare l'autorizzazione per Cloud Block Storage.

Accedere alla pagina delle autorizzazioni del servizio nella console IBM Cloud.
Fai clic su Crea.
Impostare l'account Sorgente su Questo account se il cluster risiede nell'account corrente. Se il cluster si trova in un altro account, selezionare Altro account e fornire l'ID dell'account.
Impostare il servizio Sorgente su Cloud Block Storage. Si noti che nella CLI il servizio di origine è indicato come server-protect.
Impostare il servizio Target su Key Protect.
L'autorizzazione viene estesa al livello del servizio o dell'istanza di Key Protect. Non è possibile fissare un portachiavi o una chiave specifica.
Includere almeno l'accesso al servizio Reader.
Fai clic su Autorizza.

Red Hat OpenShift on IBM Cloud crea automaticamente un criterio di delega aggiuntivo da servizio a servizio per il servizio Cloud Block Storage nell'account del servizio gestito IBM all'istanza Key Protect. Questo criterio di delega è necessario affinché l'infrastruttura VPC possa crittografare il volume di avvio dei nodi worker con la chiave root Key Protect. Se si verificano problemi dopo la migrazione, verificare che questo criterio di autorizzazione delegata esista nelle autorizzazioni IAM.

Passo 2. Identificare l'utilizzo chiave per la migrazione

Identificare quali risorse dell'account devono essere migrate da HPCS a Key Protect. Per informazioni sui diversi metodi di identificazione dell'uso, vedere Ricerca dell'uso nella documentazione di Key Protect.

Per ogni cluster, è possibile visualizzare le registrazioni delle chiavi con il comando ibmcloud kp registrations -i KMS_INSTNACE_ID KEY_ID. L'output mostra le seguenti registrazioni di chiavi: - Una registrazione per i segreti del cluster - Una registrazione per ogni pool di lavoratori crittografato - Una registrazione per ogni lavoratore criptato

Le registrazioni potrebbero presentarsi in modo simile a quanto segue:

"crn:v1:staging:public:containers-kubernetes:us-south:a/1152aa1c1ec54274ac42b8ad8507c90c:d70mi70206f7fchch5h0::
crn:v1:staging:public:containers-kubernetes:us-south:a/1152aa1c1ec54274ac42b8ad8507c90c:d79qqpt20aca2a0ii8v0:worker-pool:d79qqpt20aca2a0ii8v0-edea88a
crn:v1:staging:public:is:us-south-1:a/e2523561f3864f058711d94392c19e9b::volume:r134-799cdc60-c598-4a58-913b-b29ad312a143

Opzionale: Utilizzo dello strumento Key Usage Reporter

Un metodo disponibile per identificare l'utilizzo delle chiavi è lo strumento Key Usage Reporter (KUR), che esegue una scansione dell'account e fornisce un rapporto sulle chiavi HPCS in uso. Questo strumento di rilevamento aiuta a identificare quali cluster hanno la crittografia segreta abilitata con chiavi HPCS e quali pool di lavoratori hanno la crittografia del disco del nodo lavoratore abilitata con chiavi HPCS. L'output del report mostra i segreti del cluster, i lavoratori e i pool di lavoratori come risorse separate legate a una chiave e a un'istanza HPCS specifica. Per istruzioni dettagliate sull'esecuzione dello strumento di rilevamento, vedere Rilevamento dell'uso della chiave HPCS nella documentazione di Key Protect.

Si noti che lo strumento KUR potrebbe non mostrare tutti i casi di utilizzo dell'HPCS, quindi è importante esaminare tutti i metodi per identificare l'utilizzo. Se si utilizza un'istanza di KMS che coinvolge più account, è necessario eseguire lo strumento KUR in tutti gli account interessati.

Passo 3. Esecuzione dello strumento di migrazione

Dopo aver identificato le risorse che utilizzano le chiavi HPCS e aver impostato le autorizzazioni di servizio richieste, utilizzare lo strumento di migrazione Key Protect per migrare le chiavi di crittografia. Prima di completare questo passaggio, accertarsi di aver creato i criteri di autorizzazione da servizio a servizio necessari.

Per istruzioni dettagliate sull'esecuzione dello strumento di migrazione, vedere Migrazione a Key Protect nella documentazione di Key Protect.

Cosa succede durante la migrazione

Quando si esegue lo strumento di migrazione, si verificano le seguenti azioni:

Crittografia segreta del cluster

La migrazione attiva la creazione di una registrazione di chiavi sulla chiave Key Protect. Quindi, la chiave di crittografia dei dati viene nuovamente crittografata utilizzando la chiave Key Protect invece della chiave HPCS. La registrazione viene quindi cancellata dalla chiave HCPS. Non sono previsti tempi di inattività durante l'operazione e il cluster continua a funzionare normalmente.

Crittografia del disco del nodo lavoratore

Per i pool di lavoratori crittografati: La migrazione attiva la creazione di una registrazione di chiavi sul pool di lavoratori per i lavoratori crittografati. I riferimenti all'istanza e alla chiave HPCS vengono aggiornati per puntare all'istanza e alla chiave Key Protect. La registrazione viene quindi cancellata dalla chiave HPCS. Tutti i nuovi lavoratori aggiunti al pool di lavoratori utilizzano ora le informazioni chiave aggiornate. Non sono previsti tempi di inattività durante l'operazione e il vostro pool di lavoratori continua a funzionare normalmente.

Per i singoli lavoratori: La migrazione attiva la creazione di una registrazione di chiavi sulla chiave Key Protect. Quindi, la chiave di crittografia dei dati viene nuovamente crittografata utilizzando la chiave Key Protect invece della chiave HPCS. La registrazione viene quindi cancellata dalla chiave HCPS. Non è previsto alcun tempo di inattività durante l'operazione e il lavoratore continua a funzionare normalmente.

Durante la migrazione, Red Hat OpenShift on IBM Cloud crea automaticamente un criterio di delega aggiuntivo da servizio a servizio per il servizio Cloud Block Storage nell'account del servizio gestito da IBM all'istanza Key Protect. Questo criterio di delega è necessario affinché l'infrastruttura VPC possa crittografare il volume di avvio dei nodi worker con la chiave root Key Protect. Se si verificano problemi durante o dopo la migrazione, verificare che questo criterio di autorizzazione delegata esista nelle autorizzazioni IAM.

Passo 4. Verifica della migrazione

Al termine della migrazione, verificare che il cluster utilizzi la chiave Key Protect.

Controllare lo stato del cluster per verificare che il master sia pronto.
```
ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
```
Nell'output, verificare che lo stato Master sia Pronto e che il Servizio di gestione delle chiavi mostri l'ID istanza KMS e l'ID chiave radice KMS dell'istanza Key Protect.
Per la crittografia dei nodi worker, verificare che il pool di worker faccia riferimento alla chiave Key Protect.
```
ibmcloud oc worker-pool get --worker-pool WORKER_POOL_NAME_OR_ID --cluster CLUSTER_NAME_OR_ID
```
Controllare i campi KMS e CRK nell'output per verificare che facciano riferimento all'istanza Key Protect e alla chiave root.
Verificare che sia possibile accedere ai segreti del cluster.
```
oc get secrets --all-namespaces
```
Nell'istanza Key Protect, verificare che il cluster, i lavoratori e i pool di lavoratori siano registrati sulla nuova chiave principale e che le registrazioni delle chiavi non esistano sulle vecchie chiavi HPCS. Per ulteriori informazioni, vedere Visualizzazione delle associazioni tra chiavi radice e risorse criptate di IBM Cloud.

Passi successivi

Dopo la migrazione a Key Protect e la verifica della migrazione:

Monitorare il cluster per individuare eventuali problemi legati alla crittografia o all'accesso alle chiavi.
Aggiornare la documentazione o i runbook che fanno riferimento all'istanza HPCS.
Considerate la possibilità di ruotare la chiave root di Key Protect in base ai vostri criteri di sicurezza.