Migration des secrets de cluster et des nœuds de travail de HPCS vers Key Protect

Cloud privé virtuel Infrastructure classique

Vous pouvez migrer le chiffrement secret de votre cluster, votre pool de travailleurs et le chiffrement des disques des nœuds de travail de Hyper Protect Crypto Services (HPCS) vers IBM® Key Protect for IBM Cloud® à l'aide des outils de migration Key Protect. Ce processus met à jour les références des clés de chiffrement et des instances ainsi que l'utilisation des secrets de cluster, des travailleurs chiffrés et des pools de travailleurs.

Le processus de migration peut prendre jusqu'à une heure ou plus en fonction du nombre de ressources à migrer. Veillez à planifier en conséquence.

Avant de commencer

Avant de migrer de HPCS à Key Protect, examinez les exigences et les considérations suivantes.

  • Vous devez avoir créé une instance Key Protect et une clé racine. Pour plus d'informations, voir Configuration d'un fournisseur de services de gestion de clés(KMS).
  • Vous devez disposer des autorisations appropriées dans « IBM Cloud » ( Identity and Access Management, IAM) pour activer KMS dans votre cluster. Pour plus d'informations, voir Configuration d'un fournisseur de services de gestion de clés(KMS).
  • Des politiques d'autorisation de service à service doivent être mises en place et doivent être définies au niveau de l'instance ou du service Key Protect, et non au niveau du trousseau de clés ou de la clé. Il s'agit d'une limitation actuelle qui s'applique au chiffrement des secrets des nœuds de travail et des clusters.

Ne supprimez pas votre clé racine HPCS tant que la migration n'est pas terminée et que son succès n'a pas été vérifié.

Etape 1. Mise en place d'une autorisation de service à service

Avant de pouvoir migrer de HPCS vers Key Protect, vous devez configurer les politiques d'autorisation service à service requises dans IBM Cloud IAM. Cette étape doit être réalisée individuellement pour les secrets de cluster et les nœuds de travail. Notez que vous avez peut-être déjà mis en place ces politiques, auquel cas vous n'avez pas besoin de les recréer.

Autorisation pour le cryptage du secret de la grappe

Pour migrer le cryptage des secrets de cluster, vous avez besoin d'une politique d'autorisation de service de IBM Cloud Kubernetes Service vers votre instance Key Protect.

  1. Accédez à la page des autorisations de service dans la console IBM Cloud.
  2. Cliquez sur Créer.
  3. Définissez le compte source sur Ce compte si le cluster réside dans le compte actuel. Si le cluster se trouve dans un autre compte, sélectionnez Autre compte et indiquez l'ID du compte.
  4. Définissez le Service source sur Kubernetes Service.
  5. Réglez le service cible sur Key Protect.
  6. Étendre l'autorisation au niveau du service ou de l'instance Key Protect. Ne pas attacher à un porte-clés ou à une clé spécifique.
  7. Incluez au moins l'accès au service Lecteur.
  8. Autorisez la délégation de l'autorisation par les services source et dépendants.
  9. Cliquez sur Autoriser.

Autorisations pour le chiffrement des disques des nœuds de travail

Pour migrer le chiffrement des disques des nœuds de travail pour les clusters VPC, vous avez besoin de stratégies d'autorisation de service pour IBM Cloud Kubernetes Service et Cloud Block Storage vers votre instance Key Protect.

Procédez comme suit pour créer l'autorisation pour IBM Cloud Kubernetes Service. Si ces politiques existent déjà, il n'est pas nécessaire de les recréer.

  1. Accédez à la page des autorisations de service dans la console IBM Cloud.
  2. Cliquez sur Créer.
  3. Définissez le compte source sur Ce compte si le cluster réside dans le compte actuel. Si le cluster se trouve dans un autre compte, sélectionnez Autre compte et indiquez l'ID du compte.
  4. Définissez le Service source sur Kubernetes Service.
  5. Réglez le service cible sur Key Protect.
  6. Étendre l'autorisation au niveau du service ou de l'instance Key Protect. Ne pas attacher à un porte-clés ou à une clé spécifique.
  7. Incluez au moins l'accès au service Lecteur.
  8. Autorisez la délégation de l'autorisation par les services source et dépendants.
  9. Cliquez sur Autoriser.

Procédez comme suit pour créer l'autorisation pour Cloud Block Storage.

  1. Accédez à la page des autorisations de service dans la console IBM Cloud.
  2. Cliquez sur Créer.
  3. Définissez le compte source sur Ce compte si le cluster réside dans le compte actuel. Si le cluster se trouve dans un autre compte, sélectionnez Autre compte et indiquez l'ID du compte.
  4. Définissez le Service source sur Cloud Block Storage. Notez que dans l'interface de programmation, le service source est appelé server-protect.
  5. Réglez le service cible sur Key Protect.
  6. Étendre l'autorisation au niveau du service ou de l'instance Key Protect. Ne pas attacher à un porte-clés ou à une clé spécifique.
  7. Incluez au moins l'accès au service Lecteur.
  8. Cliquez sur Autoriser.

Red Hat OpenShift on IBM Cloud crée automatiquement une politique de délégation service à service supplémentaire pour le service Cloud Block Storage dans le compte de service géré IBM vers l'instance Key Protect. Cette politique de délégation est nécessaire pour que l'infrastructure VPC puisse crypter le volume de démarrage des nœuds de travail avec votre clé racine Key Protect. Si vous rencontrez des problèmes après la migration, vérifiez que cette politique d'autorisation déléguée existe dans vos autorisations IAM.

Étape 2. Identifier les usages clés pour la migration

Identifiez les ressources de votre compte qui doivent être migrées de HPCS à Key Protect. Pour plus d'informations sur les différentes méthodes d'identification de l'utilisation, voir Recherche d'utilisation dans la documentation Key Protect.

Pour chaque cluster, vous pouvez visualiser les enregistrements de clés à l'aide de la commande ibmcloud kp registrations -i KMS_INSTNACE_ID KEY_ID. La sortie montre les enregistrements de clés suivants : - Un enregistrement pour les secrets de la grappe - Un enregistrement pour chaque groupe de travailleurs cryptés - Un enregistrement pour chaque travailleur crypté

Les enregistrements pourraient ressembler à ce qui suit :

"crn:v1:staging:public:containers-kubernetes:us-south:a/1152aa1c1ec54274ac42b8ad8507c90c:d70mi70206f7fchch5h0::
crn:v1:staging:public:containers-kubernetes:us-south:a/1152aa1c1ec54274ac42b8ad8507c90c:d79qqpt20aca2a0ii8v0:worker-pool:d79qqpt20aca2a0ii8v0-edea88a
crn:v1:staging:public:is:us-south-1:a/e2523561f3864f058711d94392c19e9b::volume:r134-799cdc60-c598-4a58-913b-b29ad312a143

Optionnel : Utilisation de l'outil Key Usage Reporter

Une méthode disponible pour identifier l'utilisation des clés est l'outil Key Usage Reporter (KUR), qui analyse votre compte et fournit un rapport sur les clés HPCS utilisées. Cet outil de détection vous aide à identifier les grappes dont le chiffrement secret est activé avec des clés HPCS et les pools de travailleurs dont le chiffrement des disques des nœuds de travail est activé avec des clés HPCS. Le rapport présente les secrets de cluster, les travailleurs et les pools de travailleurs comme des ressources distinctes liées à une clé HPCS et à une instance spécifiques. Pour des instructions détaillées sur l'exécution de l'outil de détection, voir Détection de l'utilisation de la clé HPCS dans la documentation Key Protect.

Notez que l'outil KUR peut ne pas montrer tous les cas d'utilisation de HPCS, il est donc important d'examiner toutes les méthodes d'identification de l'utilisation. Si vous utilisez une instance de KMS inter-comptes, vous devez exécuter l'outil KUR dans tous les comptes concernés.

Étape 3. Exécution de l'outil de migration

Après avoir identifié les ressources utilisant des clés HPCS et configuré les autorisations de service requises, utilisez l'outil de migration Key Protect pour migrer vos clés de chiffrement. Avant de réaliser cette étape, assurez-vous d'avoir créé les politiques d'autorisation service à service requises.

Pour des instructions détaillées sur l'exécution de l'outil de migration, voir Migrating to Key Protect dans la documentation Key Protect.

Ce qui se passe pendant la migration

Lorsque vous exécutez l'outil de migration, les actions suivantes se produisent :

Cryptage du secret de la grappe
La migration déclenche la création d'un enregistrement de clé sur la clé Key Protect. Ensuite, la clé de cryptage des données est recryptée en utilisant la clé Key Protect au lieu de la clé HPCS. L'enregistrement est alors supprimé de la clé HCPS. Il n'y a pas de temps d'arrêt prévu pendant l'opération et votre cluster continue à fonctionner normalement.
Cryptage du disque du nœud de travail
  • Pour les pools de travailleurs cryptés: La migration déclenche la création d'un enregistrement de clé sur le pool de travailleurs pour les travailleurs chiffrés. Les références à l'instance et à la clé HPCS sont mises à jour pour pointer vers l'instance et la clé Key Protect. L'enregistrement est ensuite supprimé de la clé HPCS. Tous les nouveaux travailleurs ajoutés au pool de travailleurs utilisent désormais les informations clés mises à jour. Il n'y a pas de temps d'arrêt prévu pendant l'opération et votre groupe de travailleurs continue à fonctionner normalement.
  • Pour les travailleurs individuels: La migration déclenche la création d'un enregistrement de clé sur la clé Key Protect. Ensuite, la clé de cryptage des données est recryptée en utilisant la clé Key Protect au lieu de la clé HPCS. L'enregistrement est alors supprimé de la clé HCPS. Il n'y a pas de temps d'arrêt prévu pendant l'opération et votre travailleur continue à fonctionner normalement.

Pendant la migration, Red Hat OpenShift on IBM Cloud crée automatiquement une politique de délégation service à service supplémentaire pour le service Cloud Block Storage dans le compte de service géré IBM vers l'instance Key Protect. Cette politique de délégation est nécessaire pour que l'infrastructure VPC puisse crypter le volume de démarrage des nœuds de travail avec votre clé racine Key Protect. Si vous rencontrez des problèmes pendant ou après la migration, vérifiez que cette politique d'autorisation déléguée existe dans vos autorisations IAM.

Étape 4. Vérification de la migration

Une fois la migration terminée, vérifiez que votre cluster utilise la clé Key Protect.

  1. Vérifiez l'état de la grappe pour vous assurer que le maître est prêt.

    ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID

    Dans la sortie, vérifiez que l'état du maître est prêt et que le service de gestion des clés affiche l'ID de l'instance KMS et l'ID de la clé racine KMS de l'instance Key Protect.

  2. Pour le chiffrement des nœuds de travailleur, vérifiez que le pool de travailleur fait référence à la clé Key Protect.

    ibmcloud oc worker-pool get --worker-pool WORKER_POOL_NAME_OR_ID --cluster CLUSTER_NAME_OR_ID

    Examinez les champs KMS et CRK dans la sortie pour confirmer qu'ils font référence à votre instance Key Protect et à votre clé racine.

  3. Vérifiez que vous pouvez accéder aux secrets du cluster.

    oc get secrets --all-namespaces

  4. Dans votre instance Key Protect, vérifiez que le cluster, les travailleurs et les pools de travailleurs sont enregistrés sur la nouvelle clé racine et que les enregistrements de clés n'existent pas sur les anciennes clés HPCS. Pour plus d'informations, voir Affichage des associations entre les clés racine et les ressources chiffrées IBM Cloud.

Etapes suivantes

Après avoir migré avec succès vers Key Protect et vérifié la migration :

  • Surveillez votre cluster pour détecter tout problème lié au cryptage ou à l'accès aux clés.
  • Mettre à jour toute la documentation ou les runbooks qui font référence à l'instance HPCS.
  • Envisagez de faire tourner votre clé racine Key Protect conformément à vos politiques de sécurité.