Cette documentation concerne la version actuelle de GKE sur AWS, publiée en novembre 2021. Consultez les notes de version pour plus d'informations.

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

Utiliser Workload Identity avec AWS

Workload Identity vous permet d'attribuer des identités et une autorisation distinctes et précises pour chaque application du cluster. Workload Identity est la méthode recommandée pour que les applications s'exécutant dans GKE sur AWS puissent accéder aux services AWS et Google Cloud. Pour en savoir plus, consultez la page concernant Workload Identity.

Cette rubrique explique comment créer un fournisseur OIDC, provisionner des comptes de service et tester un exemple de charge de travail à l'aide de Workload Identity.

Créer un fournisseur OIDC AWS IAM pour votre cluster

Pour utiliser Workload Identity avec votre cluster, vous devez d'abord créer un fournisseur OIDC AWS IAM qui référence votre cluster. Si vous disposez déjà d'un fournisseur IAM OIDC pour votre cluster, vous pouvez ignorer cette section.

Pour créer le fournisseur, procédez comme suit :

Déterminez l'URI d'émetteur OIDC pour votre cluster :
```
gcloud container aws clusters describe CLUSTER_NAME \
     --location=GOOGLE_CLOUD_LOCATION \
     --format='value(workloadIdentityConfig.issuerUri)'
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster
- GOOGLE_CLOUD_LOCATION : nom de l'emplacement Google Cloud à partir duquel ce pool de nœuds sera géré, comme défini dans les régions de gestion de Google Cloud.
Le résultat inclut l'URI d'émetteur OIDC de votre cluster. Enregistrez cette valeur pour l'étape suivante.
Créez ensuite un fournisseur OIDC AWS IAM qui référence votre cluster à l'aide de la commande suivante :
```
aws iam create-open-id-connect-provider \
    --url ISSUER_URI \
    --client-id-list sts.amazonaws.com \
    --thumbprint-list 08745487e891c19e3078c1f2a07e452950ef36f6
```
Remplacez ISSUER_URI par votre URI d'émetteur de l'étape précédente.

La thumbprint du service Google Cloud qui diffuse l'URI de l'émetteur est toujours 08745487e891c19e3078c1f2a07e452950ef36f6.

Configurer un rôle AWS IAM associé à une stratégie IAM

Pour configurer un rôle AWS IAM et lui associer une stratégie, procédez comme suit :

Déterminez l'hôte émetteur en supprimant le préfixe https:// de l'URI de l'émetteur. Par exemple, si votre URI est https://oidc-provider.com/v1/projects/pid/locations/us-west1/awsClusters/awscluster, l'hôte est oidc-provider.com/v1/projects/pid/locations/us-west1/awsClusters/awscluster. Enregistrez cette valeur. Vous en aurez besoin ultérieurement.
Déterminez le nom de ressource Amazon (ARN) du fournisseur en exécutant la commande suivante :
```
aws iam list-open-id-connect-providers --output=text \
    --query 'OpenIDConnectProviderList[?ends_with(Arn, `ISSUER_HOST`) == `true`].Arn'
```
Remplacez ISSUER_HOST par le nom d'hôte de l'URI d'émetteur pour le cluster.
Ensuite, créez une règle d'approbation pour fournir des identifiants OIDC au compte de service Kubernetes. Créez un fichier nommé trust-policy.json avec le contenu suivant :
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "PROVIDER_ARN"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "ISSUER_HOST:sub": "system:serviceaccount:NAMESPACE:KSA_NAME"
        }
      }
    }
  ]
}
```
Remplacez les éléments suivants :
- PROVIDER_ARN : ARN du fournisseur OIDC IAM du cluster
- ISSUER_HOST: nom d'hôte de l'URI de l'émetteur pour le cluster.
- NAMESPACE : espace de noms Kubernetes dans lequel l'application s'exécute
- KSA_NAME : compte de service Kubernetes (KSA) à utiliser pour l'application

Créez un rôle AWS IAM :

aws iam create-role --role-name=AWS_ROLE_NAME \
    --assume-role-policy-document file://trust-policy.json

Remplacez AWS_ROLE_NAME par le nom du rôle AWS IAM pour l'application.

Associez une stratégie AWS IAM au rôle :
```
aws iam attach-role-policy --role-name=AWS_ROLE_NAME \
    --policy-arn=AWS_POLICY_ARN
```
Remplacez les éléments suivants :
- AWS_ROLE_NAME: nom du rôle IAM AWS pour l'application
Par exemple, pour créer un rôle nommé ec2-readonly, avec la stratégie arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess, exécutez la commande suivante :
```
aws iam attach-role-policy --role-name=ec2-readonly \
    --policy-arn=arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
```

Déploiement d'un exemple d'application

Pour tester Workload Identity, procédez comme suit pour déployer un exemple d'application :

Déterminez l'ARN du rôle :

aws iam get-role --role-name=AWS_ROLE_NAME --query 'Role.Arn'

Remplacez AWS_ROLE_NAME.

Créez un fichier manifeste pour un espace de noms Kubernetes, un KSA et un pod. Copiez le fichier manifeste YAML suivant dans un fichier nommé workload-identity-test.yaml.

apiVersion: v1
kind: Namespace
metadata:
  name: NAMESPACE
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: KSA_NAME
  namespace: NAMESPACE
automountServiceAccountToken: false
---
apiVersion: v1
kind: Pod
metadata:
  name: aws-cli-example
  namespace: NAMESPACE
spec:
  serviceAccount: KSA_NAME
  containers:
  - name: aws-cli
    image: amazon/aws-cli:latest
    command:
    - /bin/bash
    - -c
    - "set -eu -o pipefail; while true; do aws ec2 describe-availability-zones; sleep 5; done"
    env:
    - name: AWS_ROLE_ARN
      value: AWS_ROLE_ARN
    - name: AWS_WEB_IDENTITY_TOKEN_FILE
      value: /var/run/secrets/aws-iam-token/serviceaccount/token
    - name: AWS_REGION
      value: AWS_REGION
    volumeMounts:
    - mountPath: /var/run/secrets/aws-iam-token/serviceaccount
      name: aws-iam-token
      readOnly: true
  volumes:
  - name: aws-iam-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: sts.amazonaws.com
          expirationSeconds: 86400
          path: token

Remplacez les éléments suivants :

NAMESPACE
KSA_NAME
AWS_ROLE_ARN : ARN du rôle AWS IAM pour l'application
AWS_REGION : région AWS du cluster

Appliquer le fichier manifeste :
```
kubectl apply -f workload-identity-test.yaml
```
Attendez quelques minutes que le pod démarre, puis passez à la section suivante.

Vérifier que l'exemple d'application fonctionne

Pour vérifier que l'exemple d'application peut accéder à l'API EC2, consultez les journaux du pod :

kubectl logs -f aws-cli-example -n NAMESPACE

Si le pod peut accéder à l'API EC2, le résultat inclut des informations sur les zones de disponibilité EC2 et se présente comme suit :

-------------------------------------------------
|           DescribeAvailabilityZones           |
+-----------------------------------------------+
||              AvailabilityZones              ||
|+---------------------+-----------------------+|
||  GroupName          |  us-west-2            ||
||  NetworkBorderGroup |  us-west-2            ||
||  OptInStatus        |  opt-in-not-required  ||
||  RegionName         |  us-west-2            ||
||  State              |  available            ||
||  ZoneId             |  usw2-az1             ||
||  ZoneName           |  us-west-2a           ||
|+---------------------+-----------------------+|
||              AvailabilityZones              ||
|+---------------------+-----------------------+|
||  GroupName          |  us-west-2            ||
||  NetworkBorderGroup |  us-west-2            ||
||  OptInStatus        |  opt-in-not-required  ||
||  RegionName         |  us-west-2            ||
||  State              |  available            ||
||  ZoneId             |  usw2-az2             ||
||  ZoneName           |  us-west-2b           ||
|+---------------------+-----------------------+|
||              AvailabilityZones              ||
|+---------------------+-----------------------+|
||  GroupName          |  us-west-2            ||
||  NetworkBorderGroup |  us-west-2            ||
||  OptInStatus        |  opt-in-not-required  ||
||  RegionName         |  us-west-2            ||
||  State              |  available            ||
||  ZoneId             |  usw2-az3             ||
||  ZoneName           |  us-west-2c           ||
|+---------------------+-----------------------+|
||              AvailabilityZones              ||
|+---------------------+-----------------------+|
||  GroupName          |  us-west-2            ||
||  NetworkBorderGroup |  us-west-2            ||
||  OptInStatus        |  opt-in-not-required  ||
||  RegionName         |  us-west-2            ||
||  State              |  available            ||
||  ZoneId             |  usw2-az4             ||
||  ZoneName           |  us-west-2d           ||
|+---------------------+-----------------------+|

Effectuer un nettoyage

Pour supprimer cet exemple d'application, procédez comme suit :

Supprimez le fichier manifeste de l'exemple d'application de votre cluster :
```
kubectl delete -f workload-identity-test.yaml
```

Dissociez la stratégie AWS IAM du rôle :

aws iam detach-role-policy --role-name AWS_ROLE_NAME \
    --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

Remplacez AWS_ROLE_NAME par le nom du rôle AWS IAM pour l'application.

Supprimez le rôle AWS IAM :
```
aws iam delete-role --role-name AWS_ROLE_NAME
```
Remplacez AWS_ROLE_NAME par le nom du rôle AWS IAM pour l'application.
Supprimez le fournisseur OIDC AWS IAM :
```
aws iam delete-open-id-connect-provider --open-id-connect-provider-arn PROVIDER_ARN
```
Remplacez PROVIDER_ARN par l'ARN du fournisseur OIDC IAM pour le cluster.

Étapes suivantes

Découvrez comment utiliser Workload Identity avec les services Google Cloud.