Migrazione da Hyper Protect Crypto Services a Key Protect per COS

Migrare la crittografia di Hyper Protect Crypto Services (HPCS) per il plugin IBM Cloud Object Storage s3fs per utilizzare invece Key Protect (KP).

Prima di iniziare

Prima di iniziare, seguire questi passaggi per determinare se è necessario migrare il plugin COS per utilizzare Key Protect invece di HPCS.

  1. Ottenere il CRN delle istanze HPCS e KP. Eseguire il seguente comando per ogni istanza.

    ibmcloud resource service-instance <instance-name>

    Output di esempio.

    Name:  my-hpcs-instance
ID:    crn:v1:bluemix:public:kms:us-south:a/1ab234cd5e678fgh9a0123bc4de567:f89gh01a-bcd2-3456-e789-f0g1234h5ab6::

  2. Elencare tutti i segreti del cluster di tipo ibm/ibmc-s3fs.

    kubectl get secrets --field-selector type=ibm/ibmc-s3fs

  3. Per ogni segreto ibm/ibmc-s3fs, esaminare il contenuto del segreto e trovare la chiave principale kp-root-key-crn nella sezione data. Si noti qualsiasi segreto con un valore kp-root-key-crn che includa la stringa hs-crypto, che indica che si tratta di una chiave radice HPCS e che deve essere migrata. Salvare l'elenco dei segreti da migrare. Se non ci sono valori kp-root-key-crn che contengono hs-crypto, non è necessario seguire i passaggi della migrazione.

Prerequisiti per la migrazione

Completate questi passaggi prima di iniziare.

  1. Se sul cluster è installato un diagramma COS helm, assicurarsi che esegua la versione più recente.
  2. Se non ne avete già una, create una nuova istanza di Key Protect e un nuovo set di chiavi Key Protect per la crittografia. Assicurarsi che l'istanza Key Protect sia creata nella stessa regione del cluster. Questo è necessario affinché l'istanza Key Protect possa accedere alle risorse COS.
  3. Creare un'autorizzazione da servizio a servizio per Key Protect per accedere alle risorse COS. Impostare il servizio di origine come Key Protect e il servizio di destinazione come COS e impostare il livello di accesso almeno su Reader.

Passi di migrazione

Seguite questi passaggi per migrare il vostro plugin COS a Key Protect.

Se tutti i segreti COS e i PVC si trovano in uno specifico spazio dei nomi, è possibile applicare i passaggi seguenti a tale spazio dei nomi. Altrimenti, cercare tra tutti i namespace del cluster.

Passo 1. Elenco dei PVC da migrare

Determinare quali PVC devono essere migrati.

  1. Elencare tutti i PVC presenti nel cluster o nel namespace pertinente.
    oc get pvc [-n <namespace>]
  2. Descrivete ogni PVC.
    oc describe pvc <pvc-name>
  3. Nell'output del PVC, trovare la sezione Annotazioni e verificare se volume.kubernetes.io/storage-provisioner: ibm.io/ibmc-s3fs è elencato.
  4. Se l'annotazione è elencata, cercare l'annotazione ibm.io/secret-name.
  5. Se l'annotazione volume.kubernetes.io/storage-provisioner: ibm.io/ibmc-s3fs è elencata e il valore ibm.io/secret-name corrisponde a uno qualsiasi dei segreti trovati che hanno una chiave radice HPCS, il PVC deve essere migrato. Osservare il nome del PVC.
  6. Ripetere questi passaggi per ogni PVC. Salvare l'elenco dei PVC da migrare.

Passo 2. Elenco dei pod da migrare

Determinare quali pod devono essere migrati.

  1. Elenca tutti i pod nel cluster o nel relativo spazio dei nomi.
    oc get pods [-n <namespace>]
  2. Descrivete ogni capsula.
    oc describe pod <pod-name>
  3. Nell'output, trovare la sezione Volumi e controllare il nome di ciascuno di essi PersistentVolumeClaim. Se uno qualsiasi dei PVC nell'output è incluso nell'elenco dei PVC da migrare, il pod deve essere migrato. Osservare il nome del baccello.
  4. Ripetere questi passaggi per ogni baccello. Salvare l'elenco dei pod da migrare.

Passo 3. Creare nuovi segreti

Creare nuovi segreti che utilizzino la chiave principale Key Protect invece della chiave principale HPCS.

  1. Ottenere il CRN dell'istanza Key Protect e codificarlo in base64.

    ibmcloud resource service-instance <kp-instance-name>

    echo  -n "<root_key_CRN>" | base64

  2. Per ogni segreto da migrare, ottenere lo yaml del segreto.

    oc get secret <secret-name> -o yaml

  3. Copiare lo yaml in un file per creare un nuovo segreto. Modificare kp-root-key-crn in modo che punti al CRN codificato base64 dell'istanza Key Protect. Aggiungere una stringa alla fine del nome del segreto per distinguere il nuovo segreto da quello vecchio.

    Quando si ricreano i PVC, è necessario specificare la nuova copia del segreto utilizzato dal PVC. Assicuratevi che il nome del nuovo segreto corrisponda a quello del vecchio segreto, ma che permetta di distinguere i due.

  4. Applicare il segreto.

    kubectl apply -f <secret-file-name>

  5. Ripetere questi passaggi per ogni segreto da migrare.

Passo 4. Ricreare i PVC

Ricreare i PVC in modo che puntino ai nuovi segreti.

  1. Per ogni PVC da migrare, ottenere il PVC yaml.

    oc get PVC <pvc-name> -o yaml

  2. Copiare lo yaml in un file per creare un nuovo PVC. Modificare le annotazioni ibm.io/secret-name e ibm.io/secret-namespace per puntare al nuovo segreto che corrisponde al segreto precedentemente elencato. Aggiungere una stringa alla fine del nome del PVC per differenziarlo dal vecchio PVC.

  3. Applicare il nuovo PVC.

    oc apply -f <pvc-file-name>

  4. Ottenere i dettagli del PVC e verificare che sia nello stato Bound.

    oc get PVC <pvc>

  5. Ripetete questi passaggi per ogni PVC da migrare.

Passo 5. Aggiornamento dei baccelli

Aggiornare i pod in modo che puntino ai nuovi PVC.

  1. Determinare il tipo di risorsa utilizzata. Nell'output, trovare la sezione ownerReferences e annotare il tipo di risorsa e il nome della risorsa elencata.
    oc describe pod <pod-name>
  2. Seguire le strategie di aggiornamento basate sulla risorsa elencata nella sezione ownerReferences sezione.

Ricreare manualmente il pod

  1. Ottenere il pod yaml.

    oc describe <resource-type> <resource-name> -o yaml

  2. Copiare lo yaml in un file per creare un nuovo pod. Nella sezione volumi dello yaml, modificare il parametro PersistentVolumeClaim per puntare al nuovo PVC che corrisponde al PVC precedentemente elencato. Aggiungere una stringa alla fine del nome della nuova risorsa per differenziarla da quella precedente.

  3. Applicare il nuovo file yaml.

    oc apply -f <pod-yaml-file>

  4. Verifica che il pod è in esecuzione.

    oc get pods

  5. Ripetete questi passaggi per ogni pod che deve essere migrato manualmente.