Cette page a été traduite par l'API Cloud Translation.

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

Autopilot Standard

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

Cette page décrit l'une des fonctionnalités facultatives du plan de contrôle dans GKE. Elle 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 À 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 :

Composants des identifiants du plan de contrôle

Les clusters GKE utilisent des CA 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 (CA Service), puis configurer vos clusters pour qu'ils utilisent ces ressources au lieu des clés et autorités de certification gérées par Google Cloud.

Pour en savoir plus sur les composants spécifiques que vous créez, consultez CA et clés autogérées.

Utilisation avec d'autres fonctionnalités de l'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 et clés (cette page)
Chiffrer les composants du plan de contrôle

Objectifs

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

Coûts

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

Pour obtenir une estimation des coûts en fonction de votre utilisation prévue, utilisez le 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

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.

Install the Google Cloud CLI.

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

If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

To initialize the gcloud CLI, run the following command:

gcloud init

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

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

Install the Google Cloud CLI.

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

If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

To initialize the gcloud CLI, run the following command:

gcloud init

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

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

Assurez-vous que votre environnement est éligible à l'utilisation des fonctionnalités de l'autorité du plan de contrôle GKE. Pour activer ces fonctionnalités, contactez votre équipe commerciale Google Cloud .
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 :
- API Cloud Key Management Service (KMS) : DATA_READ
- Certificate Authority Service : ADMIN_READ
Pour activer ces types de journaux, consultez 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 clés et CA, demandez à votre administrateur de vous accorder les rôles IAM suivants :

Créez des clés Cloud KMS : Administrateur Cloud KMS (roles/cloudkms.admin) dans votre projet de clés.
Créez des pools d'autorités de certification et des autorités de certification racines : Administrateur du service CA (roles/privateca.admin) sur votre projet clé
Créez 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 Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec 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 les autorités de certification du service CA.
Les régions et les zones dans lesquelles vous pouvez utiliser l'autorité du plan de contrôle GKE dépendent de votre souhait d'utiliser ou non des fonctionnalités spécifiques :
- Pour chiffrer les disques de démarrage de votre plan de contrôle avec une clé de chiffrement gérée par le client, votre cluster doit se trouver dans l'une des régions suivantes :
  - asia-east1
  - asia-northeast1
  - asia-southeast1
  - europe-west1
  - europe-west4
  - us-central1
  - us-east1
  - us-east4
  - us-east5
  - us-south1
  - us-west1
  - us-west3
  - us-west4
- Pour utiliser les nœuds Confidential GKE avec l'autorité du plan de contrôle GKE, votre cluster doit se trouver dans une région compatible avec le mode Confidentiel pour Hyperdisk équilibré.
Si vous n'utilisez pas ces fonctionnalités, vous pouvez utiliser l'autorité du plan de contrôle GKE dans n'importe quel emplacement Google Cloud .

Préparer l'environnement

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

Identifier des projets

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

Projet de clés : contient toutes les clés et les CA.
Projet de clusters : contient vos clusters GKE.

Vous pouvez éventuellement utiliser le même projet pour vos clés, vos CA et vos clusters GKE, mais nous vous recommandons d'utiliser des projets distincts afin que les équipes qui gèrent les opérations de chiffrement dans 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.

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'authentification, comme 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.

Lorsque vous créez ces ressources dans Cloud KMS, tenez compte des points suivants :

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 votre cluster.
Pour minimiser la latence, votre trousseau de clés doit se trouver au même emplacement que votre cluster. Google Cloud
Les clés doivent spécifier asymmetric-signing comme objectif de la clé.
Utilisez les algorithmes suivants en fonction du type de clé :
- Clés de signature de compte de service : un algorithme PKCS1 de signature RSA fort, comme rsa-sign-pkcs1-4096-sha256 ou rsa-sign-pkcs1-3072-sha256.
- Clés de l'autorité de certification : un algorithme puissant tel que ec-sign-p256-sha256.
Les clés matérielles Cloud HSM sont acceptées, mais le niveau de protection software suffit pour la plupart des cas d'utilisation. Pour en savoir plus sur les clés matérielles, consultez Cloud HSM.
Ne modifiez pas la durée par défaut avant destruction des clés.
GKE ne vous empêche pas de supprimer les clés Cloud KMS, y compris les clés de service de l'autorité de certification, qui sont utilisées par le cluster. Avant de supprimer des clés ou des CA, assurez-vous que les ressources ne sont pas utilisées.

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

Créez la clé de signature Kubernetes ServiceAccount, 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 du projet de clé dédié.

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

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

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

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é de certification et les autorités de certification racine correspondantes à l'aide de CA Service :

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. Si vous omettez ces indicateurs, les certificats sont publiés dans un bucket Cloud Storage. Pour en savoir plus, consultez Activer la publication des certificats CA et des LRC pour les autorités de certification d'un pool d'autorités de certification.

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.

Créez le pool d'autorités de certification des pairs 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

Créez l'autorité de certification racine des pairs 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

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

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

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

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

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

L'agent de service GKE doit avoir accès aux ressources que vous avez créées dans Cloud KMS et dans CA Service. 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 :

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 du projet de votre cluster.

Attribuez 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:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
  --role=roles/container.cloudKmsKeyUser \
  --project=KEY_PROJECT_ID

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

Accordez le rôle Gestionnaire de certificats CA Service sur les pools d'autorités de certification que vous avez créés dans Créer les autorités de certification :

gcloud privateca pools add-iam-policy-binding cluster-ca-pool \
    --location=us-central1 \
    --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
    --role=roles/privateca.certificateManager \
    --project=KEY_PROJECT_ID

gcloud privateca pools add-iam-policy-binding etcd-peer-ca-pool \
    --location=us-central1 \
    --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
    --role=roles/privateca.certificateManager \
    --project=KEY_PROJECT_ID

gcloud privateca pools add-iam-policy-binding etcd-api-ca-pool \
    --location=us-central1 \
    --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
    --role=roles/privateca.certificateManager \
    --project=KEY_PROJECT_ID

gcloud privateca pools add-iam-policy-binding aggregation-ca-pool \
    --location=us-central1 \
    --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
    --role=roles/privateca.certificateManager \
    --project=KEY_PROJECT_ID

Attribuer des rôles supplémentaires lorsque vous n'utilisez pas gcloud CLI

Cette section décrit les étapes de configuration supplémentaires que vous devez effectuer si vous prévoyez de configurer vos clés et CA à l'aide d'un client tel que Terraform ou la console Google Cloud au lieu d'utiliser gcloud CLI. Si vous utilisez gcloud CLI, ignorez cette section et passez à la section Configurer des certificats et des clés sur un nouveau cluster.

Lorsque vous utilisez gcloud CLI pour configurer vos clés et vos CA, comme décrit sur cette page, gcloud CLI crée et configure automatiquement un agent de service pour le service de CA, et accorde des rôles IAM à l'agent de service. Toutefois, si vous utilisez un client tel que Terraform ou la console Google Cloud pour configurer votre environnement Google Cloud, vous devez effectuer manuellement les étapes de configuration suivantes pour votre projet clé :

Déclenchez la création de l'agent de service CA Service.

Preview — triggering service agent creation

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les fonctionnalités de pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.
```
gcloud beta services identity create --service=privateca.googleapis.com \
    --project=KEY_PROJECT_ID
```

Trouvez le numéro de projet de votre projet clé :

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

Attribuez le rôle Lecteur (roles/viewer) et le rôle Signature/validation de clé de chiffrement Cloud KMS autorisées (roles/cloudkms.signerVerifier) à toutes les clés d'autorité de certification racine que vous avez créées dans la section Créer des clés :

for key in cluster-ca-key etcd-peer-ca-key etcd-api-ca-key aggregation-ca-key
do
gcloud kms keys add-iam-policy-binding $key \
    --keyring=KEY_RING_NAME \
    --location=LOCATION \
    --role=roles/viewer \
    --member="serviceAccount:service-KEY_PROJECT_NUMBER@gcp-sa-privateca.iam.gserviceaccount.com" \
    --project=KEY_PROJECT_ID

gcloud kms keys add-iam-policy-binding $key \
    --keyring=KEY_RING_NAME \
    --location=LOCATION \
    --role=roles/cloudkms.signerVerifier \
    --member="serviceAccount:service-KEY_PROJECT_NUMBER@gcp-sa-privateca.iam.gserviceaccount.com" \
    --project=KEY_PROJECT_ID
done

Remplacez KEY_PROJECT_NUMBER par le numéro du projet clé obtenu à l'étape précédente.

Cette commande est une boucle for qui parcourt les clés de l'autorité de certification racine, en accordant à chaque rôle sur cette clé l'agent de service CA Service. Si vous avez utilisé des noms différents pour les clés de l'autorité de certification racine, exécutez ces commandes manuellement pour chaque clé.

Configurer des CA et des clés sur un nouveau cluster

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

Les indicateurs que vous spécifiez dans la commande de création de cluster nécessitent les chemins d'accès aux 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 d'accès pour l'option service-account-signing-keys et pour l'option service-account-verification-keys.
Chemin d'accès à chacun des pools d'autorités de certification que vous avez créés dans Créer les autorités de certification.

Pour configurer un nouveau cluster afin qu'il utilise vos clés et vos CA, procédez comme suit :

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

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 de 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

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 le résultat 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 configurer uniquement les certificats et les clés que vous avez créés 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 de GKE du cluster. Doit être 1.31.1-gke.1846000 ou une version ultérieure.

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

Suivez toutes les étapes de configuration des clés décrites dans Chiffrer les disques de démarrage etcd et du plan de contrôle.
Trouvez 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.

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 de cluster.
VERSION : version de 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 interne de sauvegarde etcd.

Vous pouvez également utiliser ces indicateurs lorsque vous créez un cluster en mode Standard.

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

Cette section explique comment vérifier les clés et les CA qui ont été utilisés 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 vérifier les clés et les CA

Pour valider les clés et les CA à l'aide de Logging, procédez comme suit :

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

Accéder à l'explorateur de journaux

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 cluster qui incluent les clés et les autorités de certification que vous gérez.

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 CA 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 la gcloud CLI pour vérifier les clés et les CA

Pour vérifier que le cluster utilise les clés et les certificats que vous avez créés, 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 aura les effets suivants :

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

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

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

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

Supprimez les autorités de certification racines :

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

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

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 trousseaux de clés de Cloud KMS. Toutefois, les trousseaux de clés n'entraînent pas de frais supplémentaires.

Étapes suivantes

Suivre l'utilisation des identités dès leur émission
Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Cloud Architecture Center.

Exécuter vos propres autorités de certification et clés dans GKE Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Composants des identifiants du plan de contrôle

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

Objectifs

Coûts

Avant de commencer

Rôles et autorisations requis

Conditions requises

Limites

Préparer l'environnement

Identifier des projets

Créer un trousseau de clés

Créer des clés

Créer les autorités de certification

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

Attribuer des rôles supplémentaires lorsque vous n'utilisez pas gcloud CLI

Configurer des CA et des clés sur un nouveau cluster

Créer un cluster

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

Utiliser la journalisation pour vérifier les clés et les CA

Utiliser la gcloud CLI pour vérifier les clés et les CA

Effectuer un nettoyage

Supprimer les projets

Supprimer des ressources individuelles

Étapes suivantes

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