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 solution recommandée pour que les applications exécutées 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 :

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

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

    L'empreinte du service Google Cloud qui diffuse l'URI d'é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 :

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

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

  3. 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
  4. 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.

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

  1. Déterminez l'ARN du rôle :

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

    Remplacez AWS_ROLE_NAME.

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

  1. Supprimez le fichier manifeste de l'exemple d'application de votre cluster :

    kubectl delete -f workload-identity-test.yaml
    
  2. 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.

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

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

Étape suivante