Authentification du cluster Workload Identity

Ce document explique comment configurer et utiliser l'authentification du cluster d'identité de charge de travail 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. De même, les jetons de récupération d'images expirent également au bout d'une heure par défaut.

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. Pour savoir comment définir un délai d'expiration pour vos clés de compte de service, consultez Délais d'expiration des clés gérées par l'utilisateur.

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.

L'authentification de cluster Workload Identity a été introduite en version preview avec la version 1.30 et est disponible en disponibilité générale pour la version 1.33 et ultérieure. L'authentification du cluster Workload Identity ne peut être activée que lors de la création de clusters. Vous ne pouvez pas configurer un cluster existant pour qu'il utilise l'authentification du cluster Workload Identity lors d'une mise à jour ou d'une mise à niveau. Pour connaître les autres restrictions, consultez la section Limites.

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 Rôles utilisateur et tâches courantes de GKE.

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 du cluster avec l'identité de charge de travail. Les instructions de configuration de ce document ne remplacent pas celles de la section Configurer des ressources Google Cloud. 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 du cluster Workload Identity sont semblables à ceux décrits dans Configurer des ressourcesGoogle Cloud , 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.

Les comptes de service requis pour l'authentification du cluster Workload Identity diffèrent pour les offres en version bêta et en disponibilité générale, comme décrit dans le tableau suivant :

1.33 et versions ultérieures

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/iam.serviceAccountAdmin
roles/iam.serviceAccountTokenCreator
roles/logging.admin
roles/monitoring.admin
roles/resourcemanager.projectIamAdmin
baremetal-gcr Google Distributed Cloud utilise ce compte de service pour télécharger des images de conteneurs à partir d'Artifact Registry. Aucun

1.30-1.32

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/iam.serviceAccountAdmin
roles/iam.serviceAccountTokenCreator
roles/logging.admin
roles/monitoring.admin
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. roles/kubernetesmetadata.publisher
roles/logging.logWriter
roles/monitoring.dashboardEditor
roles/monitoring.metricWriter
roles/monitoring.viewer
roles/opsconfigmonitoring.resourceMetadata.writer
roles/serviceusage.serviceUsageViewer
roles/stackdriver.resourceMetadata.writer
baremetal-gcr Google Distributed Cloud utilise ce compte de service pour télécharger des images de conteneurs à partir d'Artifact Registry. Aucun

Configurer des comptes de service

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 du 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 du cluster Workload Identity, procédez comme suit :

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

    gcloud auth login

  2. Créez les comptes de service requis pour l'authentification du cluster Workload Identity :

    Le nom du compte de service admin-sa est arbitraire. Vous pouvez modifier le nom s'il est source de conflit dans votre projet. Les autres comptes de service pour l'authentification du cluster Workload Identity ont des noms prédéterminés qui peuvent être personnalisés, si vous le souhaitez.

    1.33 et versions ultérieures 

    gcloud iam service-accounts create admin-sa \
    --project=PROJECT_ID

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

    Remplacez PROJECT_ID par l'ID de votre projetGoogle Cloud .

    1.30-1.32 

    gcloud iam service-accounts create admin-sa \
    --project=PROJECT_ID

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

Pour appliquer les liaisons de stratégie Identity and Access Management requises aux nouveaux comptes de service :

1.33 et versions ultérieures

  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/iam.serviceAccountAdmin

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:admin-sa@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/iam.serviceAccountTokenCreator

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/resourcemanager.projectIamAdmin

1.30-1.32

  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/iam.serviceAccountAdmin

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:admin-sa@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/iam.serviceAccountTokenCreator

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

  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/kubernetesmetadata.publisher

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/monitoring.viewer

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/serviceusage.serviceUsageViewer

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/stackdriver.resourceMetadata.writer

  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 l'authentification

Les étapes suivantes permettent de configurer le flux d'authentification qui utilise un jeton de courte durée pour authentifier les opérations de cluster :

  1. Sur votre poste de travail administrateur, 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 :

    Cette clé est nécessaire pour autoriser l'accès au compte de service admin-sa.

    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. Sur votre poste de travail administrateur, créez une variable d'environnement GOOGLE_APPLICATION_CREDENTIALS avec la valeur de la clé de compte de service téléchargée :

    export GOOGLE_APPLICATION_CREDENTIALS=TMP_KEY_FILE_PATH

  4. 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 application-default print-access-token)

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

  5. 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:

    ...
"exp": "1759512810",
"expires_in": "3589",
...

    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.

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.

1.33 et versions ultérieures

Pour les versions de cluster dans lesquelles l'authentification du cluster Workload Identity est en disponibilité générale, vous utilisez la commande bmctl configure projects pour configurer la fédération d'identité de charge de travail pour vos clusters. Cette commande est intégrée aux étapes de création d'un cluster d'administrateur et de création d'un cluster d'utilisateur.

1.30-1.32

Pour les versions de cluster dans lesquelles l'authentification du cluster Workload Identity est en version Preview, vous devez configurer manuellement la fédération d'identité de charge de travail pour vos clusters, comme décrit dans les sections suivantes.

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 :

  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 à emprunter 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

Créer un cluster d'administrateur

La procédure de création d'un cluster d'administrateur diffère légèrement pour les offres Preview (versions 1.30 à 1.32) et GA (versions 1.33 et ultérieures). Les étapes de disponibilité générale utilisent la commande bmctl configure projects pour configurer la fédération d'identité de charge de travail pour vos clusters.

1.33 et versions ultérieures

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 le mode avec clé 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-ADMIN_CLUSTER_NAME
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: ADMIN_CLUSTER_NAME
  namespace: cluster-ADMIN_CLUSTER_NAME
spec:
  type: admin
  profile: default
  anthosBareMetalVersion: 1.33.0-gke.799
  ...

  2. Ajoutez l'annotation baremetal.cluster.gke.io/enable-workload-identity-cluster-authentication: "true" au fichier de configuration du cluster :

    gcrKeyPath:
sshPrivateKeyPath: /home/USERNAME/.ssh/id_rsa
gkeConnectAgentServiceAccountKeyPath:
gkeConnectRegisterServiceAccountKeyPath:
cloudOperationsServiceAccountKeyPath:
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-ADMIN_CLUSTER_NAME
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: ADMIN_CLUSTER_NAME
  namespace: cluster-ADMIN_CLUSTER_NAME
  annotations:
    baremetal.cluster.gke.io/enable-workload-identity-cluster-authentication: "true"
spec:
  type: admin
  profile: default
  anthosBareMetalVersion: 1.33.0-gke.799
  ...

  3. Sur votre poste de travail administrateur, mettez à jour la variable d'environnement GCP_ACCESS_TOKEN avec un jeton d'accès nouvellement récupéré :

    export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token)

    Par défaut, le jeton d'accès a une durée de vie de 3 600 secondes (une heure). Lorsque vous utilisez l'authentification du cluster Workload Identity, bmctl vérifie le délai d'expiration du jeton. Si le jeton expire dans les 1 800 secondes (30 minutes), bmctl signale une erreur et quitte le programme.

  4. Configurez la fédération d'identité de charge de travail pour le cluster que vous créez :

    bmctl configure projects --project-id=PROJECT_ID \
    --admin-cluster=ADMIN_CLUSTER_NAME

  5. Exécutez la commande bmctl create cluster pour créer votre cluster d'administrateur.

1.30-1.32

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 le mode avec clé 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-ADMIN_CLUSTER_NAME
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: ADMIN_CLUSTER_NAME
  namespace: cluster-ADMIN_CLUSTER_NAME
spec:
  type: admin
  profile: default
  anthosBareMetalVersion: 1.33.0-gke.799
  ...

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

    Cette clé est nécessaire pour autoriser l'accès au compte de service admin-sa. Vous devez la supprimer immédiatement après l'autorisation du compte de service.

    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

    Le jeton d'accès a une durée de vie courte. Vous devez donc généralement le régénérer avant d'exécuter des commandes bmctl pour les opérations de cluster, telles que la création, la mise à niveau ou la réinitialisation d'un cluster.

  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 de 3 600 secondes (une heure).

  6. Exécutez la commande bmctl create cluster pour créer votre cluster d'administrateur.

Créer un cluster d'utilisateur

La procédure de création d'un cluster d'administrateur diffère légèrement pour les offres Preview (versions 1.30 à 1.32) et GA (versions 1.33 et ultérieures). Les étapes de disponibilité générale utilisent la commande bmctl configure projects pour configurer la fédération d'identité de charge de travail pour vos clusters.

1.33 et versions ultérieures

  1. Ajoutez l'annotation baremetal.cluster.gke.io/enable-workload-identity-cluster-authentication: "true" au fichier de configuration du cluster :

    apiVersion: v1
kind: Namespace
metadata:
  name: cluster-USER_CLUSTER_NAME
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: USER_CLUSTER_NAME
  namespace: cluster-USER_CLUSTER_NAME
  annotations:
    baremetal.cluster.gke.io/enable-workload-identity-cluster-authentication: "true"
spec:
  type: admin
  profile: default
  anthosBareMetalVersion: 1.33.0-gke.799
  ...

    Le jeton d'accès a une durée de vie courte. Vous devez donc généralement le régénérer avant d'exécuter des commandes bmctl pour les opérations de cluster, telles que la création, la mise à niveau ou la réinitialisation d'un cluster.

  2. Sur votre poste de travail administrateur, mettez à jour la variable d'environnement GCP_ACCESS_TOKEN avec un jeton d'accès nouvellement récupéré :

    export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token)

    Par défaut, le jeton d'accès a une durée de vie de 3 600 secondes (une heure).

  3. Configurez la fédération d'identité de charge de travail pour le cluster que vous créez :

    bmctl configure projects --project-id=PROJECT_ID \
    --user-clusters=USER_CLUSTER_NAME

  4. Utilisez kubectl pour déployer le fichier manifeste du cluster d'utilisateur :

    kubectl apply -f USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_KUBECONFIG

Remplacez les éléments suivants :

  • USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur

  • ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.

1.30-1.32

  1. Sur votre poste de travail administrateur, créez et téléchargez une clé pour le compte de service admin-sa :

    Cette clé est nécessaire pour autoriser l'accès au compte de service admin-sa. Vous devez la supprimer immédiatement après l'autorisation du compte de service.

    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é.

  2. 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

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

    rm TMP_KEY_FILE_PATH

    Le jeton d'accès a une durée de vie courte. Vous devez donc généralement le régénérer avant d'exécuter des commandes bmctl pour les opérations de cluster, telles que la création, la mise à niveau ou la réinitialisation d'un cluster.

  4. 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 de 3 600 secondes (une heure).

  5. Exécutez la commande bmctl create cluster pour créer votre cluster d'utilisateur.

Autres opérations sur les clusters

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

  • bmctl configure projects
  • bmctl create cluster
  • bmctl reset cluster
  • bmctl upgrade 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.

  • Si le jeton n'est pas valide, récupérez-en un nouveau :

    Le jeton d'accès a une durée de vie courte. Vous devez donc généralement le régénérer avant d'exécuter des commandes bmctl pour les opérations de cluster, telles que la création, la mise à niveau ou la réinitialisation d'un cluster. Sur votre poste de travail administrateur, mettez à jour la variable d'environnement GCP_ACCESS_TOKEN avec un jeton d'accès nouvellement récupéré :

    1.33 et versions ultérieures 

    export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token)

    1.30-1.32 

    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 de 3 600 secondes (une heure). Lorsque vous utilisez l'authentification du cluster Workload Identity, bmctl vérifie le délai d'expiration du jeton. Si le jeton expire dans les 1 800 secondes (30 minutes), bmctl signale une erreur et quitte le programme.

Personnalisation

Vous pouvez utiliser des comptes de service avec des noms uniques pour l'authentification du cluster Workload Identity, à condition qu'ils disposent de liaisons pour les rôles requis.

1.33 et versions ultérieures

Par défaut, l'authentification du cluster Workload Identity pour les clusters de version 1.33 et ultérieure n'utilise que le compte de service baremetal-gcr. Il s'agit donc du seul compte de service pouvant être personnalisé.

  1. Assurez-vous que le compte de service que vous souhaitez utiliser dispose des rôles identifiés dans le tableau de la section Avant de commencer.

  2. Annotez le fichier de configuration du cluster pour spécifier le nom personnalisé du compte de service d'authentification du cluster Workload Identity :

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: my-cluster
  namespace: cluster-my-cluster
  annotations:
    ...
    baremetal.cluster.gke.io/gcr-service-account: "CUSTOM_AR_GSA"
spec:
  type: admin
  profile: default
  anthosBareMetalVersion: 1.33.0-gke.799
  ...

Remplacez CUSTOM_AR_GSA par le nom de l'adresse e-mail du compte de service utilisé par Google Distributed Cloud pour télécharger des images de conteneurs à partir d'Artifact Registry.

1.30-1.32

  1. Assurez-vous que les comptes de service que vous souhaitez utiliser disposent des rôles identifiés dans le tableau de la section Avant de commencer.

  2. Ajoutez une annotation au fichier de configuration du cluster pour spécifier les noms personnalisés des comptes de service du service d'authentification du cluster Workload Identity :

    La spécification de noms personnalisés vous permet d'utiliser des comptes de service existants. Assurez-vous que les noms de comptes de service personnalisés que vous spécifiez sont différents les uns des autres. Nous n'autorisons pas l'utilisation d'un seul compte de service pour remplacer deux comptes de service par défaut ou plus.

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: my-cluster
  namespace: cluster-my-cluster
  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_AR_GSA"
spec:
  type: admin
  profile: default
  anthosBareMetalVersion: 1.30.0-gke.1930
  ...

Remplacez les éléments suivants :

  • CUSTOM_CONTROLLER_GSA : nom de l'adresse e-mail du compte de service utilisé par l'agent Connect pour maintenir une connexion entre votre cluster et Google Cloud, et pour enregistrer vos clusters.

  • CUSTOM_CLOUD_OPS_GSA : nom de l'adresse e-mail du compte de service utilisé par l'agent Stackdriver pour exporter les journaux et les métriques des clusters vers Cloud Logging et Cloud Monitoring.

  • CUSTOM_AR_GSA : nom de l'adresse e-mail du compte de service utilisé par Google Distributed Cloud pour télécharger les images de conteneurs depuis Artifact Registry.

Limites

Les fonctionnalités suivantes ne sont pas compatibles lorsque vous utilisez l'authentification du cluster Workload Identity pour Google Distributed Cloud (logiciel uniquement) sur Bare Metal :

  • Utiliser un serveur proxy
  • VPC Service Controls
  • Mettre à jour les clusters en mode clé existants pour utiliser l'authentification de cluster Workload Identity
  • Gestion du cycle de vie des clusters à l'aide de clients de l'API GKE On-Prem, tels que Google Cloud CLI, Terraform ou la console Google Cloud

Étapes suivantes