**Aidez à améliorer cette page** 

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Attribuer un rôle IAM à un compte de service Kubernetes
<a name="pod-id-association"></a>

Cette rubrique explique comment configurer un compte de service Kubernetes pour qu'il assume un rôle de gestion des AWS identités et des accès (IAM) avec EKS Pod Identity. Tous les pods configurés pour utiliser le compte de service peuvent ensuite accéder à tout AWS service auquel le rôle est autorisé à accéder.

Pour créer une association EKS Pod Identity, il n'y a qu'une seule étape : vous créez l'association dans EKS via la AWS Management Console AWS CLI AWS CloudFormation et d'autres outils. AWS SDKs Il n’y a aucune donnée ou métadonnée concernant les associations à l’intérieur du cluster dans les objets Kubernetes et vous n’ajoutez aucune annotation aux comptes de service.

 **Conditions préalables** 
+ Un cluster existant. Si vous n’en avez pas, vous pouvez en créer un en suivant l’un des guides [Mise en route avec Amazon EKS](getting-started.md).
+ Le principal IAM qui crée l’association doit avoir le `iam:PassRole`.
+ La dernière version de la AWS CLI installée et configurée sur votre appareil ou AWS CloudShell. Vous pouvez vérifier votre version actuelle avec `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Les gestionnaires de packages tels que `yum``apt-get`, ou Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI. Pour installer la dernière version, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) et [configuration rapide avec aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) dans le Guide de l'utilisateur de l'interface de ligne de AWS commande. La version de la AWS CLI installée dans le AWS CloudShell peut également avoir plusieurs versions de retard par rapport à la dernière version. Pour le mettre à jour, consultez la section [Installation de la AWS CLI dans votre répertoire](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) de base dans le guide de AWS CloudShell l'utilisateur.
+ L'outil de ligne de commande `kubectl` est installé sur votre appareil ou AWS CloudShell. La version peut correspondre à celle utilisée par votre cluster Kubernetes, ou différer d’au plus une version mineure, qu’elle soit antérieure ou plus récente. Par exemple, si la version de votre cluster est `1.29`, vous pouvez utiliser la version `kubectl` `1.28`, `1.29` ou `1.30`. Pour installer ou mettre à niveau `kubectl`, veuillez consulter [Configuration de `kubectl` et `eksctl`](install-kubectl.md).
+ Un fichier existant `kubectl` `config` qui contient la configuration de votre cluster. Pour créer un fichier `kubectl` `config`, consultez [Connexion de kubectl à un cluster EKS en créant un fichier kubeconfig](create-kubeconfig.md).

## Création d'une association Pod Identity (AWS console)
<a name="pod-id-association-create"></a>

1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. Dans le panneau de navigation de gauche, sélectionnez **Clusters**, puis sélectionnez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire l’agent d’identité du pod EKS.

1. Choisissez l’onglet **Access**.

1. Dans **Associations d’identité du pod**, sélectionnez **Créer**.

1. Pour **Rôle IAM**, sélectionnez le rôle IAM avec les autorisations dont a besoin la charge de travail.
**Note**  
La liste ne contient que les rôles qui ont la politique d’approbation suivante qui permet à l’identité du pod EKS de les utiliser.

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
               "Effect": "Allow",
               "Principal": {
                   "Service": "pods.eks.amazonaws.com"
               },
               "Action": [
                   "sts:AssumeRole",
                   "sts:TagSession"
               ]
           }
       ]
   }
   ```

    `sts:AssumeRole` : l’identité du pod EKS utilise `AssumeRole` pour assumer le rôle IAM avant de transmettre les informations d’identification temporaires à vos pods.

    `sts:TagSession`— EKS Pod Identity est utilisé `TagSession` pour inclure des *balises de session* dans les demandes adressées à AWS STS.

   Vous pouvez utiliser ces balises dans les *clés de condition* de la politique d’approbation pour restreindre les comptes de service, les espaces de noms et les clusters pouvant utiliser ce rôle.

   Pour obtenir la liste des clés de condition Amazon EKS, consultez la rubrique [Conditions définies par Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) de la *Référence de l'autorisation de service*. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez la rubrique [Actions définies par Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).

1. Pour l’**espace de noms Kubernetes**, sélectionnez l’espace de noms Kubernetes qui contient le compte de service et la charge de travail. Vous pouvez également spécifier un espace de noms par son nom qui n’existe pas dans le cluster.

1. Pour le **compte de service Kubernetes**, sélectionnez le compte de service Kubernetes à utiliser. Le manifeste de votre charge de travail Kubernetes doit spécifier ce compte de service. Vous pouvez également spécifier un compte de service par son nom qui n’existe pas dans le cluster.

1. (Facultatif) Sélectionnez **Désactiver les balises de session** pour désactiver les balises de session par défaut que Pod Identity ajoute automatiquement lorsqu'il assume le rôle.

1. (Facultatif) Activez l'option **Configurer la politique de session** pour configurer une politique IAM afin d'appliquer des restrictions supplémentaires à cette association Pod Identity au-delà des autorisations définies dans la stratégie IAM attachée au rôle IAM.
**Note**  
Une politique de session ne peut être appliquée que lorsque le paramètre **Désactiver les balises de session** est coché.

1. (Facultatif) Pour **Balises**, choisissez **Ajouter une balise** pour ajouter des métadonnées dans une paire clé et valeur. Ces balises sont appliquées à l’association et peuvent être utilisées dans les politiques IAM.

   Vous pouvez répéter cette étape pour ajouter plusieurs balises.

1. Choisissez **Créer**.

## Création d'une association Pod Identity (AWS CLI)
<a name="create_a_pod_identity_association_shared_aws_cli"></a>

1. Si vous souhaitez associer une politique IAM existante à votre rôle IAM, passez à l'étape suivante.

   Créez une politique IAM. Vous pouvez créer votre propre politique ou copier une politique AWS gérée qui accorde déjà certaines des autorisations dont vous avez besoin et la personnaliser en fonction de vos besoins spécifiques. Pour plus d’informations, consultez [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.

   1. Créez un fichier qui inclut les autorisations pour les AWS services auxquels vous souhaitez que vos pods accèdent. Pour obtenir la liste de toutes les actions pour tous les AWS services, consultez la [référence d'autorisation des services](https://docs.aws.amazon.com/service-authorization/latest/reference/).

      Vous pouvez exécuter la commande suivante pour créer un exemple de fichier de politique autorisant l'accès en lecture seule à un compartiment Amazon S3. Vous pouvez, si vous le souhaitez, stocker des informations de configuration ou un script d’amorçage dans ce compartiment et les conteneurs de votre pod pourront lire le fichier dans le compartiment et le charger dans votre application. Si vous souhaitez créer cet exemple de politique, copiez le contenu suivant sur votre appareil. *my-pod-secrets-bucket*Remplacez-le par le nom de votre compartiment et exécutez la commande.

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": "s3:GetObject",
                  "Resource": "arn:aws:s3:::my-pod-secrets-bucket"
              }
          ]
      }
      ```

   1. Créez la politique IAM.

      ```
      aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
      ```

1. Créez un rôle IAM, puis associez-le à un compte de service Kubernetes.

   1. Si vous avez déjà un compte de service Kubernetes devant assumer un rôle IAM, vous pouvez ignorer cette étape.

      Créez un compte de service Kubernetes. Copiez les contenus suivants sur votre appareil. *my-service-account*Remplacez-le par le nom de votre choix et *default* par un autre espace de noms, si nécessaire. Si vous modifiez*default*, l'espace de noms doit déjà exister.

      ```
      cat >my-service-account.yaml <<EOF
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: my-service-account
        namespace: default
      EOF
      kubectl apply -f my-service-account.yaml
      ```

      Exécutez la commande suivante.

      ```
      kubectl apply -f my-service-account.yaml
      ```

   1. Exécutez la commande suivante pour créer un fichier de stratégie d'approbation pour le rôle IAM.

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
                  "Effect": "Allow",
                  "Principal": {
                      "Service": "pods.eks.amazonaws.com"
                  },
                  "Action": [
                      "sts:AssumeRole",
                      "sts:TagSession"
                  ]
              }
          ]
      }
      ```

   1. Créez le rôle. Remplacez *my-role* avec un nom pour votre rôle IAM, et *my-role-description* avec une description de votre rôle.

      ```
      aws iam create-role --role-name my-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"
      ```

   1. Liez une politique IAM à votre rôle. Remplacez *my-role* par le nom de votre rôle IAM et *my-policy* par le nom d'une politique existante que vous avez créée.

      ```
      aws iam attach-role-policy --role-name my-role --policy-arn=arn:aws: iam::111122223333:policy/my-policy
      ```
**Note**  
Contrairement aux rôles IAM pour les comptes de service, l’identité du pod EKS n’utilise pas d’annotation sur le compte de service.

   1. Exécutez la commande suivante pour créer l’association. `my-cluster`Remplacez-le par le nom du cluster, remplacez-le *my-service-account* par le nom de votre choix et *default* par un autre espace de noms, si nécessaire.

      ```
      aws eks create-pod-identity-association --cluster-name my-cluster --role-arn arn:aws: iam::111122223333:role/my-role --namespace default --service-account my-service-account
      ```

      L'exemple qui suit illustre un résultat.

      ```
      {
          "association": {
              "clusterName": "my-cluster",
              "namespace": "default",
              "serviceAccount": "my-service-account",
              "roleArn": "arn:aws: iam::111122223333:role/my-role",
              "associationArn": "arn:aws::111122223333:podidentityassociation/my-cluster/a-abcdefghijklmnop1",
              "associationId": "a-abcdefghijklmnop1",
              "tags": {},
              "createdAt": 1700862734.922,
              "modifiedAt": 1700862734.922
          }
      }
      ```
**Note**  
Vous pouvez spécifier un espace de noms et un compte de service par leur nom qui n’existent pas dans le cluster. Vous devez créer l’espace de noms, le compte de service et la charge de travail qui utilise le compte de service pour que l’association de l’identité du pod EKS fonctionne.

## Confirmer la configuration
<a name="pod-id-confirm-role-configuration"></a>

1. Vérifiez que la stratégie d’approbation du rôle IAM est correctement configurée.

   ```
   aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
   ```

   L'exemple qui suit illustre un résultat.

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "Allow EKS Auth service to assume this role for Pod Identities",
               "Effect": "Allow",
               "Principal": {
                   "Service": "pods.eks.amazonaws.com"
               },
               "Action": [
                   "sts:AssumeRole",
                   "sts:TagSession"
               ]
           }
       ]
   }
   ```

1. Vérifiez que la stratégie que vous avez associée à votre rôle lors d'une étape précédente est associée au rôle.

   ```
   aws iam list-attached-role-policies --role-name my-role --query 'AttachedPolicies[].PolicyArn' --output text
   ```

   L'exemple qui suit illustre un résultat.

   ```
    arn:aws: iam::111122223333:policy/my-policy
   ```

1. Définissez une variable pour stocker l'Amazon Resource Name (ARN) de la stratégie que vous souhaitez utiliser. *my-policy*Remplacez-le par le nom de la politique pour laquelle vous souhaitez confirmer les autorisations.

   ```
   export policy_arn=arn:aws: iam::111122223333:policy/my-policy
   ```

1. Affichez la version par défaut de la stratégie.

   ```
   aws iam get-policy --policy-arn $policy_arn
   ```

   L'exemple qui suit illustre un résultat.

   ```
   {
       "Policy": {
           "PolicyName": "my-policy",
           "PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
           "Arn": "arn:aws: iam::111122223333:policy/my-policy",
           "Path": "/",
           "DefaultVersionId": "v1",
           [...]
       }
   }
   ```

1. Consultez le contenu de la stratégie pour vous assurer qu’elle inclut toutes les autorisations nécessaires pour votre pod. Si nécessaire, remplacez *1* la commande suivante par la version renvoyée dans la sortie précédente.

   ```
   aws iam get-policy-version --policy-arn $policy_arn --version-id v1
   ```

   L'exemple qui suit illustre un résultat.

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::my-pod-secrets-bucket"
           }
       ]
   }
   ```

   Si vous avez créé l'exemple de stratégie lors d'une étape précédente, le résultat est le même. Si vous avez créé une politique différente, le *example* contenu est différent.

## Étapes suivantes
<a name="_next_steps"></a>

 [Configurer les pods pour accéder aux AWS services avec des comptes de service](pod-id-configure-pods.md)