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

Completa 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 acceda 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.
    kubectl get pvc [-n <namespace>]
  2. Describa cada PVC.
    kubectl 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. Anote 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.
    kubectl get pods [-n <namespace>]
  2. Describa cada vaina.
    kubectl 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.

    kubectl 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.

    kubectl 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.

    kubectl apply -f <pvc-file-name>

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

    kubectl get PVC <pvc>

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

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.
    kubectl 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. Obtén el pod yaml.

    kubectl 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.

    kubectl apply -f <pod-yaml-file>

  4. Compruebe que el pod se está ejecutando.

    kubectl get pods

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