Migration de Hyper Protect Crypto Services à Key Protect pour le COS

Migrer votre cryptage Hyper Protect Crypto Services (HPCS) pour le plugin IBM Cloud Object Storage s3fs pour utiliser Key Protect (KP) à la place.

Avant de commencer

Avant de commencer, suivez les étapes suivantes pour déterminer si vous devez migrer votre plugin COS pour utiliser Key Protect au lieu de HPCS.

  1. Obtenez le CRN de vos instances HPCS et KP. Exécutez la commande suivante pour chaque instance.

    ibmcloud resource service-instance <instance-name>

    Exemple de sortie.

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

  2. Listez tous les secrets de votre cluster qui sont de type ibm/ibmc-s3fs.

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

  3. Pour chaque secret ibm/ibmc-s3fs, examinez le contenu du secret et trouvez la clé racine kp-root-key-crn dans la section data. Notez tout secret dont la valeur kp-root-key-crn comprend la chaîne hs-crypto, qui indique qu'il s'agit d'une clé racine HPCS et qu'elle doit être migrée. Enregistrer cette liste de secrets à migrer. Si aucune valeur de kp-root-key-crn ne contient hs-crypto, il n'est pas nécessaire de suivre les étapes de la migration.

Conditions préalables à la migration

Effectuez les étapes suivantes avant de commencer.

  1. Si vous avez un diagramme COS helm installé sur votre cluster, assurez-vous qu'il exécute la dernière version.
  2. Si vous n'en avez pas encore, créez une nouvelle instance Key Protect et un nouveau jeu de clés Key Protect pour le cryptage. Assurez-vous que votre instance Key Protect est créée dans la même région que votre cluster. Ceci est nécessaire pour que l'instance Key Protect puisse accéder à vos ressources COS.
  3. Créez une autorisation de service à service pour que Key Protect puisse accéder à vos ressources COS. Définissez le service source comme Key Protect et le service cible comme COS, et définissez le niveau d'accès comme étant au moins Reader.

Etapes de migration

Suivez les étapes suivantes pour migrer votre plugin COS vers Key Protect.

Si tous vos secrets COS et PVC se trouvent dans un espace de noms spécifique, vous pouvez étendre les étapes suivantes à cet espace de noms. Dans le cas contraire, il faut rechercher dans tous les namesapces de votre cluster.

Étape 1. Liste des PVC à migrer

Déterminer les PVC qui doivent être migrés.

  1. Dressez la liste de tous les PVC de votre cluster ou de l'espace de noms correspondant.
    oc get pvc [-n <namespace>]
  2. Décrivez chaque PVC.
    oc describe pvc <pvc-name>
  3. Dans la sortie PVC, recherchez la section Annotations et vérifiez si le site volume.kubernetes.io/storage-provisioner: ibm.io/ibmc-s3fs est répertorié.
  4. Si l'annotation est répertoriée, recherchez l'annotation ibm.io/secret-name.
  5. Si l'annotation volume.kubernetes.io/storage-provisioner: ibm.io/ibmc-s3fs est répertoriée et que la valeur ibm.io/secret-name correspond à l'un des secrets pour lesquels vous avez trouvé une clé racine HPCS, le PVC doit être migré. Notez le nom du PVC.
  6. Répétez ces étapes pour chaque PVC. Enregistrer la liste des PVC à migrer.

Étape 2. Liste des pods à migrer

Déterminer quels pods doivent être migrés.

  1. Liste de tous les pods sur votre cluster ou dans l'espace de noms correspondant.
    oc get pods [-n <namespace>]
  2. Décrivez chaque capsule.
    oc describe pod <pod-name>
  3. Dans le résultat, trouvez la section Volumes et vérifiez le nom de chaque fichier PersistentVolumeClaim. Si l'un des PVC de la sortie est également inclus dans la liste des PVC à migrer, le pod doit être migré. Notez le nom de la capsule.
  4. Répéter ces étapes pour chaque gousse. Enregistrer la liste des pods à migrer.

Étape 3. Créer de nouveaux secrets

Créer de nouveaux secrets qui utilisent la clé racine Key Protect au lieu de la clé racine HPCS.

  1. Obtenez le CRN de votre instance Key Protect et encodez-le dans base64.

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

    echo  -n "<root_key_CRN>" | base64

  2. Pour chaque secret que vous devez migrer, récupérez le secret yaml.

    oc get secret <secret-name> -o yaml

  3. Copiez le fichier yaml dans un fichier pour créer un nouveau secret. Modifier le kp-root-key-crn pour qu'il pointe vers le CRN codé base64 de l'instance Key Protect. Ajouter une chaîne de caractères à la fin du nom du secret pour aider à différencier le nouveau secret de l'ancien.

    Lorsque vous recréez vos PVC, vous devez spécifier la nouvelle copie du secret utilisé par le PVC. Veillez à ce que le nom du nouveau secret corresponde à celui de l'ancien, tout en vous permettant de faire la distinction entre les deux.

  4. Appliquer le secret.

    kubectl apply -f <secret-file-name>

  5. Répétez ces étapes pour chaque secret à migrer.

Étape 4. Recréer des PVC

Recréez vos PVC pour qu'ils pointent vers les nouveaux secrets.

  1. Pour chaque PVC que vous devez migrer, récupérez le PVC yaml.

    oc get PVC <pvc-name> -o yaml

  2. Copier le yaml dans un fichier pour créer un nouveau PVC. Modifiez les annotations ibm.io/secret-name et ibm.io/secret-namespace pour qu'elles indiquent le nouveau secret correspondant au secret précédemment répertorié. Ajouter une chaîne à la fin du nom du PVC pour le différencier de l'ancien PVC.

  3. Appliquer le nouveau PVC.

    oc apply -f <pvc-file-name>

  4. Obtenez les détails du PVC et vérifiez qu'il est dans l'état "Bound".

    oc get PVC <pvc>

  5. Répétez ces étapes pour chaque PVC qui doit être migré.

Étape 5. Mise à jour des nacelles

Mettez à jour les pods pour qu'ils pointent vers les nouveaux PVC.

  1. Déterminer le type de ressource utilisé. Dans le résultat, recherchez la section ownerReferences et notez le type de ressource et le nom de la ressource répertoriée.
    oc describe pod <pod-name>
  2. Suivez les stratégies de mise à jour basées sur les ressources répertoriées dans la section ownerReferences section.

Recréer manuellement le pod

  1. Obtenir le pod yaml.

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

  2. Copier le yaml dans un fichier pour créer un nouveau pod. Dans la section volumes du fichier yaml, modifiez le paramètre PersistentVolumeClaim pour pointer vers le nouveau PVC qui correspond au PVC précédemment listé. Ajouter une chaîne de caractères à la fin du nom de la nouvelle ressource pour la différencier de l'ancienne.

  3. Appliquer le nouveau fichier yaml.

    oc apply -f <pod-yaml-file>

  4. Vérifiez que le pod s'exécute.

    oc get pods

  5. Répétez ces étapes pour chaque module qui doit être migré manuellement.