Authentification de cluster Workload Identity

Preview

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

Ce document explique comment configurer et utiliser l'authentification de cluster Workload Identity pour Google Distributed Cloud (logiciel uniquement) sur Bare Metal. Au lieu de clés de compte de service, l'authentification de cluster Workload Identity utilise des jetons de courte durée et la fédération d'identité de charge de travail pour créer et sécuriser vos clusters. Les identifiants éphémères du compte de service sont sous la forme de jetons d'accès OAuth 2.0. Par défaut, les jetons d'accès expirent au bout d'une heure, à l'exception des jetons de récupération d'images, qui expirent au bout de 12 heures.

Remarque :Au départ, nous avons appelé la fonctionnalité Authentification de cluster par identité de charge de travail Clusters sans clé, ce qui ne décrivait pas précisément l'objectif de la fonctionnalité ni son fonctionnement.

L'authentification de cluster Workload Identity n'est disponible que pour les clusters de la version 1.30 et ultérieure.

En revanche, le mode avec clé, qui est la méthode standard pour créer et sécuriser des clusters, utilise les clés de compte de service téléchargées. Lorsque vous créez un cluster autogéré (administrateur, hybride ou autonome), vous spécifiez le chemin d'accès aux clés téléchargées. Les clés sont ensuite stockées en tant que secrets dans le cluster et dans tous les clusters utilisateur gérés. Par défaut, les clés de compte de service ne sont pas soumises à une date d'expiration et constituent un risque pour la sécurité si elles ne sont pas gérées correctement.

L'authentification de cluster Workload Identity présente deux avantages principaux par rapport à l'utilisation de clés de compte de service:

• Sécurité améliorée: les clés de compte de service constituent un risque pour la sécurité si elles ne sont pas gérées correctement. Les jetons OAuth 2.0 et la fédération d'identité de charge de travail sont considérés comme des bonnes alternatives aux clés de compte de service. Pour en savoir plus sur les jetons de compte de service, consultez Identifiants de compte de service à court terme. Pour en savoir plus sur la fédération d'identité de charge de travail, consultez Fédération d'identité de charge de travail.

• Maintenance réduite: les clés de compte de service nécessitent plus de maintenance. La rotation et la sécurisation régulières de ces clés peuvent représenter un fardeau administratif important.

Bien que cette fonctionnalité soit en version preview, elle présente certaines limites.

Avant de commencer

Dans les sections suivantes, vous allez créer des comptes de service et accorder les rôles nécessaires pour l'authentification de cluster Workload Identity. Les instructions de configuration de ce document ne remplacent pas celles de la section Configurer des ressources . Elles sont requises en plus des conditions préalables standards d'installation logicielle uniquement de Google Distributed Cloud. Les comptes de service requis pour l'authentification de cluster Workload Identity sont semblables aux comptes de service décrits dans Configurer Google Cloud des ressources, mais ils ont un nom unique. Ils n'interfèrent donc pas avec les clusters qui utilisent les clés de compte de service par défaut.

Cette page s'adresse aux administrateurs, aux architectes et aux opérateurs qui configurent, surveillent et gèrent le cycle de vie de l'infrastructure technologique sous-jacente. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenuGoogle Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Le tableau suivant décrit les comptes de service requis pour l'authentification de cluster Workload Identity:

Compte de service	Objectif	Rôles
ADMIN_SA	Vous utiliserez ce compte de service pour générer des jetons. Chaque jeton dispose des droits associés aux rôles du compte de service.	roles/gkehub.admin roles/logging.admin roles/monitoring.admin roles/monitoring.dashboardEditor roles/iam.serviceAccountAdmin roles/iam.serviceAccountTokenCreator
baremetal-controller	L'agent Connect utilise ce compte de service pour maintenir une connexion entre votre cluster et Google Cloud , et pour enregistrer vos clusters auprès d' un parc. Ce compte de service actualise également les jetons pour le compte de service baremetal-gcr.	roles/gkehub.admin roles/monitoring.dashboardEditor roles/serviceusage.serviceUsageViewer
baremetal-cloud-ops	L'agent Stackdriver utilise ce compte de service pour exporter les journaux et les métriques des clusters vers Cloud Logging et Cloud Monitoring. Vous ne pouvez pas désactiver Cloud Logging et Cloud Monitoring pour vos clusters. Ce compte de service et tous les rôles listés pour ce compte de service sont obligatoires.	roles/logging.logWriter roles/monitoring.metricWriter roles/stackdriver.resourceMetadata.writer roles/opsconfigmonitoring.resourceMetadata.writer roles/monitoring.dashboardEditor roles/monitoring.viewer roles/serviceusage.serviceUsageViewer roles/kubernetesmetadata.publisher
baremetal-gcr	Google Distributed Cloud utilise ce compte de service pour télécharger des images de conteneurs à partir de Container Registry	Aucun

Créer et configurer des comptes de service pour l'authentification de cluster Workload Identity

Les sections suivantes contiennent des instructions pour créer les comptes de service requis et leur attribuer les rôles nécessaires pour l'authentification de cluster Workload Identity. Pour obtenir la liste des comptes de service et des rôles requis, consultez le tableau de la section précédente.

Créer des comptes de service

Pour créer les comptes de service pour l'authentification de cluster Workload Identity, procédez comme suit:

1. Sur votre poste de travail administrateur, connectez-vous à Google Cloud CLI:

   gcloud auth login
   

2. Vous pouvez également créer le compte de service administratif:

   Le nom du compte de service ADMIN_SA est arbitraire. Vous pouvez même utiliser un compte de service existant, s'il dispose des rôles identifiés dans le tableau de la section précédente, mais cela n'est pas recommandé, car cela va à l'encontre du principe du moindre privilège.

   gcloud iam service-accounts create ADMIN_SA \
       --project=PROJECT_ID
   

   Remplacez PROJECT_ID par l'ID de votre projetGoogle Cloud .

3. Créez les comptes de service standards pour l'authentification de cluster Workload Identity:

   Les comptes de service standards pour l'authentification de cluster Workload Identity ont des noms prédéterminés qui peuvent être personnalisés, si vous le souhaitez.

   gcloud iam service-accounts create baremetal-controller \
       --project=PROJECT_ID
   
   gcloud iam service-accounts create baremetal-cloud-ops \
       --project=PROJECT_ID
   
   gcloud iam service-accounts create baremetal-gcr \
       --project=PROJECT_ID
   

   Remplacez PROJECT_ID par l'ID de votre projetGoogle Cloud .

Ajouter des liaisons de stratégie Identity and Access Management pour les comptes de service

1. Ajoutez des liaisons de stratégie IAM pour les rôles requis pour le compte de service ADMIN_SA:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:ADMIN_SA@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/gkehub.admin
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:ADMIN_SA@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/logging.admin
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:ADMIN_SA@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/monitoring.admin
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:ADMIN_SA@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/monitoring.dashboardEditor
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:ADMIN_SA@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.serviceAccountAdmin
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:ADMIN_SA@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.serviceAccountTokenCreator
   

2. Ajoutez des liaisons de stratégie IAM pour les rôles requis pour le compte de service baremetal-controller:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:baremetal-controller@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/gkehub.admin
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:baremetal-controller@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/monitoring.dashboardEditor
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:baremetal-controller@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/serviceusage.serviceUsageViewer
   

3. Ajoutez des liaisons de stratégie IAM pour les rôles requis pour le compte de service baremetal-cloud-ops:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/logging.logWriter
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/monitoring.dashboardEditor
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/monitoring.metricWriter
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/opsconfigmonitoring.resourceMetadata.writer
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/stackdriver.resourceMetadata.writer
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/monitoring.viewer
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/serviceusage.serviceUsageViewer
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/kubernetesmetadata.publisher
   

4. Autorisez le compte de service baremetal-controller à générer des jetons d'accès au nom du compte de service baremetal-gcr:

   gcloud iam service-accounts add-iam-policy-binding \
       baremetal-gcr@PROJECT_ID.iam.gserviceaccount.com \
       --member=serviceAccount:baremetal-controller@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.serviceAccountTokenCreator
   

Configurer la fédération d'identité de charge de travail pour vos clusters

Pour fournir un accès Google Cloud avec la fédération d'identité de charge de travail pour GKE, vous devez créer une stratégie d'autorisation IAM qui accorde l'accès à une ressourceGoogle Cloud spécifique à un compte principal correspondant à l'identité de votre application. Dans ce cas, Workload Identity Federation accorde l'accès à des opérateurs spécifiques du cluster. Pour en savoir plus sur la fédération d'identité de charge de travail pour GKE, consultez la section Fédération d'identité de charge de travail dans la documentation IAM.

Ajouter des liaisons de stratégie IAM pour l'opérateur de cluster

Les commandes suivantes permettent au compte de service Kubernetes anthos-cluster-operator d'emprunter l'identité du compte de service baremetal-controller et d'interagir avec les ressources Google Cloud au nom du cluster:

1. Pour chaque cluster configuré pour l'authentification de cluster Workload Identity (ou prévu pour utiliser l'authentification de cluster Workload Identity), y compris le cluster d'amorçage, accordez à anthos-cluster-operator dans le cluster la possibilité d'emprunter l'identité du compte de service baremetal-controller:

   Dans la commande suivante, principalSet se compose du pool d'identité de la charge de travail et d'un compte de service Kubernetes, anthos-cluster-operator, dans l'espace de noms kube-system.

   gcloud iam service-accounts add-iam-policy-binding \
       baremetal-controller@PROJECT_ID.iam.gserviceaccount.com \
       --member=principalSet://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/attribute.fleetclusteridentity/projects/PROJECT_ID/locations/REGION/memberships/CLUSTER_NAME/ns/kube-system/sa/anthos-cluster-operator \
       --role=roles/iam.workloadIdentityUser \
       --project=PROJECT_ID
   

   Remplacez les éléments suivants :

   • PROJECT_NUM : identifiant unique généré automatiquement pour votre projet.

   • REGION: emplacement de l'appartenance au parc pour votre cluster, qui est global par défaut. Pour en savoir plus, consultez Emplacement des appartenances à un parc.

   • CLUSTER_NAME : nom du cluster. Par défaut, le nom du cluster d'amorçage est bmctl-MACHINE_NAME.

2. Vérifiez les liaisons de stratégie pour le compte de service baremetal-controller:

   gcloud iam service-accounts get-iam-policy \
       baremetal-controller@PROJECT_ID.iam.gserviceaccount.com
   

   La réponse devrait ressembler à ceci :

   bindings:
   - members:
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/bmctl-admin-ws/kube-system/anthos-cluster-operator
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/admin-cluster/kube-system/anthos-cluster-operator
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/user-cluster/kube-system/anthos-cluster-operator
     role: roles/iam.workloadIdentityUser
   etag: BwYoN3QLig0=
   version: 1
   

Ajouter des liaisons de stratégie IAM pour les opérateurs Google Cloud Observability

Les commandes suivantes permettent aux comptes de service Kubernetes Google Cloud Observability suivants de se faire passer pour le compte de service baremetal-cloud-ops et d'interagir avec les ressources Google Cloud au nom du cluster:

• cloud-audit-logging
• gke-metrics-agent
• kubestore-collector
• metadata-agent
• stackdriver-log-forwarder

1. Pour chaque cluster configuré pour l'authentification de cluster Workload Identity (ou prévu pour utiliser l'authentification de cluster Workload Identity), y compris le cluster d'amorçage, autorisez les opérateurs Google Cloud Observability du cluster à usurper l'identité du compte de service baremetal-cloud-ops:

   Dans chacune des commandes suivantes, principalSet se compose du pool d'identités de la charge de travail et d'un compte de service Kubernetes, tel que cloud-audit-logging, dans l'espace de noms kube-system.

   gcloud iam service-accounts add-iam-policy-binding \
       baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
       --member=principalSet://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/attribute.fleetclusteridentity/projects/PROJECT_ID/locations/REGION/memberships/CLUSTER_NAME/ns/kube-system/sa/cloud-audit-logging \
       --role=roles/iam.workloadIdentityUser \
       --project=PROJECT_ID
   
   gcloud iam service-accounts add-iam-policy-binding \
       baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
       --member=principalSet://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/attribute.fleetclusteridentity/projects/PROJECT_ID/locations/REGION/memberships/CLUSTER_NAME/ns/kube-system/sa/gke-metrics-agent \
       --role=roles/iam.workloadIdentityUser \
       --project=PROJECT_ID
   
   gcloud iam service-accounts add-iam-policy-binding \
       baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
       --member=principalSet://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/attribute.fleetclusteridentity/projects/PROJECT_ID/locations/REGION/memberships/CLUSTER_NAME/ns/kube-system/sa/kubestore-collector \
       --role=roles/iam.workloadIdentityUser \
       --project=PROJECT_ID
   
   gcloud iam service-accounts add-iam-policy-binding \
       baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
       --member=principalSet://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/attribute.fleetclusteridentity/projects/PROJECT_ID/locations/REGION/memberships/CLUSTER_NAME/ns/kube-system/sa/metadata-agent \
       --role=roles/iam.workloadIdentityUser \
       --project=PROJECT_ID
   
   gcloud iam service-accounts add-iam-policy-binding \
       baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
       --member=principalSet://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/attribute.fleetclusteridentity/projects/PROJECT_ID/locations/REGION/memberships/CLUSTER_NAME/ns/kube-system/sa/stackdriver-log-forwarder \
       --role=roles/iam.workloadIdentityUser \
       --project=PROJECT_ID
   

2. Vérifiez les liaisons de stratégie pour le compte de service baremetal-cloud-ops:

   gcloud iam service-accounts get-iam-policy \
       baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com
   

   La réponse devrait ressembler à ceci :

   bindings:
   - members:
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/bmctl-admin-ws/kube-system/cloud-audit-logging
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/bmctl-admin-ws/kube-system/gke-metrics-agent
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/bmctl-admin-ws/kube-system/kubestore-collector
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/bmctl-admin-ws/kube-system/metadata-agent
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/bmctl-admin-ws/kube-system/stackdriver-log-forwarder
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/admin-cluster/kube-system/cloud-audit-logging
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/admin-cluster/kube-system/gke-metrics-agent
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/admin-cluster/kube-system/kubestore-collector
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/admin-cluster/kube-system/metadata-agent
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/admin-cluster/kube-system/stackdriver-log-forwarder
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/user-cluster/kube-system/cloud-audit-logging
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/user-cluster/kube-system/gke-metrics-agent
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/user-cluster/kube-system/kubestore-collector
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/user-cluster/kube-system/metadata-agent
     - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/user-cluster/kube-system/stackdriver-log-forwarder
     role: roles/iam.workloadIdentityUser
   etag: BwYhT4gL-dY=
   version: 1
   

Configuration du cluster

La différence la plus évidente entre la configuration des clusters qui utilisent l'authentification de cluster Workload Identity et celle des clusters qui utilisent l'authentification de cluster Workload Identity est que vous ne spécifiez pas les chemins d'accès aux clés de compte de service téléchargées.

1. Lorsque vous renseignez les paramètres de votre cluster dans le fichier de configuration, laissez les chemins d'accès aux clés de compte de service dans la section des identifiants vides, comme illustré dans l'exemple suivant:

   gcrKeyPath:
   sshPrivateKeyPath: /home/USERNAME/.ssh/id_rsa
   gkeConnectAgentServiceAccountKeyPath:
   gkeConnectRegisterServiceAccountKeyPath:
   cloudOperationsServiceAccountKeyPath:
   ---
   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-CLUSTER_NAME
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: CLUSTER_NAME
     namespace: cluster-CLUSTER_NAME
   spec:
     type: admin
     profile: default
     anthosBareMetalVersion: 1.30.0-gke.1930
     ...
   

2. Vous pouvez également définir des noms personnalisés pour les comptes de service d'authentification de cluster Workload Identity:

   La spécification de noms personnalisés vous permet d'utiliser des comptes de service existants. En spécifiant le même nom personnalisé pour plusieurs comptes de service, vous pouvez regrouper les comptes de service.

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: CLUSTER_NAME
     namespace: cluster-CLUSTER_NAME
     annotations:
       baremetal.cluster.gke.io/controller-service-account: "CUSTOM_CONTROLLER_GSA"
       baremetal.cluster.gke.io/cloud-ops-service-account: "CUSTOM_CLOUD_OPS_GSA"
       baremetal.cluster.gke.io/gcr-service-account: "CUSTOM_GCR_GSA"
   spec:
     type: admin
     profile: default
     anthosBareMetalVersion: 1.30.0-gke.1930
       ...
   

Opération du cluster

Lorsque vous êtes prêt à créer, mettre à niveau ou supprimer un cluster qui utilise l'authentification de cluster Workload Identity, procédez comme suit:

1. Connectez-vous à Google Cloud CLI:

   gcloud auth login
   

2. Sur votre poste de travail administrateur, créez et téléchargez une clé pour le compte de service ADMIN_SA:

   Remarque :Cette clé est nécessaire pour autoriser l'accès au compte de service ADMIN_SA. Elle est supprimée une fois le compte de service autorisé.

   gcloud iam service-accounts keys create TMP_KEY_FILE_PATH \
       --iam-account=ADMIN_SA@PROJECT_ID.iam.gserviceaccount.com
   

   Remplacez TMP_KEY_FILE_PATH par le chemin d'accès, y compris le nom de fichier de clé téléchargé.

3. Autorisez l'accès à Google Cloud avec le compte de service ADMIN_SA:

   gcloud auth activate-service-account ADMIN_SA@PROJECT_ID.iam.gserviceaccount.com \
       --key-file=TMP_KEY_FILE_PATH
   

4. Supprimez le fichier de clé JSON téléchargé:

   rm TMP_KEY_FILE_PATH
   

5. Sur votre poste de travail administrateur, créez une variable d'environnement GCP_ACCESS_TOKEN avec la valeur d'un jeton d'accès créé par le compte de service ADMIN_SA:

   export GCP_ACCESS_TOKEN=$(gcloud auth print-access-token \
       --impersonate-service-account=ADMIN_SA@PROJECT_ID.iam.gserviceaccount.com)
   

   Par défaut, le jeton d'accès a une durée de vie d'une heure.

6. Vérifiez que le jeton est généré par le compte de service ADMIN_SA avec la date d'expiration correcte:

   curl "https://oauth2.googleapis.com/tokeninfo?access_token=$GCP_ACCESS_TOKEN"
   

   La réponse doit inclure des lignes semblables à celles-ci:

   ...
   "expires_in": "3582",
   "email": "ADMIN_SA@PROJECT_ID.iam.gserviceaccount.com)",
   ...
   

   La valeur d'expiration est exprimée en secondes et doit être inférieure à 3600, ce qui indique que le jeton expirera dans moins d'une heure.

7. Exécutez une commande bmctl pour créer, mettre à niveau ou supprimer un cluster:

   Si bmctl détecte que la variable d'environnement GCP_ACCESS_TOKEN a été définie, il effectue la validation du jeton. Si le jeton est valide, bmctl l'utilise pour les opérations de cluster.

   Pour les clusters qui utilisent l'authentification de cluster Workload Identity, les commandes suivantes nécessitent que la variable d'environnement GCP_ACCESS_TOKEN soit définie sur un jeton d'accès valide et actif:

   • bmctl create cluster -c CLUSTER_NAME
   • bmctl reset cluster -c CLUSTER_NAME
   • bmctl upgrade cluster -c CLUSTER_NAME

Limites

Tant que l'authentification de cluster Workload Identity est en version preview, les fonctionnalités suivantes ne sont pas prises en charge:

• Utiliser un serveur proxy
• VPC Service Controls

Étape suivante

• Déployer une application
• Créer un service et un objet Ingress