Migración de Hyper Protect Crypto Services a Key Protect para COS

Migre su cifrado Hyper Protect Crypto Services (HPCS) para el plugin IBM Cloud Object Storage s3fs para utilizar Key Protect (KP) en su lugar.

Antes de empezar

Antes de empezar, siga estos pasos para determinar si necesita migrar su plugin COS para utilizar Key Protect en lugar de HPCS.

  1. Obtenga el CRN de sus instancias HPCS y KP. Ejecute el siguiente comando para cada instancia.

    ibmcloud resource service-instance <instance-name>

    Ejemplo de salida.

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

  2. Enumere todos los secretos de su clúster que sean del tipo ibm/ibmc-s3fs.

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

  3. Para cada secreto ibm/ibmc-s3fs, revise el contenido del secreto y encuentre la clave raíz kp-root-key-crn en la sección data. Tenga en cuenta cualquier secreto con un valor kp-root-key-crn que incluya la cadena hs-crypto, que indica que es una clave raíz HPCS y debe migrarse. Guarde esta lista de secretos para migrar. Si no hay valores kp-root-key-crn que contengan hs-crypto, no es necesario seguir los pasos de migración.

Requisitos previos para la migración

Complete estos pasos antes de empezar.

  1. Si tiene una carta COS helm instalada en su cluster, asegúrese de que ejecuta la última versión.
  2. Si aún no dispone de una, cree una nueva instancia de Key Protect y un nuevo juego de claves Key Protect para el cifrado. Asegúrese de que su instancia Key Protect se ha creado en la misma región que su clúster. Esto es necesario para que la instancia Key Protect pueda acceder a sus recursos COS.
  3. Cree una autorización de servicio a servicio para que Key Protect acceda a sus recursos COS. Establezca el servicio de origen como Key Protect y el servicio de destino como COS, y establezca el nivel de acceso en Reader como mínimo.

Pasos de la migración

Siga estos pasos para migrar su plugin COS a Key Protect.

Si todos sus secretos COS y PVC se encuentran en un espacio de nombres específico, puede aplicar los siguientes pasos a ese espacio de nombres. Si no, busca en todos los namesapces de tu cluster.

Paso 1. Lista de PVC a migrar

Determine qué PVC deben migrarse.

  1. Enumera todos los PVC de tu clúster o del espacio de nombres correspondiente.
    oc get pvc [-n <namespace>]
  2. Describa cada PVC.
    oc describe pvc <pvc-name>
  3. En la salida PVC, busque la sección Anotaciones y compruebe si aparece volume.kubernetes.io/storage-provisioner: ibm.io/ibmc-s3fs.
  4. Si la anotación aparece en la lista, busque la anotación ibm.io/secret-name.
  5. Si la anotación volume.kubernetes.io/storage-provisioner: ibm.io/ibmc-s3fs aparece en la lista y el valor ibm.io/secret-name coincide con alguno de los secretos que has encontrado que tienen una clave raíz HPCS, el PVC debe migrarse. Fíjate en el nombre del PVC.
  6. Repita estos pasos para cada PVC. Guarda la lista de PVCs a migrar.

Paso 2. Lista de pods a migrar

Determine qué pods deben migrarse.

  1. Enumere todos los pods de su clúster o del espacio de nombres correspondiente.
    oc get pods [-n <namespace>]
  2. Describa cada vaina.
    oc describe pod <pod-name>
  3. En la salida, busque la sección Volúmenes y compruebe el nombre de cada uno de ellos PersistentVolumeClaim. Si alguno de los PVCs de la salida también está incluido en la lista de PVCs a migrar, entonces el pod debe ser migrado. Anote el nombre de la vaina.
  4. Repita estos pasos para cada vaina. Guarde la lista de pods a migrar.

Paso 3. Crear nuevos secretos

Cree nuevos secretos que utilicen la clave raíz Key Protect en lugar de la clave raíz HPCS.

  1. Obtenga el CRN de su instancia Key Protect y codifíquelo en base64.

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

    echo  -n "<root_key_CRN>" | base64

  2. Para cada secreto que deba migrar, obtenga el yaml del secreto.

    oc get secret <secret-name> -o yaml

  3. Copie el yaml en un archivo para crear un nuevo secreto. Cambie kp-root-key-crn para que apunte al CRN codificado en base64 de la instancia Key Protect. Añade una cadena al final del nombre del secreto para ayudar a diferenciar el nuevo secreto del antiguo.

    Cuando vuelva a crear sus PVC, deberá especificar la nueva copia del secreto utilizada por el PVC. Asegúrate de que el nombre del nuevo secreto se corresponde con el del antiguo, pero que permite diferenciar ambos.

  4. Aplica el secreto.

    kubectl apply -f <secret-file-name>

  5. Repite estos pasos para cada secreto que haya que migrar.

Paso 4. Recrear PVC

Recrea tus PVCs para que apunten a los nuevos secretos.

  1. Para cada PVC que deba migrar, obtenga el yaml del PVC.

    oc get PVC <pvc-name> -o yaml

  2. Copie el yaml en un archivo para crear un nuevo PVC. Cambia las anotaciones ibm.io/secret-name y ibm.io/secret-namespace para que apunten al nuevo secreto que corresponde al secreto listado anteriormente. Añade una cadena al final del nombre del PVC para ayudar a diferenciarlo del antiguo PVC.

  3. Aplique el nuevo PVC.

    oc apply -f <pvc-file-name>

  4. Obtén los datos del PVC y comprueba que está en estado Bound.

    oc get PVC <pvc>

  5. Repita estos pasos para cada PVC que deba migrarse.

Paso 5. Actualizar vainas

Actualiza los pods para que apunten a los nuevos PVCs.

  1. Determinar el tipo de recurso utilizado. En la salida, busque la sección ownerReferences y anote el tipo de recurso y el nombre del recurso listado.
    oc describe pod <pod-name>
  2. Siga las estrategias de actualización basadas en el recurso indicado en la ownerReferences sección.

Recreación manual del pod

  1. Obtenga el pod yaml.

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

  2. Copie el yaml en un archivo para crear un nuevo pod. En la sección de volúmenes del yaml, cambia el icono PersistentVolumeClaim para que apunte al nuevo PVC que corresponde al PVC listado anteriormente. Añade una cadena al final del nombre del nuevo recurso para diferenciarlo del antiguo.

  3. Aplique el nuevo archivo yaml.

    oc apply -f <pod-yaml-file>

  4. Compruebe que el pod se está ejecutando.

    oc get pods

  5. Repita estos pasos para cada pod que deba migrarse manualmente.