S'authentifier auprès des API Google Cloud à partir de charges de travail de parc à confiance mixte

Cette page vous explique comment configurer vos applications pour qu'elles s'authentifient auprès des APIGoogle Cloud , comme l'API Compute Engine ou l'API AI Platform, à partir de flottes qui ont un modèle de confiance mixte. Si votre parc dispose d'un modèle de confiance partagée, consultez S'authentifier auprès des API  Google Cloud à partir des charges de travail du parc à confiance partagée.

Cette page s'adresse aux administrateurs et opérateurs de plate-forme, ainsi qu'aux ingénieurs en sécurité qui souhaitent s'authentifier de manière programmatique auprès des API Google Cloudà partir de charges de travail de parc. Pour en savoir plus sur les rôles utilisateur et les exemples de tâches que nous citons dans la documentation Google Cloud, consultez Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Avant de lire cette page, assurez-vous de maîtriser les concepts suivants :

À propos de la fédération d'identité de charge de travail de parc pour les environnements à confiance mixte

La fédération d'identité de charge de travail du parc vous permet d'accorder des rôles IAM sur les API et les ressourcesGoogle Cloud aux entités de votre parc, comme les charges de travail dans un espace de noms spécifique. Par défaut, votre projet hôte de parc utilise un pool d'identités de charge de travail géré par Google pour provisionner des identités pour les entités du parc. Toutefois, dans les environnements à confiance mixte tels que les parcs multitenants ou dans les projets hôtes de parc qui exécutent des clusters autonomes, nous vous recommandons de configurer un pool d'identités de charge de travail autogéré distinct pour un sous-ensemble de vos charges de travail et clusters.

Les entités qui utilisent un pool d'identités de charge de travail autogéré ont des identifiants différents dans les règles IAM que les entités qui utilisent le pool d'identités de charge de travail géré par Google du projet hôte du parc. Cela garantit que l'octroi d'un accès aux comptes principaux dans un espace de noms de parc spécifique n'accorde pas involontairement l'accès à d'autres comptes principaux correspondant à l'identifiant.

Les pools d'identités de charge de travail autogérés nécessitent l'utilisation de scopes d'équipe. Les niveaux d'accès d'équipe vous permettent de contrôler l'accès à des sous-ensembles de ressources de parc par équipe. Vous associez des niveaux d'accès d'équipe spécifiques à des clusters membres de parc spécifiques pour permettre à cette équipe de déployer des charges de travail sur ces clusters. Dans un niveau d'accès d'équipe, les membres de l'équipe ne peuvent déployer des charges de travail que dans des espaces de noms de parc.

L'utilisation de pools d'identités de charge de travail autogérés pour fournir des identités aux charges de travail de portée d'équipe présente des avantages tels que les suivants :

  • Assurez-vous que les droits d'accès aux entités des espaces de noms de parc ne s'appliquent pas involontairement aux entités d'autres espaces de noms ou clusters.
  • Configurez un ensemble de clusters de parc pour obtenir des identités à partir du pool autogéré en les associant à un champ d'application d'équipe et en configurant le pool autogéré en tant que fournisseur d'identité dans ces clusters.
  • Configurez un sous-ensemble des clusters liés d'un champ d'application d'équipe pour obtenir des identités à partir du pool autogéré en configurant uniquement le pool autogéré en tant que fournisseur d'identité dans des clusters spécifiques.

Exemple d'uniformité de l'identité dans un environnement à confiance mixte

Imaginez le scénario suivant :

  • Vous disposez de deux clusters membres du parc : frontend-cluster et finance-cluster.
  • Vous n'avez pas configuré de pool d'identités de charge de travail autogéré.
  • Vous créez un champ d'application d'équipe finance-team et un espace de noms de parc finance-ns dans le champ d'application d'équipe.
  • Vous associez le cluster finance-cluster au niveau d'accès de l'équipe finance-team.
  • Vous attribuez un rôle IAM au compte de service Kubernetes finance-sa dans l'espace de noms du parc finance-ns.

Toutes les charges de travail qui répondent aux critères suivants partagent la même identité :

  • Exécutez-le dans l'espace de noms du parc finance-ns.
  • Utilisez le compte de service finance-sa.

Toutefois, si une personne du cluster frontend-cluster crée un espace de noms Kubernetes finance-ns et un compte de service finance-sa, elle obtient la même identité que les charges de travail du cluster finance-cluster. En effet, l'ensemble du parc utilise le pool d'identités de charge de travail géré par Google du projet hôte du parc, et l'identifiant principal ne spécifie pas de cluster hôte.

Prenons l'exemple suivant :

  • Vous configurez un pool d'identités de charge de travail autogéré dans votre parc.
  • Vous configurez le cluster finance-cluster pour obtenir des identités à partir du pool autogéré au lieu du pool géré par Google.
  • Vous créez une autorisation de rôle IAM qui spécifie le pool autogéré dans l'identifiant principal au lieu du pool géré par Google.

Les charges de travail qui s'exécutent dans l'espace de noms du parc finance-ns dans finance-cluster obtiennent désormais une identité du pool autogéré. Toutefois, les entités de l'espace de noms Kubernetes finance-ns du cluster frontend-cluster continuent d'obtenir des identités à partir du pool d'identités de charge de travail géré par Google du projet hôte du parc.

Ces modifications présentent les avantages suivants :

  • Vous pouvez accorder explicitement des rôles aux entités dans l'espace de noms de parc finance-ns.
  • Les entités du cluster frontend-cluster ne peuvent pas obtenir le même accès, car les identités du cluster frontend-cluster proviennent du pool d'identités de charge de travail géré par Google.

Avant de commencer

  • Assurez-vous que les outils de ligne de commande suivants sont installés :

    • La dernière version de la CLI Google Cloud, qui inclut gcloud, l'outil de ligne de commande permettant d'interagir avec Google Cloud.
    • kubectl

    Si vous utilisez Cloud Shell comme environnement shell pour interagir avec Google Cloud, ces outils sont installés pour vous.

  • Assurez-vous d'avoir initialisé gcloud CLI à utiliser avec votre projet.

Conditions requises

Vous devez utiliser les fonctionnalités de gestion des équipes de parc, comme les niveaux d'accès d'équipe et les espaces de noms de parc dans votre parc. Les instructions de cette page vous expliquent comment configurer un exemple de champ d'application d'équipe et d'espace de noms de parc.

Préparer vos clusters

Pour que les applications de votre parc puissent recevoir une identité fédérée, les clusters sur lesquels elles s'exécutent doivent être enregistrés dans votre parc et correctement configurés pour utiliser la fédération d'identité de charge de travail de parc. Les sections suivantes décrivent comment configurer la fédération d'identité de charge de travail de flotte pour différents types de clusters.

GKE

Pour les clusters GKE, procédez comme suit :

  1. Activez la fédération d'identité de charge de travail pour GKE sur votre cluster Google Kubernetes Engine, si ce n'est pas déjà fait.
  2. Enregistrez le cluster dans le parc.

Vous pouvez également activer la fédération d'identité de charge de travail pour GKE lors de la création du cluster et de l'enregistrement du parc.

Clusters en dehors de Google Cloud

Les types de clusters suivants activent automatiquement la fédération d'identité de charge de travail du parc et sont enregistrés dans votre parc lors de la création du cluster :

  • Google Distributed Cloud (logiciel uniquement) sur VMware
  • Google Distributed Cloud (logiciel uniquement) sur solution Bare Metal
  • GKE sur AWS
  • GKE sur Azure

Clusters associés

Les clusters associés EKS et AKS enregistrés à l'aide de l'API GKE Multi-Cloud sont enregistrés avec la fédération d'identité de charge de travail de parc activée par défaut. Les autres clusters associés peuvent être enregistrés lorsque la fédération d'identité de charge de travail du parc est activée, s'ils répondent aux conditions préalables. Suivez les instructions correspondant à votre type de cluster dans Enregistrer un cluster.

Configurer un pool d'identités de charge de travail IAM

Dans cette section, vous allez créer un pool d'identités de charge de travail IAM dans le projet hôte du parc et accorder l'accès à l'agent de service du parc au nouveau pool.

  1. Créez un pool d'identités de charge de travail :

    gcloud iam workload-identity-pools create POOL_NAME \
    --location=global \
    --project=POOL_HOST_PROJECT_ID \
    --mode=TRUST_DOMAIN

    Remplacez les éléments suivants :

    • POOL_NAME : nom du nouveau pool d'identités de charge de travail.
    • POOL_HOST_PROJECT_ID : ID du projet dans lequel vous souhaitez créer le pool d'identités de charge de travail autogéré. Vous pouvez utiliser n'importe quel projet  Google Cloud , y compris votre projet hôte de parc.

  2. Accordez le rôle Administrateur IAM de pools d'identités de charge de travail (roles/iam.workloadIdentityPoolAdmin) sur le nouveau pool d'identités de charge de travail à l'agent de service du parc :

    gcloud iam workload-identity-pools add-iam-policy-binding POOL_NAME \
    --project=POOL_HOST_PROJECT_ID \
    --location=global \
    --member=serviceAccount:service-FLEET_HOST_PROJECT_NUMBER@gcp-sa-gkehub.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityPoolAdmin \
    --condition=None

    Remplacez FLEET_HOST_PROJECT_NUMBER par le numéro du projet hôte du parc.

Ajouter le pool autogéré à la configuration de votre parc

Dans cette section, vous allez activer les pools autogérés avec la fédération d'identité de charge de travail du parc, puis ajouter le pool que vous avez créé à la configuration du parc. Cette section fournit également des instructions pour créer un niveau d'accès d'équipe et un espace de noms de parc. Si des champs d'application d'équipe et des espaces de noms de parc sont déjà configurés dans votre parc, ignorez ces étapes.

  1. Activez la fédération d'identité de charge de travail du parc au niveau du parc :

    gcloud beta container fleet workload-identity enable \
  --project=FLEET_HOST_PROJECT_ID

    Remplacez FLEET_HOST_PROJECT_ID par l'ID de votre projet hôte de parc.

  2. Ajoutez le pool d'identités de charge de travail autogéré à la configuration du parc :

    gcloud beta container fleet workload-identity scope-tenancy-pool set POOL_NAME

    Remplacez POOL_NAME par le nom de votre pool d'identités de charge de travail autogéré. Cette valeur utilise la syntaxe suivante :

    POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog

  3. Créez un niveau d'accès d'équipe. Si vous disposez déjà d'un champ d'application d'équipe et d'un espace de noms de parc, passez à la section Vérifier la configuration du pool d'identités de charge de travail.

    gcloud container fleet scopes create SCOPE_NAME

    Remplacez SCOPE_NAME par le nom de votre nouvelle portée d'équipe.

  4. Créez un espace de noms de parc dans le niveau d'accès de l'équipe :

    gcloud container fleet scopes namespaces create NAMESPACE_NAME \
    --scope=SCOPE_NAME

    Remplacez NAMESPACE_NAME par le nom de votre nouvel espace de noms de parc.

  5. Associez un cluster de votre parc au champ d'application de l'équipe :

    gcloud container fleet memberships bindings create BINDING_NAME \
    --membership=FLEET_CLUSTER_NAME \
    --location=global \
    --scope=SCOPE_NAME

    Remplacez les éléments suivants :

    • BINDING_NAME : nom de votre nouvelle association de membres.
    • FLEET_CLUSTER_NAME : nom du cluster de parc existant à associer au niveau d'accès de l'équipe.

Vérifier la configuration du pool d'identités de charge de travail

Dans cette section, vous vous assurez que la configuration de votre pool d'identités de charge de travail autogéré a réussi.

  1. Décrivez la configuration de l'appartenance au parc :

    gcloud container fleet memberships describe FLEET_CLUSTER_NAME \
    --location=global

    Remplacez FLEET_CLUSTER_NAME par le nom d'un cluster de parc existant lié à un champ d'application d'équipe dans votre parc.

    Le résultat ressemble à ce qui suit :

    authority:
...
  scopeTenancyIdentityProvider: https://gkehub.googleapis.com/projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/FLEET_CLUSTER_NAME
  scopeTenancyWorkloadIdentityPool: POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog
  workloadIdentityPool: FLEET_HOST_PROJECT_ID.svc.id.goog
...

    Cette sortie doit contenir les champs suivants :

    • scopeTenancyIdentityProvider : fournisseur d'identité pour les charges de travail exécutées dans des espaces de noms de parc au sein de niveaux d'accès d'équipe. La valeur est un identifiant de ressource pour votre cluster.
    • scopeTenancyWorkloadIdentityPool : pool d'identités de charge de travail à partir duquel les charges de travail dans les espaces de noms du parc au sein des périmètres d'équipe obtiennent des identifiants. La valeur correspond à votre pool d'identités de charge de travail autogéré, au format POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog.
    • workloadIdentityPool : nom du pool d'identités de charge de travail géré par Google du projet hôte du parc, à partir duquel toutes les autres charges de travail du parc obtiennent des identités par défaut.

  2. Facultatif : Vérifiez si votre pool d'identités de charge de travail possède un espace de noms portant le même nom que celui de votre parc :

    gcloud iam workload-identity-pools namespaces list \
    --workload-identity-pool=POOL_NAME \
    --location=global

    Le résultat ressemble à ce qui suit :

    ---
description: Fleet namespace NAMESPACE_NAME
name: projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME/namespaces/NAMESPACE_NAME
state: ACTIVE

Votre parc peut désormais utiliser le pool d'identités de charge de travail autogéré pour obtenir des identités pour les charges de travail qui s'exécutent dans les espaces de noms du parc. Pour commencer à utiliser le pool autogéré, configurez la façon dont les clusters spécifiques obtiennent des identités, comme décrit dans la section suivante.

Faire en sorte que les charges de travail utilisent des pools autogérés pour les identités

Pour que les charges de travail utilisent le pool autogéré, vous devez configurer des espaces de noms de parc spécifiques dans les clusters membres du parc à l'aide d'un ConfigMap Kubernetes. Cette configuration par cluster et par espace de noms vous permet de réduire davantage le champ d'application des autorisations d'accès, en passant des espaces de noms de l'ensemble du parc aux charges de travail qui s'exécutent dans des espaces de noms de parc spécifiques dans des clusters spécifiques.

  1. Connectez-vous à votre cluster membre du parc :

    gcloud container clusters get-credentials FLEET_CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CLUSTER_LOCATION

    Remplacez les éléments suivants :

    • FLEET_CLUSTER_NAME : nom d'un cluster membre du parc déjà associé à un niveau d'accès d'équipe.
    • CLUSTER_PROJECT_ID : ID de projet du projet de cluster.
    • CLUSTER_LOCATION : emplacement du cluster.

  2. Obtenez le nom complet du pool d'identités de charge de travail autogéré. Vous en aurez besoin plus tard.

    kubectl get membership membership -o json | jq -r ".spec.scope_tenancy_workload_identity_pool"

    Le résultat ressemble à ce qui suit :

    POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog

  3. Obtenez le nom du fournisseur d'identité pour les niveaux d'accès de l'équipe. Vous en aurez besoin ultérieurement.

    kubectl get membership membership -o json | jq -r ".spec.scope_tenancy_identity_provider"

    Le résultat ressemble à ce qui suit :

    https://gkehub.googleapis.com/projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/FLEET_CLUSTER_NAME

  4. Dans un éditeur de texte, enregistrez le fichier manifeste YAML suivant pour un ConfigMap sous le nom self-managed-pool.yaml :

    kind: ConfigMap
apiVersion: v1
metadata:
  namespace: NAMESPACE_NAME
  name: google-application-credentials
data:
  config: |
    {
      "type": "external_account",
      "audience": "identitynamespace:SELF_MANAGED_POOL_FULL_NAME:IDENTITY_PROVIDER",
      "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
      "token_url": "https://sts.googleapis.com/v1/token",
      "credential_source": {
        "file": "/var/run/secrets/tokens/gcp-ksa/token"
      }
    }

    Remplacez les éléments suivants :

    • NAMESPACE_NAME : nom de l'espace de noms du parc.
    • SELF_MANAGED_POOL_FULL_NAME : nom complet du pool d'identités de charge de travail autogéré à partir de la sortie des étapes précédentes de cette section. Exemple : example-pool.global.1234567890.workload.id.goog.
    • IDENTITY_PROVIDER : nom du fournisseur d'identité issu des étapes précédentes de cette section. Exemple : https://gkehub.googleapis.com/projects/1234567890/locations/global/memberships/example-cluster..

  5. Déployez le ConfigMap dans votre cluster :

    kubectl create -f self-managed-pool.yaml

Le déploiement du ConfigMap indique à GKE que les charges de travail de cet espace de noms doivent utiliser le pool d'identités de charge de travail autogéré pour obtenir des identités.

Attribuer des rôles IAM aux comptes principaux

Dans cette section, vous allez créer un compte de service Kubernetes dans un espace de noms de parc et accorder un rôle IAM au compte de service. Les pods qui utilisent ce ServiceAccount peuvent ensuite accéder aux ressources Google Cloud sur lesquelles vous accordez le rôle.

  1. Créez un ServiceAccount Kubernetes dans l'espace de noms de votre parc :

    kubectl create serviceaccount SERVICEACCOUNT_NAME \
    --namespace=NAMESPACE_NAME

    Remplacez les éléments suivants :

    • SERVICEACCOUNT_NAME : nom de votre nouveau compte de service.
    • NAMESPACE_NAME : nom de l'espace de noms du parc.

  2. Attribuez un rôle IAM au compte de service. L'exemple de commande suivant attribue le rôle Lecteur des objets Storage (roles/storage.objectViewer) sur un bucket au compte de service :

    gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
    --member=principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog/subject/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME \
    --role=roles/storage.objectViewer \
    --condition=None

L'indicateur member contient l'identifiant principal du nouveau ServiceAccount que vous avez créé. Les requêtes que vos charges de travail envoient aux API Google Cloudutilisent un jeton d'accès fédéré. Ce jeton d'accès fédéré inclut l'identifiant principal de l'entité qui envoie la requête. Si le compte principal d'une stratégie d'autorisation qui accorde un rôle sur la ressource cible correspond au compte principal du jeton d'accès fédéré, l'authentification et l'autorisation peuvent se poursuivre.

Déployer des charges de travail qui utilisent le pool autogéré

Les fichiers manifestes Kubernetes que vous appliquez dans votre espace de noms de parc doivent être configurés pour obtenir des identités à partir du pool autogéré. Les charges de travail que vous déployez et qui doivent appeler les API Google Cloud doivent inclure les champs suivants :

  • metadata.namespace : nom de l'espace de noms du parc.
  • spec.serviceAccountName : nom du compte de service Kubernetes dans l'espace de noms du parc.
  • spec.containers.env : variable d'environnement nommée GOOGLE_APPLICATION_CREDENTIALS qui indique le chemin d'accès au fichier d'identifiants par défaut de l'application (ADC).
  • spec.containers.volumeMounts : volume en lecture seule qui permet au conteneur d'utiliser le jeton du porteur pour le compte de service.
  • spec.volumes : volume projeté qui monte un jeton ServiceAccount dans le pod. L'audience du jeton est le pool d'identités de charge de travail autogéré. Le ConfigMap contenant la configuration de la fédération d'identité de charge de travail du parc est une source pour le volume.

Pour obtenir un exemple de fichier manifeste correctement configuré, consultez la section Vérifier l'authentification à partir d'une charge de travail.

Vérifier l'authentification à partir d'une charge de travail

Cette section fournit des instructions facultatives pour vérifier que vous avez correctement configuré le pool d'identités de charge de travail autogéré en listant le contenu d'un exemple de bucket Cloud Storage. Vous créez un bucket, accordez un rôle sur le bucket à un ServiceAccount dans un espace de noms de parc, puis déployez un pod pour tenter d'accéder au bucket.

  1. Créez un bucket Cloud Storage :

    gcloud storage buckets create gs://FLEET_HOST_PROJECT_ID-workload-id-bucket \
    --location=LOCATION \
    --project=FLEET_HOST_PROJECT_ID

  2. Attribuez le rôle roles/storage.objectViewer sur le bucket au compte de service dans l'espace de noms du parc :

    gcloud storage buckets add-iam-policy-binding gs://FLEET_HOST_PROJECT_ID-workload-id-bucket \
    --condition=None \
    --role=roles/storage.objectViewer \
    --member=principal://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog/subject/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME

    Remplacez les éléments suivants :

    • FLEET_HOST_PROJECT_NUMBER : numéro de votre projet hôte de parc.
    • POOL_NAME : nom de votre pool d'identités de charge de travail autogéré.
    • NAMESPACE_NAME : nom de l'espace de noms du parc dans lequel vous souhaitez exécuter le pod.
    • SERVICEACCOUNT_NAME : nom du compte de service Kubernetes que le pod doit utiliser.

  3. Enregistrez le manifeste suivant sous le nom pod-bucket-access.yaml :

    apiVersion: v1
kind: Pod
metadata:
  name: bucket-access-pod
  namespace:  NAMESPACE_NAME
spec:
  serviceAccountName: SERVICEACCOUNT_NAME
  containers:
  - name: sample-container
    image: google/cloud-sdk:slim
    command: ["sleep","infinity"]
    env:
    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: /var/run/secrets/tokens/gcp-ksa/google-application-credentials.json
    volumeMounts:
    - name: gcp-ksa
      mountPath: /var/run/secrets/tokens/gcp-ksa
      readOnly: true
  volumes:
  - name: gcp-ksa
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          path: token
          audience: POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog
          expirationSeconds: 172800
      - configMap:
          name: my-cloudsdk-config
          optional: false
          items:
          - key: "config"
            path: "google-application-credentials.json"

    Remplacez les éléments suivants :

    • NAMESPACE_NAME : nom de l'espace de noms du parc dans lequel vous souhaitez exécuter le pod.
    • SERVICEACCOUNT_NAME : nom du compte de service Kubernetes que le pod doit utiliser.
    • POOL_NAME : nom de votre pool d'identités de charge de travail autogéré.
    • FLEET_HOST_PROJECT_NUMBER : numéro de votre projet hôte de parc.

  4. Déployez le pod dans votre cluster :

    kubectl apply -f pod-bucket-access.yaml

  5. Ouvrez une session d'interface système dans le pod :

    kubectl exec -it bucket-access-pod -n NAMESPACE_NAME -- /bin/bash

  6. Essayez de lister les objets du bucket :

    curl -X GET -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
    "https://storage.googleapis.com/storage/v1/b/FLEET_HOST_PROJECT_ID-workload-id-bucket/o"

    Le résultat est le suivant :

    {
  "kind": "storage#objects"
}

Vous pouvez également vérifier qu'un espace de noms et un compte de service similaires dans un autre cluster membre du parc ne pourront pas affirmer la même identité. Dans un cluster qui utilise la fédération d'identité de charge de travail du parc, mais qui ne dispose pas d'un espace de noms de parc ni d'une configuration de pool autogérée, procédez comme suit :

  1. Créez un espace de noms Kubernetes portant le même nom que l'espace de noms du parc dans lequel vous avez configuré le pool d'identités de charge de travail autogéré.
  2. Créez un compte de service Kubernetes portant le même nom que celui auquel vous avez attribué un rôle IAM dans les sections précédentes.

  3. Déployez un pod qui utilise le même compte de service et le même espace de noms, mais pour lequel le champ spec.volumes.projected.sources.serviceAccountToken spécifie le pool d'identités de charge de travail géré par Google. Ce pool utilise la syntaxe suivante :

    FLEET_HOST_PROJECT_ID.svc.id.goog

  4. Tentez d'accéder au bucket Cloud Storage depuis une session shell dans le pod.

La sortie doit être une erreur 401: Unauthorized, car l'identifiant principal du pod qui utilise le pool d'identités de charge de travail géré par Google est différent de l'identifiant principal du pod qui utilise le pool autogéré.

Étapes suivantes