Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

Cette page vous explique comment configurer vos applications pour qu'elles s'authentifient auprès des Google Cloud API telles que l'API Compute Engine ou l'API AI Platform à partir de parcs qui disposent d'un modèle d'approbation partagé dans l'ensemble du parc. Si votre parc dispose d'un modèle d'approbation mixte, consultez la page S'authentifier auprès des Google Cloud API à partir de charges de travail de parc à approbation mixte.

Cette page est destinée aux administrateurs et opérateurs de plate-forme, ainsi qu'aux ingénieurs en sécurité qui souhaitent s'authentifier par programmation auprès des Google Cloud API à 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 Google Cloud documentation, consultez Rôles utilisateur et tâches courantes de GKE.

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 à approbation partagée

La fédération d'identité de charge de travail de parc vous permet de vous authentifier auprès de Google Cloud API à partir de charges de travail de parc à l'aide de mécanismes d'authentification Kubernetes intégrés Google Cloud et. La fédération d'identité de charge de travail de parc élimine le besoin d'utiliser des méthodes moins sécurisées, comme l'installation de jetons d'accès dans des pods ou le stockage d'identifiants à longue durée de vie.

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. Toute entité du parc ou du projet hôte de parc qui possède le même identifiant IAM est considérée comme identique par IAM. Cette identité implicite est utile lorsque vous accordez un accès à grande échelle dans des environnements à approbation partagée, tels que les parcs à locataire unique, où il n'est pas important que d'autres entités obtiennent involontairement des autorisations similaires sur les ressources.

Avant de commencer

Assurez-vous que les outils de ligne de commande suivants sont installés :
- La dernière version de la Google Cloud CLI qui inclut gcloud, l'outil de ligne de commande qui permet 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.

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 parc pour différents types de clusters.

GKE

Pour les clusters GKE, procédez comme suit :

Activez Workload Identity Federation for GKE sur votre cluster Google Kubernetes Engine si ce n'est pas déjà fait.
Enregistrez le cluster dans le parc.

Vous pouvez également activer Workload Identity Federation for GKE lors du processus de création de cluster et d'enregistrement de parc.

Clusters en dehors de Google Cloud

Les types de clusters suivants activent automatiquement la fédération d'identité de charge de travail de 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 de parc est activée, s'ils répondent aux conditions préalables . Suivez les instructions correspondant à votre type de cluster de la page Enregistrer un cluster.

Utiliser la fédération d'identité de charge de travail de parc dans les applications

La procédure suivante permet de configurer une charge de travail dans un cluster enregistré pour qu'elle utilise la fédération d'identité de charge de travail de parc :

Recherchez le nom de votre pool d'identités de charge de travail de cluster et de votre fournisseur d'identité :
```
gcloud container fleet memberships describe MEMBERSHIP_ID \
    --project=FLEET_PROJECT_ID \
    --format="table(authority.identityProvider,authority.workloadIdentityPool,name)"
```
Remplacez les éléments suivants :
- MEMBERSHIP_ID : nom de l'abonnement au cluster . Il s'agit souvent du nom de votre cluster.
- FLEET_PROJECT_ID: ID du projet hôte du parc.
Le résultat ressemble à ce qui suit :
```
IDENTITY_PROVIDER: IDENTITY_PROVIDER
WORKLOAD_IDENTITY_POOL: WORKLOAD_IDENTITY_POOL
NAME: projects/FLEET_PROJECT_ID/locations/MEMBERSHIP_LOCATION/memberships/MEMBERSHIP_ID
```
Ce résultat contient les informations suivantes :
- IDENTITY_PROVIDER: fournisseur d'identité du cluster.
- MEMBERSHIP_LOCATION: emplacement de l'abonnement au parc. Il s'agit généralement du même emplacement que celui de votre cluster.
- WORKLOAD_IDENTITY_POOL : nom du pool d'identités de charge de travail associé à votre parc. Cette valeur utilise la syntaxe FLEET_PROJECT_ID.svc.id.goog.
Créez un espace de noms Kubernetes. Vous pouvez également utiliser n'importe quel espace de noms existant, y compris l'espace de noms default.
```
kubectl create namespace NAMESPACE
```
Remplacez NAMESPACE par le nom de l'espace de noms.
Créez un compte de service Kubernetes dans l'espace de noms. Vous pouvez également utiliser n'importe quel compte de service existant, y compris le compte de service default dans l'espace de noms.
```
kubectl create serviceaccount KSA_NAME \
    --namespace=NAMESPACE
```
Remplacez KSA_NAME par le nom du compte de service.

Enregistrez le fichier manifeste suivant sous le nom adc-config-map.yaml. Ce ConfigMap contient la configuration ADC pour les charges de travail.

kind: ConfigMap
apiVersion: v1
metadata:
  namespace: NAMESPACE
  name: my-cloudsdk-config
data:
  config: |
    {
      "type": "external_account",
      "audience": "identitynamespace:WORKLOAD_IDENTITY_POOL: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"
      }
    }

Déployez le ConfigMap :
```
kubectl create -f adc-config-map.yaml
```

Enregistrez le manifeste suivant sous le nom workload-config.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace:  NAMESPACE
spec:
  serviceAccountName: KSA_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: WORKLOAD_IDENTITY_POOL
          expirationSeconds: 172800
      - configMap:
          name: my-cloudsdk-config
          optional: false
          items:
          - key: "config"
            path: "google-application-credentials.json"

Lorsque vous déployez cette charge de travail, le volume gcp-ksa du pod contient les données suivantes :

Les données du ConfigMap que vous avez déployé en tant que fichier nommé google-application-credentials.json. Ce fichier est un fichier de configuration des identifiants ADC.
Le jeton de compte de service Kubernetes en tant que token. Kubernetes installe un JWT signé pour le compte de service en tant que fichier de jeton de compte de service projeté.

Le conteneur du pod installe le volume gcp-ksa sur le /var/run/secrets/tokens/gcp-ksa chemin d'accès et configure ADC pour rechercher le fichier JSON de configuration des identifiants dans ce chemin d'accès.

Déployer la charge de travail :
```
kubectl apply -f workload-config.yaml
```

Autre solution : emprunter l'identité d'un compte de service IAM

Vous pouvez également configurer des comptes de service Kubernetes dans vos clusters pour emprunter l'identité de comptes de service IAM et effectuer toutes les actions autorisées que les comptes de service IAM peuvent effectuer. Cette approche peut augmenter la charge de maintenance, car vous devez gérer les paires de comptes de service dans IAM et Kubernetes.

Dans la plupart des cas, nous vous recommandons de référencer directement les comptes principaux Kubernetes dans les stratégies d'autorisation IAM pour accorder l'accès aux Google Cloud ressources en suivant les instructions de la section Utiliser la fédération d'identité de charge de travail de parc dans les applications.

Recherchez le nom de votre pool d'identités de charge de travail de cluster et de votre fournisseur d'identité :
```
gcloud container fleet memberships describe MEMBERSHIP_ID \
    --project=FLEET_PROJECT_ID \
    --format="table(authority.identityProvider,authority.workloadIdentityPool,name)"
```
Remplacez les éléments suivants :
- MEMBERSHIP_ID : nom de l'abonnement au cluster . Il s'agit souvent du nom de votre cluster.
- FLEET_PROJECT_ID: ID du projet hôte du parc.
Le résultat ressemble à ce qui suit :
```
IDENTITY_PROVIDER: IDENTITY_PROVIDER
WORKLOAD_IDENTITY_POOL: WORKLOAD_IDENTITY_POOL
NAME: projects/FLEET_PROJECT_ID/locations/MEMBERSHIP_LOCATION/memberships/MEMBERSHIP_ID
```
Ce résultat contient les informations suivantes :
- IDENTITY_PROVIDER: fournisseur d'identité du cluster.
- MEMBERSHIP_LOCATION: emplacement de l'abonnement. Il s'agit généralement du même emplacement que celui de votre cluster.
- WORKLOAD_IDENTITY_POOL : nom du pool d'identités de charge de travail associé à votre parc. Cette valeur utilise la syntaxe FLEET_PROJECT_ID.svc.id.goog.
Créez un compte de service IAM que votre application peut emprunter. Vous pouvez également utiliser n'importe quel compte de service IAM existant.
```
gcloud iam service-accounts create IAM_SA_NAME \
    --project=IAM_SA_PROJECT_ID
```
Remplacez les éléments suivants :
- IAM_SA_NAME: nom de votre compte de service IAM.
- IAM_SA_PROJECT_ID: ID du projet contenant votre compte de service IAM. Il peut être différent de votre projet hôte de parc.
Accordez au compte de service IAM toutes les autorisations dont il a besoin pour accéder aux Google Cloud API en ajoutant les stratégies d'autorisation IAM nécessaires. Pour ce faire, vous pouvez utiliser gcloud iam service-accounts add-iam-policy-binding ou une autre méthode. Pour connaître les autorisations requises pour utiliser les Google Cloud API dans la documentation de chaque service, consultez la liste complète des rôles prédéfinis avec les autorisations nécessaires dans la page Comprendre les rôles.
Créez un compte de service Kubernetes dans un espace de noms. Vous pouvez également utiliser un compte de service Kubernetes existant et n'importe quel espace de noms, y compris le compte de service default et l'espace de noms default.
```
kubectl create serviceaccount KSA_NAME \
    --namespace=NAMESPACE
```
Remplacez les éléments suivants :
- KSA_NAME : nom du compte de service.
- NAMESPACE : nom de l'espace de noms.

Créez une stratégie d'autorisation IAM qui permet à un compte de service Kubernetes dans un espace de noms spécifique de votre cluster d'emprunter l'identité du compte de service IAM :

gcloud iam service-accounts add-iam-policy-binding IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com \
    --project=IAM_SA_PROJECT_ID \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:WORKLOAD_IDENTITY_POOL[NAMESPACE/KSA_NAME]"

Remplacez WORKLOAD_IDENTITY_POOL par le nom du pool d'identités de charge de travail.

Enregistrez le fichier manifeste suivant sous le nom adc-config-map.yaml. Ce ConfigMap contient la configuration ADC pour les charges de travail.

kind: ConfigMap
apiVersion: v1
metadata:
  namespace: K8S_NAMESPACE
  name: my-cloudsdk-config
data:
  config: |
    {
      "type": "external_account",
      "audience": "identitynamespace:WORKLOAD_IDENTITY_POOL:IDENTITY_PROVIDER",
      "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/IAM_SA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com:generateAccessToken",
      "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 :

IAM_SA_NAME: nom du compte de service IAM à emprunter.
IAM_SA_PROJECT_ID: ID du projet du compte de service IAM.

Enregistrez le manifeste suivant sous le nom workload-config.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace:  K8S_NAMESPACE
spec:
  serviceAccountName: KSA_NAME
  containers:
  - name: my-container
    image: my-image
    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: WORKLOAD_IDENTITY_POOL
          expirationSeconds: 172800
      - configMap:
          name: my-cloudsdk-config
          optional: false
          items:
            - key: "config"
              path: "google-application-credentials.json"

Lorsque vous déployez cette charge de travail, le volume gcp-ksa du pod contient les données suivantes :

Les données du ConfigMap que vous avez déployé en tant que fichier nommé google-application-credentials.json. Ce fichier est un fichier de configuration des identifiants ADC.
Le jeton de compte de service Kubernetes en tant que token. Kubernetes installe un JWT signé pour le compte de service en tant que fichier de jeton de compte de service projeté.

Déployer la charge de travail :
```
kubectl apply -f workload-config.yaml
```

Vérifier la configuration de la fédération d'identité de charge de travail de parc

Dans cette section, vous allez créer un bucket Cloud Storage et y accéder à partir d'un pod qui utilise la fédération d'identité de charge de travail de parc. Avant d'effectuer ces étapes, assurez-vous d'avoir configuré la fédération d'identité de charge de travail en suivant les instructions de la section Utiliser la fédération d'identité de charge de travail de parc dans les applications.

Cette section ne vous explique pas comment vérifier la fédération d'identité de charge de travail à l'aide de la méthode d'emprunt d'identité d'un compte de service IAM.

Recherchez votre numéro de projet numérique :

gcloud projects describe FLEET_PROJECT_ID \
    --format="value(projectNumber)"

Le résultat ressemble à ce qui suit :

1234567890

Créez un bucket Cloud Storage :

gcloud storage buckets create gs://FLEET_PROJECT_ID-test-bucket \
    --location=LOCATION

Remplacez LOCATION par un Google Cloud emplacement.

Créez une stratégie d'autorisation IAM qui accorde l'accès au bucket au compte de service que vous avez créé :
```
gcloud storage buckets add-iam-policy-binding gs://FLEET_PROJECT_ID-test-bucket \
    --condition=None \
    --role=roles/storage.objectViewer \
    --member=principal://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/FLEET_PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME
```
Remplacez les éléments suivants :
- FLEET_PROJECT_NUMBER: votre numéro de projet numérique.
- FLEET_PROJECT_ID : ID du projet.
- NAMESPACE: nom de l'espace de noms Kubernetes qui exécute votre pod à partir de la section précédente.
- KSA_NAME: nom du compte de service Kubernetes utilisé par votre pod à partir de la section précédente.
Bonne pratique : Créez des stratégies d'autorisation IAM qui accordent le moins d'autorisations possible sur la ressource spécifique à laquelle la charge de travail doit accéder.

Ouvrez une session shell dans le pod :

kubectl exec -it pods/my-pod --namespace=NAMESPACE -- /bin/bash

Essayez de répertorier 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_PROJECT_ID-test-bucket/o"

Le résultat est le suivant :

{
  "kind": "storage#objects"
}

S'authentifier à partir du code

Lorsque vous utilisez les bibliothèques clientes Cloud, les bibliothèques d'authentification utilisent automatiquement ADC pour rechercher les identifiants permettant de s'authentifier auprès des Google Cloud services. Vous devez utiliser les bibliothèques clientes Cloud compatibles avec la fédération d'identité de charge de travail. Vous trouverez ci-dessous les versions minimales requises des bibliothèques clientes Cloud, ainsi que des instructions pour la vérification de votre version actuelle :

C++

La plupart des Google Cloud bibliothèques clientes pour C++ sont compatibles avec la fédération d'identité à l'aide d'un ChannelCredentials objet, créé en appelant grpc::GoogleDefaultCredentials(). Pour initialiser cet identifiant, vous devez créer les bibliothèques clientes avec la version 1.36.0 ou ultérieure de gRPC.

La bibliothèque cliente Cloud Storage pour C++ utilise l'API REST et non gRPC. Elle n'est donc pas compatible avec la fédération d'identités.

Go

Les bibliothèques clientes pour Go sont compatibles avec la fédération d'identité si elles utilisent la version 0.0.0-20210218202405-ba52d332ba99 ou une version ultérieure du module golang.org/x/oauth2.

Pour vérifier quelle version de ce module est utilisée par votre bibliothèque cliente, exécutez les commandes suivantes :

cd $GOPATH/src/cloud.google.com/go
go list -m golang.org/x/oauth2

Java

Les bibliothèques clientes pour Java sont compatibles avec la fédération d'identité si elles utilisent la version 0.24.0 ou une version ultérieure de l'artefact com.google.auth:google-auth-library-oauth2-http.

Pour vérifier la version de cet artefact utilisée par votre bibliothèque cliente, exécutez la commande Maven suivante dans le répertoire de votre application :

mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http

Node.js

Les bibliothèques clientes pour Node.js sont compatibles avec la fédération d'identité si elles utilisent la version 7.0.2 ou ultérieure du package google-auth-library.

Pour vérifier la version de ce package utilisée par votre bibliothèque cliente, exécutez la commande suivante dans le répertoire de votre application :

npm list google-auth-library

Lorsque vous créez un objet GoogleAuth, vous pouvez spécifier un ID de projet ou autoriser GoogleAuth à le trouver automatiquement. Pour trouver automatiquement l'ID du projet, le compte de service dans le fichier de configuration doit disposer du rôle de visiteur (roles/browser) ou d'un rôle avec des autorisations équivalentes sur votre projet. Pour en savoir plus, consultez la section README du package google-auth-library.

Python

Les bibliothèques clientes pour Python sont compatibles avec la fédération d'identité si elles utilisent la version 1.27.0 ou ultérieure du package google-auth.

Pour vérifier la version de ce package utilisée par votre bibliothèque cliente, exécutez la commande suivante dans l'environnement dans lequel le package est installé :

pip show google-auth

Pour spécifier un ID de projet pour le client d'authentification, vous pouvez définir la variable d'environnement GOOGLE_CLOUD_PROJECT ou autoriser le client à trouver automatiquement l'ID du projet. Pour trouver automatiquement l'ID du projet, le compte de service dans le fichier de configuration doit disposer du rôle de visiteur (roles/browser) ou d'un rôle avec des autorisations équivalentes sur votre projet. Pour en savoir plus, consultez le guide de l'utilisateur du google-auth package.

Étape suivante

Découvrez les bonnes pratiques pour organiser vos parcs lorsque vous utilisez la fédération d'identité de charge de travail de parc.