Migração de Hyper Protect Crypto Services para Key Protect para COS

Migre sua criptografia Hyper Protect Crypto Services (HPCS) para o plug-in IBM Cloud Object Storage s3fs para usar Key Protect (KP).

Antes de Iniciar

Antes de começar, siga estas etapas para determinar se você precisa migrar seu plug-in COS para usar Key Protect em vez de HPCS.

  1. Obtenha o CRN de suas instâncias HPCS e KP. Execute o seguinte comando para cada instância.

    ibmcloud resource service-instance <instance-name>

    Exemplo de saída.

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

  2. Liste todos os segredos em seu cluster que são do tipo ibm/ibmc-s3fs.

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

  3. Para cada segredo ibm/ibmc-s3fs, revise o conteúdo do segredo e encontre a chave raiz kp-root-key-crn na seção data. Observe qualquer segredo com um valor kp-root-key-crn que inclua a string hs-crypto, que indica que é uma chave raiz HPCS e deve ser migrada. Salve essa lista de segredos para migrar. Se não houver valores kp-root-key-crn que contenham hs-crypto, não será necessário seguir as etapas de migração.

Pré-requisitos para a migração

Conclua estas etapas antes de começar.

  1. Se você tiver um helm chart do COS instalado em seu cluster, verifique se ele executa a versão mais recente.
  2. Se você ainda não tiver uma, crie uma nova instância Key Protect e um novo conjunto de chaves Key Protect para criptografia. Certifique-se de que sua instância Key Protect seja criada na mesma região do cluster. Isso é necessário para que a instância Key Protect acesse seus recursos de COS.
  3. Crie uma autorização de serviço a serviço para que o site Key Protect acesse seus recursos COS. Defina o serviço de origem como Key Protect e o serviço de destino como COS e defina o nível de acesso como, no mínimo, Reader.

Etapas da migração

Siga estas etapas para migrar seu plug-in COS para Key Protect.

Se todos os seus segredos de COS e PVCs estiverem em um namespace específico, você poderá aplicar as etapas a seguir a esse namespace. Caso contrário, pesquise todos os namesapces em seu cluster.

Etapa 1. Lista de PVCs a serem migrados

Determine quais PVCs devem ser migrados.

  1. Liste todos os PVCs em seu cluster ou no namespace relevante.
    oc get pvc [-n <namespace>]
  2. Descreva cada PVC.
    oc describe pvc <pvc-name>
  3. Na saída do PVC, localize a seção Annotations (Anotações ) e verifique se o site volume.kubernetes.io/storage-provisioner: ibm.io/ibmc-s3fs está listado.
  4. Se a anotação estiver listada, procure a anotação ibm.io/secret-name.
  5. Se a anotação volume.kubernetes.io/storage-provisioner: ibm.io/ibmc-s3fs estiver listada e o valor ibm.io/secret-name corresponder a qualquer um dos segredos que você descobriu ter uma chave raiz HPCS, o PVC deverá ser migrado. Observe o nome do PVC.
  6. Repita essas etapas para cada PVC. Salve a lista de PVCs a serem migrados.

Etapa 2. Lista de pods a serem migrados

Determine quais pods devem ser migrados.

  1. Liste todos os pods em seu cluster ou no namespace relevante.
    oc get pods [-n <namespace>]
  2. Descreva cada cápsula.
    oc describe pod <pod-name>
  3. Na saída, localize a seção Volumes e verifique o nome de cada PersistentVolumeClaim. Se algum dos PVCs na saída também estiver incluído na lista de PVCs a serem migrados, o pod deverá ser migrado. Observe o nome do pod.
  4. Repita essas etapas para cada cápsula. Salve a lista de pods a serem migrados.

Etapa 3. Criar novos segredos

Crie novos segredos que usem a chave raiz Key Protect em vez da chave raiz HPCS.

  1. Obtenha o CRN de sua instância Key Protect e codifique-o para base64.

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

    echo  -n "<root_key_CRN>" | base64

  2. Para cada segredo que você precisa migrar, obtenha o yaml do segredo.

    oc get secret <secret-name> -o yaml

  3. Copie o yaml em um arquivo para criar um novo segredo. Altere o endereço kp-root-key-crn para apontar para o CRN codificado em base64 da instância Key Protect. Acrescente uma cadeia de caracteres ao final do nome do segredo para ajudar a diferenciar o novo segredo do antigo.

    Ao recriar seus PVCs, você deve especificar a nova cópia do segredo usado pelo PVC. Certifique-se de que o nome do novo segredo corresponda ao segredo antigo, mas ainda assim permita que você diferencie os dois.

  4. Aplique o segredo.

    kubectl apply -f <secret-file-name>

  5. Repita essas etapas para cada segredo que precisa ser migrado.

Etapa 4. Recriar PVCs

Recrie seus PVCs para que eles apontem para os novos segredos.

  1. Para cada PVC que você precisa migrar, obtenha o yaml do PVC.

    oc get PVC <pvc-name> -o yaml

  2. Copie o yaml em um arquivo para criar um novo PVC. Altere as anotações ibm.io/secret-name e ibm.io/secret-namespace para apontar para o novo segredo que corresponde ao segredo listado anteriormente. Acrescente uma cadeia de caracteres ao final do nome do PVC para ajudar a diferenciá-lo do PVC antigo.

  3. Aplique o novo PVC.

    oc apply -f <pvc-file-name>

  4. Obtenha os detalhes do PVC e verifique se ele está no estado Bound.

    oc get PVC <pvc>

  5. Repita essas etapas para cada PVC que precisa ser migrado.

Etapa 5. Atualizar pods

Atualize os pods para que eles apontem para os novos PVCs.

  1. Determine o tipo de recurso que foi usado. Na saída, localize a seção ownerReferences e anote o tipo de recurso e o nome do recurso listado.
    oc describe pod <pod-name>
  2. Siga as estratégias de atualização com base no recurso listado na ownerReferences seção.

Recriação manual do pod

  1. Obtenha o pod yaml.

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

  2. Copie o yaml em um arquivo para criar um novo pod. Na seção de volumes do yaml, altere o PersistentVolumeClaim para apontar para o novo PVC que corresponde ao PVC listado anteriormente. Acrescente uma cadeia de caracteres ao final do nome do novo recurso para ajudar a diferenciá-lo do recurso antigo.

  3. Aplique o novo arquivo yaml.

    oc apply -f <pod-yaml-file>

  4. Verifique se o pod está em execução.

    oc get pods

  5. Repita essas etapas para cada pod que precisa ser migrado manualmente.