Exécuter vos propres autorités de certification et clés dans GKE

Autopilot Standard

---

Remarque:Ce document utilise une fonctionnalité de disponibilité générale appelée autorité du plan de contrôle GKE, qui n'est disponible que pour les clients Google Cloudeligibles. Pour demander l'accès à cette fonctionnalité, contactez l'équipe chargée de votre compte Google Cloud .

Cette page vous explique comment configurer le plan de contrôle de votre cluster Google Kubernetes Engine (GKE) avec les autorités de certification (autorités CA) et les clés que vous gérez. Ces conseils sont destinés aux administrateurs de sécurité qui ont des exigences de conformité ou de règles organisationnelles spécifiques pour contrôler l'émission et la signature des identifiants.

Cette page décrit une partie d'un ensemble de fonctionnalités facultatives du plan de contrôle dans GKE qui vous permet d'effectuer des tâches telles que la vérification de la stratégie de sécurité de votre plan de contrôle ou la configuration du chiffrement et de la signature des identifiants dans le plan de contrôle à l'aide de clés que vous gérez. Pour en savoir plus, consultez la section À propos de l'autorité du plan de contrôle GKE.

Par défaut, Google Cloud applique diverses mesures de sécurité au plan de contrôle géré. Cette page décrit les fonctionnalités facultatives qui vous offrent une meilleure visibilité ou un meilleur contrôle sur le plan de contrôle GKE.

Vous devez déjà connaître les concepts suivants:

• Demandes de signature de certificat (CSR)
• Autorités de certification (AC)
• etcd
• Architecture du cluster GKE

Composants d'identifiants du plan de contrôle

Les clusters GKE utilisent des autorités de certification et des clés spécifiques pour émettre des identifiants dans le cluster, comme des certificats X.509 ou des jetons ServiceAccount. Vous pouvez créer des clés dans Cloud Key Management Service (Cloud KMS) et des autorités de certification dans Certificate Authority Service (Service d'autorité de certification) et configurer vos clusters pour qu'ils utilisent ces ressources au lieu des clés et des autorités de certification gérées par Google Cloud.

Pour en savoir plus sur les composants spécifiques que vous créez, consultez la section Autorités de certification et clés autogérées.

Utilisation avec d'autres fonctionnalités d'autorité du plan de contrôle GKE

L'autorité du plan de contrôle GKE fournit les fonctionnalités suivantes liées aux clés autogérées:

• Exécuter vos propres autorités de certification (AC) et clés (cette page)
• Chiffrer les composants du plan de contrôle

Remarque :Vous ne pouvez activer ces fonctionnalités que lorsque vous créez un cluster GKE. Vous ne pouvez pas mettre à jour les clusters existants pour utiliser ces fonctionnalités. Pour utiliser ces deux fonctionnalités dans le même cluster, effectuez toutes les procédures de configuration des clés et des autorités de certification dans les deux guides, puis exécutez la commande de création de cluster qui active les deux ensembles de fonctionnalités, comme décrit dans la section Créer un cluster.

Objectifs

• Créer des clés dans Cloud KMS
• Créer des autorités de certification dans le service CA
• Attribuer des rôles IAM (Identity and Access Management) à l'agent de service GKE
• Créer un cluster GKE qui utilise vos autorités de certification et vos clés
• Vérifier que le cluster utilise vos autorités de certification et vos clés

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

• GKE
• Cloud KMS
• CA Service
• Cloud Logging

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
2. Install the Google Cloud CLI.

3. To initialize the gcloud CLI, run the following command:

   gcloud init

   Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.

4. Make sure that billing is enabled for your Google Cloud project.

5. Enable the Kubernetes Engine, Certificate Authority Service, and Cloud Key Management Service APIs:

   gcloud services enable container.googleapis.com privateca.googleapis.com cloudkms.googleapis.com

6. Install the Google Cloud CLI.

7. To initialize the gcloud CLI, run the following command:

   gcloud init

   Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.

8. Make sure that billing is enabled for your Google Cloud project.

9. Enable the Kubernetes Engine, Certificate Authority Service, and Cloud Key Management Service APIs:

   gcloud services enable container.googleapis.com privateca.googleapis.com cloudkms.googleapis.com

10. Assurez-vous que votre environnement est éligible à l'utilisation des fonctionnalités d'autorité du plan de contrôle GKE. Pour activer ces fonctionnalités, contactez votre équipe commerciale Google Cloud .
11. Pour suivre de manière fiable l'émission et l'utilisation des identifiants, assurez-vous que les journaux d'audit des accès aux données suivants sont activés :
    • Cloud KMS: DATA_READ
    • Service d'autorité de certification: ADMIN_READ et ADMIN_WRITE

    Pour activer ces types de journaux, consultez la page Activer les journaux d'audit des accès aux données.

Rôles et autorisations requis

Pour obtenir les autorisations nécessaires pour exécuter vos propres autorités de certification et clés, demandez à votre administrateur de vous accorder les rôles IAM suivants:

• Créez des clés Cloud KMS : Administrateur Cloud KMS (roles/cloudkms.admin) sur votre projet de clé.
• Créez des pools d'autorités de certification et des autorités de certification racine : Administrateur du service d'autorité de certification (roles/privateca.admin) sur votre projet clé.
• Créer des clusters GKE : Administrateur de cluster Kubernetes Engine (roles/container.clusterAdmin) sur votre projet de cluster

Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Conditions requises

Vous devez utiliser GKE version 1.31.1-gke.1846000 ou ultérieure.

Limites

Les limites suivantes s'appliquent :

• Vous ne pouvez utiliser que des clés Cloud KMS. Vous ne pouvez pas utiliser d'autre fournisseur KMS ni d'autre fournisseur de chiffrement.
• Les clés Cloud External Key Manager (Cloud EKM) ne sont pas acceptées.
• Vous ne pouvez utiliser que des autorités de certification du service CA.

Préparer l'environnement

Dans cette section, vous identifiez les projets Google Cloud que vous utiliserez dans ce tutoriel, et vous créez un trousseau de clés dans Cloud KMS pour y stocker vos clés.

Identifier des projets

Nous vous recommandons d'utiliser des projets Google Cloud distincts comme suit:

• Projet de clé: contient toutes les clés et les autorités de certification.
• Projet de clusters: contient vos clusters GKE.

Vous pouvez utiliser le même projet pour vos clés, vos autorités de certification et vos clusters GKE, mais nous vous recommandons d'utiliser des projets distincts afin que les équipes qui gèrent les opérations cryptographiques de votre organisation soient séparées de celles qui gèrent les opérations de cluster.

Créer un trousseau de clés

Créez un trousseau de clés dans le projet de clé pour contenir toutes les clés d'un cluster spécifique. Vous devez créer le trousseau de clés au même emplacement que votre cluster GKE.

Remarque :Vous ne pouvez pas supprimer un trousseau de clés après l'avoir créé. Les trousseaux de clés n'entraînent pas de coûts supplémentaires. Toutefois, un trop grand nombre de trousseaux de clés dans un projet peut rendre la gestion de vos ressources dans Cloud KMS plus fastidieuse.

Exécutez la commande suivante :

gcloud kms keyrings create KEY_RING_NAME \
    --location=us-central1 \
    --project=KEY_PROJECT_ID

Remplacez les éléments suivants :

• KEY_RING_NAME: nom de votre trousseau de clés.
• KEY_PROJECT_ID: ID de votre projet de clé.

Créer des clés

Pour chacune des autorités d'identification, telles que les clés de compte de service et les autorités de certification, vous créez une clé à l'aide de Cloud KMS. Cette section explique comment créer les clés que GKE utilise pour signer et valider les identifiants dans le cluster. Vous pouvez spécifier vos propres propriétés pour ces clés en fonction des besoins de votre organisation. Pour en savoir plus, consultez la page Créer une clé et la documentation de référence de l'API projects.locations.keyRings.cryptoKeys.

Attention :N'activez pas la rotation automatique des clés avec Cloud KMS. La rotation de vos clés de chiffrement nécessite des étapes supplémentaires pour vous assurer que vos ressources de plan de contrôle sont rechiffrées avec de nouvelles versions de clé avant que les versions de clé d'origine ne soient détruites.

Tenez compte des points suivants lorsque vous créez ces ressources dans Cloud KMS:

• Si vous disposez d'un trousseau de clés existant dans votre projet de clé, vous pouvez l'utiliser pour stocker toutes les clés que vous créez pour les utiliser avec votre cluster.
• Votre trousseau de clés doit se trouver dans le même Google Cloud emplacement que votre cluster pour minimiser la latence.
• Les clés doivent spécifier asymmetric-signing comme objectif.
• Utilisez les algorithmes suivants en fonction du type de clé :
  • Clés de signature du compte de service: algorithme PKCS1 de signature RSA sécurisé, comme rsa-sign-pkcs1-4096-sha256 ou rsa-sign-pkcs1-3072-sha256.
  • Clés d'autorité de certification: algorithme sécurisé comme ec-sign-p256-sha256.
• Les clés matérielles Cloud HSM sont compatibles, mais le niveau de protection software est suffisant pour la plupart des cas d'utilisation. Pour en savoir plus sur les clés matérielles, consultez la section Cloud HSM.
• Ne modifiez pas la durée par défaut de destruction des clés.
• GKE ne vous empêche pas de supprimer les clés Cloud KMS, y compris les clés de service d'autorité de certification, utilisées par le cluster. Avant de supprimer des clés ou des autorités de certification, assurez-vous que les ressources ne sont pas utilisées.

Pour créer vos clés, exécutez les commandes suivantes:

1. Créez la clé de signature du ServiceAccount Kubernetes, que vous spécifiez également comme clé de validation du compte de service lors de la création du cluster:

   gcloud kms keys create sa-signing-key \
       --keyring=KEY_RING_NAME \
       --location=us-central1\
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=rsa-sign-pkcs1-4096-sha256 \
       --project=KEY_PROJECT_ID
   

   Remplacez KEY_PROJECT_ID par l'ID de votre projet de clé dédié.

2. Créez la clé de l'autorité de certification racine du cluster:

   gcloud kms keys create cluster-ca-key \
       --keyring=KEY_RING_NAME \
       --location=us-central1\
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=ec-sign-p256-sha256 \
       --project=KEY_PROJECT_ID
   

3. Créez la clé de l'autorité de certification racine du pair etcd:

   gcloud kms keys create etcd-peer-ca-key \
       --keyring=KEY_RING_NAME \
       --location=us-central1\
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=ec-sign-p256-sha256 \
       --project=KEY_PROJECT_ID
   

4. Créez la clé de l'autorité de certification racine de l'API etcd:

   gcloud kms keys create etcd-api-ca-key \
       --keyring=KEY_RING_NAME \
       --location=us-central1\
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=ec-sign-p256-sha256 \
       --project=KEY_PROJECT_ID
   

5. Créez la clé de l'autorité de certification racine d'agrégation:

   gcloud kms keys create aggregation-ca-key \
       --keyring=KEY_RING_NAME \
       --location=us-central1\
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=ec-sign-p256-sha256 \
       --project=KEY_PROJECT_ID
   

Créer les autorités de certification

Après avoir créé les clés pour chacune des fonctions du plan de contrôle, utilisez chaque clé pour créer les pools d'autorités de certification et les autorités de certification racine correspondantes à l'aide de CA Service:

1. Créez le pool d'autorités de certification du cluster:

   gcloud privateca pools create cluster-ca-pool \
       --location=us-central1 \
       --tier=enterprise \
       --project=KEY_PROJECT_ID \
       --no-publish-crl --no-publish-ca-cert
   

   Les options --no-publish-crl et --no-publish-ca-cert sont facultatives. L'omission de ces indicateurs permet de publier des certificats dans un bucket Cloud Storage. Pour en savoir plus, consultez la section Activer la publication du certificat CA et de la LRC pour les autorités de certification d'un pool d'autorités de certification.

2. Créez l'autorité de certification racine du cluster:

   gcloud privateca roots create cluster-root-ca \
       --pool=cluster-ca-pool \
       --location=us-central1 \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/cluster-ca-key/cryptoKeyVersions/1 \
       --subject="CN=cluster-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID \
       --auto-enable
   

   Remplacez ORGANIZATION par le nom de votre organisation.

3. Créez le pool d'autorités de certification de paires etcd:

   gcloud privateca pools create etcd-peer-ca-pool \
       --location=us-central1 \
       --tier=enterprise \
       --project=KEY_PROJECT_ID \
       --no-publish-crl --no-publish-ca-cert
   

4. Créez l'autorité de certification racine du pair etcd:

   gcloud privateca roots create etcd-peer-root-ca \
       --pool=etcd-peer-ca-pool \
       --location=us-central1 \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/etcd-peer-ca-key/cryptoKeyVersions/1 \
       --subject="CN=etcd-peer-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID \
       --auto-enable
   

5. Créez le pool d'autorités de certification de l'API etcd:

   gcloud privateca pools create etcd-api-ca-pool \
       --location=us-central1 \
       --tier=enterprise \
       --project=KEY_PROJECT_ID \
       --no-publish-crl --no-publish-ca-cert
   

6. Créez l'autorité de certification racine de l'API etcd:

   gcloud privateca roots create etcd-api-root-ca \
       --pool=etcd-api-ca-pool \
       --location=us-central1 \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/etcd-api-ca-key/cryptoKeyVersions/1 \
       --subject="CN=etcd-api-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID \
       --auto-enable
   

7. Créez le pool d'autorités de certification d'agrégation:

   gcloud privateca pools create aggregation-ca-pool \
       --location=us-central1 \
       --tier=enterprise \
       --project=KEY_PROJECT_ID \
       --no-publish-crl --no-publish-ca-cert
   

8. Créez l'autorité de certification racine d'agrégation:

   gcloud privateca roots create aggregation-root-ca \
       --pool=aggregation-ca-pool \
       --location=us-central1 \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/aggregation-ca-key/cryptoKeyVersions/1 \
       --subject="CN=aggregation-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID \
       --auto-enable
   

Accorder des rôles IAM à l'agent de service GKE

L'agent de service GKE nécessite un accès aux ressources que vous avez créées dans Cloud KMS et dans le service d'autorité de certification. L'agent de service utilise ces ressources pour signer, valider et émettre des identifiants dans le cluster. Vous pouvez utiliser les rôles IAM prédéfinis suivants:

• Utilisateur de clé cryptographique du service de gestion des clés Kubernetes Engine (roles/container.cloudKmsKeyUser)
• Gestionnaire de certificats du service CA (roles/privateca.certificateManager)

Pour accorder ces rôles à l'agent de service GKE, procédez comme suit:

1. Recherchez le numéro de projet de votre projet de cluster:

   gcloud projects describe CLUSTER_PROJECT_ID \
       --format='value(projectNumber)'
   

   Remplacez CLUSTER_PROJECT_ID par l'ID de votre projet de cluster.

2. Accordez le rôle Utilisateur de clé cryptographique KMS Kubernetes Engine à la clé de signature du compte de service que vous avez créée dans Créer des clés:

   gcloud kms keys add-iam-policy-binding sa-signing-key \
     --location=us-central1 \
     --keyring=KEY_RING_NAME \
     --member="serviceAccount:[e-mail]" \
     --role=roles/container.cloudKmsKeyUser \
     --project=KEY_PROJECT_ID
   

   Remplacez CLUSTER_PROJECT_NUMBER par le numéro du projet de cluster.

3. Accordez le rôle "Gestionnaire de certificats CA Service" aux pools d'autorités de certification que vous avez créés dans la section Créer les autorités de certification:

   gcloud privateca pools add-iam-policy-binding cluster-ca-pool \
       --location=us-central1 \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools add-iam-policy-binding etcd-peer-ca-pool \
       --location=us-central1 \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools add-iam-policy-binding etcd-api-ca-pool \
       --location=us-central1 \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools add-iam-policy-binding aggregation-ca-pool \
       --location=us-central1 \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   

Configurer des autorités de certification et des clés sur un nouveau cluster

Avertissement :La suppression de clés ou d'autorités de certification utilisées par le cluster peut entraîner des clusters irrécupérables. Avant de supprimer des clés ou des autorités de certification, assurez-vous que votre cluster n'utilise plus les ressources.

Après avoir créé des clés, des pools d'autorités de certification, des autorités de certification racine et accordé des rôles IAM à l'agent de service GKE, créez un cluster qui utilise ces ressources.

Les options que vous spécifiez dans la commande de création de cluster nécessitent les chemins de ressources suivants comme valeurs:

• Chemin d'accès à une version de clé dans Cloud KMS pour la clé de signature du compte de service que vous avez créée dans Créer des clés. Vous spécifiez ce chemin pour l'indicateur service-account-signing-keys et l'indicateur service-account-verification-keys.
• Chemin d'accès à chacun des pools d'autorités de certification que vous avez créés dans la section Créer les autorités de certification.

Remarque :Avant de suivre ces étapes, décidez si vous souhaitez également chiffrer les disques de démarrage du plan de contrôle et les disques etcd avec des clés que vous gérez. Si vous le faites, suivez toutes les étapes de configuration clés de la section Chiffrer les disques de démarrage d'etcd et du plan de contrôle, puis spécifiez les options facultatives décrites dans la commande de création de cluster de cette section.

Pour configurer un nouveau cluster pour qu'il utilise vos clés et autorités de certification, procédez comme suit:

1. Recherchez le chemin d'accès à la dernière version de la clé de signature du compte de service activée:

   gcloud kms keys versions list \
       --key=sa-signing-key \
       --keyring=KEY_RING_NAME \
       --location=us-central1 \
       --project=KEY_PROJECT_ID \
       --filter="STATE=ENABLED" --sort-by=~ --format="value(name)" | sed 1q
   

   Remplacez KEY_PROJECT_ID par l'ID du projet clé.

   Le résultat ressemble à ce qui suit :

   projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
   

2. Recherchez les chemins d'accès à chacun des pools d'autorités de certification que vous avez créés:

   gcloud privateca pools list --format="get(name)" \
       --project=KEY_PROJECT_ID
   

   Le résultat ressemble à ce qui suit :

   projects/KEY_PROJECT_ID/locations/us-central1/caPools/cluster-ca-pool
   projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-peer-ca-pool
   projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-api-ca-pool
   projects/KEY_PROJECT_ID/locations/us-central1/caPools/aggregation-ca-pool
   

   Assurez-vous que la sortie contient tous les pools d'autorités de certification que vous avez créés pour GKE.

Créer un cluster

Dans cette section, vous allez créer un cluster avec différentes options spécifiées en fonction des fonctionnalités d'autorité du plan de contrôle GKE que vous souhaitez configurer. Vous ne pouvez configurer ces fonctionnalités sur un cluster que lors de sa création. Les commandes suivantes créent des clusters en mode Autopilot. Pour créer des clusters en mode standard, utilisez les mêmes options avec la commande gcloud container clusters create.

• Pour ne configurer que les autorités de certification et les clés que vous avez créées dans ce tutoriel, exécutez la commande suivante:

  gcloud container clusters create-auto example-cluster \
      --location=us-central1 \
      --project=CLUSTER_PROJECT_ID \
      --cluster-version=VERSION \
      --service-account-signing-keys=projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
      --service-account-verification-keys=projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
      --cluster-ca=projects/KEY_PROJECT_ID/locations/us-central1/caPools/cluster-ca-pool \
      --etcd-peer-ca=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-peer-ca-pool \
      --etcd-api-ca=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-api-ca-pool \
      --aggregation-ca=projects/KEY_PROJECT_ID/locations/us-central1/caPools/aggregation-ca-pool
  

  Remplacez les éléments suivants :

  • CLUSTER_PROJECT_ID: ID de projet du projet de cluster.
  • VERSION: version GKE du cluster. Doit être 1.31.1-gke.1846000 ou une version ultérieure.

• Pour configurer les autorités de certification et les clés, ainsi que le chiffrement du disque de démarrage du plan de contrôle et le chiffrement d'etcd, procédez comme suit:

  1. Suivez toutes les étapes de configuration clés dans la section Chiffrer les disques de démarrage d'etcd et du plan de contrôle.
  2. Recherchez les chemins d'accès à chacune des clés en suivant les instructions de la section Utiliser des clés de chiffrement dans un cluster.

  3. Créez un cluster :

     gcloud container clusters create-auto example-cluster \
         --location=us-central1 \
         --project=CLUSTER_PROJECT_ID \
         --cluster-version=VERSION \
         --service-account-signing-keys=projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
         --service-account-verification-keys=projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
         --cluster-ca=projects/KEY_PROJECT_ID/locations/us-central1/caPools/cluster-ca-pool \
         --etcd-peer-ca=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-peer-ca-pool \
         --etcd-api-ca=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-api-ca-pool \
         --aggregation-ca=projects/KEY_PROJECT_ID/locations/us-central1/caPools/aggregation-ca-pool \
         --control-plane-disk-encryption-key=PATH_TO_DISK_KEY \
         --gkeops-etcd-backup-encryption-key=PATH_TO_ETCD_BACKUP_KEY
     

     Remplacez les éléments suivants :

     • CLUSTER_PROJECT_ID: ID du projet du cluster.
     • VERSION: version GKE du cluster. Doit être 1.31.1-gke.1846000 ou une version ultérieure.
     • PATH_TO_DISK_KEY: chemin d'accès à votre clé de chiffrement de disque.
     • PATH_TO_ETCD_BACKUP_KEY: chemin d'accès à votre clé de chiffrement de sauvegarde interne etcd.

  Vous pouvez également utiliser ces options lorsque vous créez un cluster en mode standard.

Vérifier que le cluster utilise les clés et les autorités de certification que vous avez spécifiées

Cette section explique comment vérifier les clés et les autorités de certification utilisées lors de la création du cluster. Vous pouvez effectuer cette vérification à l'aide de Cloud Logging ou de Google Cloud CLI.

Utiliser la journalisation pour valider les clés et les autorités de certification

Pour vérifier les clés et les autorités de certification à l'aide de Logging, procédez comme suit:

1. Dans la console Google Cloud , accédez à la page Explorateur de journaux:

   Accéder à l'explorateur de journaux

2. Spécifiez la requête suivante:

   resource.type="gke_cluster"
   resource.labels.cluster_name="CLUSTER_NAME"
   resource.labels.location="CLUSTER_LOCATION"
   protoPayload.serviceName="container.googleapis.com"
   protoPayload.methodName=~"google.container.v(1|1alpha1|1beta1).ClusterManager.CreateCluster"
   protoPayload.request.cluster.userManagedKeysConfig:*
   

   protoPayload.request.cluster.userManagedKeysConfig:* filtre les résultats des journaux de création de clusters qui incluent les clés et les autorités de certification que vous gérez.

3. Cliquez sur Exécuter la requête.

Dans les résultats, développez le journal de création de votre cluster. Vérifiez que les chemins d'accès aux clés et aux autorités de certification sont les mêmes que ceux que vous avez créés pour ce cluster, comme dans l'exemple suivant:

# lines omitted for clarity
userManagedKeysConfig: {
  aggregationCa: "projects/KEY_PROJECT_ID/locations/us-central1/caPools/aggregation-ca-pool"
  clusterCa: "projects/KEY_PROJECT_ID/locations/us-central1/caPools/cluster-ca-pool"
  etcdApiCa: "projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-api-ca-pool"
  etcdPeerCa: "projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-peer-ca-pool"
  serviceAccountSigningKeys: [
    0: "projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1"
  ]
  serviceAccountVerificationKeys: [
    0: "projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1"
  ]
}

Utiliser gcloud CLI pour valider les clés et les autorités de certification

Pour vérifier que le cluster utilise les autorités de certification et les clés que vous avez créées, exécutez la commande suivante:

gcloud container clusters describe example-cluster \
    --location=us-central1 \
    --project=CLUSTER_PROJECT_ID

Le résultat doit inclure le champ userManagedKeysConfig comme dans l'exemple suivant:

# lines omitted for clarity
userManagedKeysConfig:
  sa-signing-key: projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
  sa-verification-key: projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
  cluster-ca: projects/KEY_PROJECT_ID/locations/us-central1/caPools/cluster-ca-pool
  etcd-peer-ca: projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-peer-ca-pool
  etcd-api-ca: projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-api-ca-pool
  aggregation-ca: projects/KEY_PROJECT_ID/locations/us-central1/caPools/aggregation-ca-pool

Effectuer un nettoyage

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Supprimer les projets

Attention : La suppression d'un projet entraîne les effets décrits ci-dessous :

• Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
• Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Supprimer des ressources individuelles

1. Supprimez le cluster à l'aide de la commande suivante :

   gcloud container clusters delete example-cluster \
       --location=us-central1 \
       --project=CLUSTER_PROJECT_ID
   

2. Désactivez les autorités de certification racine:

   gcloud privateca roots disable cluster-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/cluster-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots disable etcd-peer-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-peer-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots disable etcd-api-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-api-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots disable aggregation-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/aggregation-ca-pool \
       --project=KEY_PROJECT_ID
   

3. Supprimez les autorités de certification racine:

   gcloud privateca roots delete cluster-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/cluster-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots delete etcd-peer-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-peer-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots delete etcd-api-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-api-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots delete aggregation-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/aggregation-ca-pool \
       --project=KEY_PROJECT_ID
   

4. Supprimez les pools d'autorités de certification:

   gcloud privateca pools delete cluster-ca-pool --location=us-central1 \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools delete etcd-peer-ca-pool --location=us-central1 \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools delete etcd-api-ca-pool --location=us-central1 \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools delete aggregation-ca-pool --location=us-central1 \
       --project=KEY_PROJECT_ID
   

5. Supprimez les clés:

   gcloud kms keys versions destroy 1 \
       --location=us-central1 \
       --keyring=KEY_RING_NAME \
       --key=sa-signing-key \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys versions destroy 1 \
       --location=us-central1 \
       --keyring=KEY_RING_NAME \
       --key=cluster-ca-key \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys versions destroy 1 \
       --location=us-central1 \
       --keyring=KEY_RING_NAME \
       --key=etcd-peer-ca-key \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys versions destroy 1 \
       --location=us-central1 \
       --keyring=KEY_RING_NAME \
       --key=etcd-api-ca-key \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys versions destroy 1 \
       --location=us-central1 \
       --keyring=KEY_RING_NAME \
       --key=aggregation-ca-key \
       --project=KEY_PROJECT_ID
   

Vous ne pouvez pas supprimer de trousseaus de clés de Cloud KMS. Toutefois, les trousseaux de clés n'entraînent pas de coûts supplémentaires.

Étape suivante

• Suivre l'utilisation de l'identité à partir du moment de son émission
• Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Cloud Architecture Center.