Migration sur place des autorités de certification

Preview — In-place CA migration

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Remarque : Ce guide explique comment migrer votre autorité de certification sans effectuer de migration des charges de travail vers un nouveau plan de contrôle (sur place) avec un temps d'arrêt minimal à l'aide d'un outil basé sur bash. Pour effectuer une migration depuis Istio CA vers Mesh CA avec une approche à base de Canary qui implique un temps d'arrêt minimal ou nul, consultez la section Migration à base de Canary vers Mesh CA.

Si votre maillage comporte plusieurs clusters avec des charges de travail qui envoient des requêtes aux charges de travail d'un autre cluster, suivez toutes les étapes de ce guide pour tous les clusters.

Suivez les étapes décrites dans ce guide pour les cas d'utilisation suivants :

• Migration d'un plan de contrôle Anthos Service Mesh dans le cluster en version 1.13 ou ultérieure avec Mesh CA vers Certificate Authority Service.
• Migration d'un plan de contrôle Anthos Service Mesh géré sur une version disponible qui correspond à la version 1.13 ou ultérieure avec Mesh CA vers Certificate Authority Service.

Limites

Les migrations et les mises à niveau sur place des autorités de certification ne sont compatibles qu'avec Anthos Service Mesh en version 1.13 et ultérieures. Pour les migrations de plans de contrôle gérés, assurez-vous que le canal choisi correspond à la version 1.13 ou ultérieure.

Prérequis

Avant de suivre les étapes de ce guide, vérifiez les points suivants :

• Avoir accordé les autorisations d'administrateur de cluster
• Avoir configuré gcloud

En outre, assurez-vous que vous utilisez actuellement Anthos Service Mesh en version 1.13 ou ultérieure.

Outils requis

Pendant la migration, vous exécutez un outil fourni par Google, migrate_ca. Cet outil comporte les dépendances suivantes :

• awk
• grep
• jq
• kubectl
• head
• sed
• tr
• yq

Avant de télécharger l'outil migrate_ca, suivez les étapes décrites dans la section Préparer votre migration.

Présentation de la migration

Au cours du processus de migration, l'authentification et l'autorisation sont entièrement fonctionnelles entre les charges de travail utilisant l'autorité de certification précédente et les charges de travail utilisant la nouvelle autorité de certification.

L'outil de migration migrate_ca crée un mappage de configuration Kubernetes pour suivre l'état de la migration de l'autorité de certification par révision/version d'Anthos Service Mesh installée. Il s'agit d'une ressource privilégiée installée dans l'espace de noms istio-system.

apiVersion: v1
kind: ConfigMap
metadata:
  Name: asm-ca-migration-<revision>
Data:
  revision:
  start_time:
  state_update_time:
  current_state: TRUSTANCHOR_INJECT | MIGRATE_CA | ROLLBACK
  old_ca:
  target_ca:

L'outil de migration sauvegarde le mappage de configuration Istio MeshConfig avant de le modifier et tente de migrer la configuration de l'autorité de certification à l'aide de l'objet CRD ProxyConfig si possible.

Voici un aperçu de la migration de l'autorité de certification :

Remarque : Vous devez effectuer les étapes de migration sur chaque cluster de votre maillage.

1. Préparez votre migration.

2. Initialisez la nouvelle autorité de certification.

3. Ajoutez des trustAnchors à l'échelle du maillage pour tous les clusters du parc.

4. Migrez l'autorité de certification.

5. Effectuez un rollback.

Préparer votre migration

1. Téléchargez l'outil bash migrate_ca :

   curl  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/ca-migration/migrate_ca > migrate_ca
   

2. Rendez l'outil exécutable :

   chmod +x migrate_ca
   

3. Configurez le répertoire de travail :

   ./migrate_ca setup --output_dir OUTPUT_DIR
   

   Remarque : Si vous ne spécifiez pas de répertoire de travail, un répertoire temporaire sera créé. Vous devrez l'utiliser comme répertoire de travail pour toutes les étapes suivantes.

4. Passez au répertoire de travail OUTPUT_DIR spécifié à l'étape précédente.

   cd OUTPUT_DIR
   

5. Exécutez la commande suivante pour vous assurer que toutes les conditions préalables sont remplies :

   ./migrate_ca check-prerequisites
   

6. Notez la révision (ASM_REVISION) du plan de contrôle associé à l'autorité de certification précédente en cours de migration. Les étapes requises dépendent du type de plan de contrôle, qu'il soit dans le cluster ou géré.

   Dans le cluster

   asm-revision=$(kubectl get deploy -n istio-system -l app=istiod -o \
    "jsonpath={.items[*].metadata.labels[istio\.io/rev']}{'\n'}")
   

   Géré

   Reportez-vous à la version déjà installée.

7. Étant donné que la migration sur place de l'autorité de certification nécessite le redémarrage de vos charges de travail, assurez-vous que le Budget d'interruption de pod est correctement configuré, et que toutes les applications dont l'autorité de certification doit migrer disposent de plusieurs pods en cours d'exécution.

8. Assurez-vous que le cluster est déjà enregistré auprès d'un parc et que Workload Identity est activé sur le cluster. Notez ensuite l'ID de projet de parc en tant que (FLEET_ID) pour les étapes suivantes.

9. L'outil accepte kubeConfig et kubeContext pour sélectionner le cluster sur lequel les opérations sont effectuées. Si ces arguments ne sont pas transmis, le contexte ou la configuration par défaut sont utilisés.

   • Pour ajouter les identifiants d'un cluster GKE à kubeConfig, utilisez la commande suivante :

     gcloud container clusters get-credentials CLUSTER_NAME
     

   • Pour modifier le contexte kubectl actuel ou transmettre le contexte à l'outil, utilisez la commande suivante :

     kubectl config get-contexts
     kubectl config use-context CLUSTER_NAME
     

Initialiser la nouvelle autorité de certification

1. Les étapes requises pour initialiser la nouvelle autorité de certification dépendent de la nouvelle autorité de certification vers laquelle vous effectuez la migration. Effectuez ces étapes dans chaque cluster du parc vers lequel vous souhaitez migrer l'autorité de certification.

   Mesh CA

   Appelez la sous-commande initialize de l'utilitaire.

   Si vous spécifiez des configurations Kubernetes personnalisées :

    ./migrate_ca initialize --kubeconfig KUBECONFIG --kubecontext KUBECONTEXT --ca mesh_ca --old_ca OLD_CA_TYPE \
    --fleet_id FLEET_ID --revision ASM_REVISION
   

   Mais :

    ./migrate_ca initialize --ca mesh_ca --old_ca OLD_CA_TYPE \
    --fleet_id FLEET_ID --revision ASM_REVISION
    ```
   

   Service d'autorité de certification

   a. Suivez les étapes requises pour initialiser Certificate Authority Service. Notez la valeur de CA_POOL.

   b. Appelez la sous-commande initialize de l'utilitaire :

   Si vous spécifiez des configurations Kubernetes personnalisées :

    ./migrate_ca initialize --kubeconfig KUBECONFIG --context KUBECONTEXT --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
    --fleet-id FLEET_ID --revision ASM_REVISION
   

   Mais :

     ./migrate_ca initialize --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
     --fleet-id FLEET_ID --revision ASM_REVISION
   

Ajouter des trustAnchors à l'échelle du maillage pour tous les clusters du parc

1. Répétez les étapes ci-dessous pour l'ancienne et la nouvelle autorité de certification, pour tous les clusters faisant partie du parc.

2. Téléchargez les trustAnchors de l'autorité de certification :

   Mesh CA

   ./migrate_ca download-trust-anchor --ca mesh_ca --ca_cert ROOT_CERT.pem
   

   Service d'autorité de certification

   Stockez le certificat CA dans un fichier :

   gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pem
   

3. Ajoutez les trustAnchors de l'autorité de certification :

   ./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem
   

4. Vérifier que les trustAnchors ont bien été reçus par toutes les charges de travail du parc. Dans l'argument des espaces de noms, transmettez tous les espaces de noms dans lesquels les charges de travail sont déployées :

   ./migrate-ca check-trust-anchor --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   Résultat attendu :

   Check the CA cert in namespace nsa-1-24232
   a-v1-597f875788-52c5t.nsa-1-24232 trusts root-cert.pem
   

Migrer l'autorité de certification

1. Migrez la configuration de l'autorité de certification. La commande requise dépend de la nouvelle autorité de certification vers laquelle vous effectuez la migration.

   Mesh CA

   ./migrate_ca migrate-ca --ca mesh_ca
   

   Service d'autorité de certification

   ./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL
   

2. Redémarrez toutes les charges de travail.

   Remarque : Cette étape est facultative si vous avez installé le plan de données géré. En effet, Google gère les durées de vie des proxys et effectue automatiquement cette étape lors d'une mise à niveau gérée.

   Pour réduire le risque de temps d'arrêt du trafic TLS, cette étape doit d'abord affecter le plus petit nombre de charges de travail. Ne redémarrez que les charges de travail associées à la révision du plan de contrôle ASM_REVISION. Par exemple, si toutes les charges de travail de l'espace de noms Kubernetes NAMESPACE sont associées au même plan de contrôle Anthos Service Mesh.

   kubectl rollout restart deployment -n NAMESPACE
   

3. Vérifiez que les connexions mTLS fonctionnent entre les charges de travail de l'espace de noms redémarré et les autres charges de travail, avant de répéter les étapes 1 et 2 pour tous les espaces de noms et pour tous les clusters du parc. Si des charges de travail plus récentes arrivent et que le trafic du réseau maillé n'est pas interrompu, répétez les étapes 1 et 2 pour tous les espaces de noms et clusters qui font partie du parc. Sinon, effectuez un rollback pour restaurer la configuration d'autorité de certification la plus récente.

4. Vérifiez que la nouvelle configuration de l'autorité de certification est bien utilisée par toutes les charges de travail :

   ./migrate_ca verify-ca --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   Résultat attendu :

   Check the CA configuration in namespace nsb-2-76095
   b-v1-8ff557759-pds69.nsb-2-76095 is signed by root-cert.pem
   

Effectuer un rollback

1. Effectuez un rollback de la configuration de l'autorité de certification et supprimez les trustAnchors nouvellement configurés :

   ./migrate-ca rollback
   

2. Redémarrez toutes les charges de travail. Veillez à ne redémarrer que les charges de travail associées à la révision du plan de contrôle ASM_REVISION. Par exemple, si toutes les charges de travail de l'espace de noms Kubernetes NAMESPACES sont associées au même plan de contrôle Anthos Service Mesh.

   kubectl rollout restart deployment -n NAMESPACES
   

3. (Facultatif) Vérifiez que l'ancienne configuration de l'autorité de certification est bien utilisée par toutes les charges de travail.

   ./migrate-ca verify-ca --ca_cert older-root-cert.pem
   

4. Répétez les étapes 1 à 3 pour tous les clusters du parc où les charges de travail utilisent le plan de contrôle ASM_REVISION.

Félicitations ! Vous avez effectué une migration sur place de l'autorité de certification.