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.

# Configuration d'Amazon EMR on EKS
<a name="setting-up"></a>

Effectuez les tâches suivantes pour vous préparer à utiliser Amazon EMR on EKS. Si vous êtes déjà inscrit à Amazon Web Services (AWS) et que vous utilisez Amazon EKS, vous êtes presque prêt à utiliser Amazon EMR on EKS. Ignorez toutes les tâches que vous avez déjà effectuées.

**Note**  
Vous pouvez également suivre l'[atelier Amazon EMR on EKS](https://emr-on-eks.workshop.aws/amazon-emr-eks-workshop.html) pour configurer toutes les ressources nécessaires à l'exécution des tâches Spark sur Amazon EMR on EKS. L'atelier fournit également une automatisation en utilisant des CloudFormation modèles pour créer les ressources nécessaires à votre démarrage. Pour d'autres modèles et meilleures pratiques, consultez notre [guide des meilleures pratiques en matière de conteneurs EMR](https://aws.github.io/aws-emr-containers-best-practices/) sur. GitHub

1. [Installez ou mettez à jour vers la dernière version du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)

1. [Configurez kubectl et eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html).

1. [Commencez avec Amazon EKS — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)

1. [Activer l'accès au cluster pour Amazon EMR sur EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html)

1. [Activer les rôles IAM pour le cluster EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM-roles.html)

1. [Autorisation des utilisateurs à accéder à Amazon EMR on EKS](setting-up-iam.md)

1. [Enregistrement du cluster Amazon EKS dans Amazon EMR](setting-up-registration.md)

# Activation de l'accès aux clusters pour Amazon EMR on EKS
<a name="setting-up-cluster-access"></a>

Les sections suivantes présentent deux manières d'activer l'accès au cluster. La première consiste à utiliser la gestion de l'accès au cluster (CAM) d'Amazon EKS et la seconde montre comment effectuer des étapes manuelles pour activer l'accès au cluster.

## Activer l'accès au cluster à l'aide d'EKS Access Entry (recommandé)
<a name="setting-up-cluster-access-cam-integration"></a>

**Note**  
`aws-auth` ConfigMap est obsolète. [La méthode recommandée pour gérer l'accès à Kubernetes APIs est celle des entrées d'accès.](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html)

Amazon EMR est intégré à la [gestion des accès aux clusters (CAM) d'Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html), ce qui vous permet d'automatiser la configuration des politiques AuthN et AuthZ nécessaires pour exécuter des tâches Amazon EMR Spark dans les espaces de noms des clusters Amazon EKS. Lorsque vous créez un cluster virtuel à partir d'un espace de noms de cluster Amazon EKS, Amazon EMR configure automatiquement toutes les autorisations nécessaires, de sorte que vous n'avez pas besoin d'ajouter d'étapes supplémentaires à vos flux de travail actuels.

**Note**  
L'intégration d'Amazon EMR à Amazon EKS CAM n'est prise en charge que pour les nouveaux clusters virtuels Amazon EMR on EKS. Vous ne pouvez pas migrer des clusters virtuels existants pour utiliser cette intégration.

### Conditions préalables
<a name="setting-up-cluster-access-cam-integration-prereqs"></a>
+ Assurez-vous que vous utilisez la version 2.15.3 ou supérieure du AWS CLI
+ Votre cluster Amazon EKS doit être doté de la version 1.23 ou supérieure.

### Configuration
<a name="setting-up-cluster-access-cam-integration-setup"></a>

Pour configurer l'intégration entre Amazon EMR et les opérations d' AccessEntry API d'Amazon EKS, assurez-vous d'avoir effectué les étapes suivantes :
+ Assurez-vous que celui `authenticationMode` de votre cluster Amazon EKS est défini sur`API_AND_CONFIG_MAP`.

  ```
  aws eks describe-cluster --name <eks-cluster-name>
  ```

  Si ce n'est pas déjà le cas, réglez-le `authenticationMode` sur`API_AND_CONFIG_MAP`.

  ```
  aws eks update-cluster-config 
      --name <eks-cluster-name> 
      --access-config authenticationMode=API_AND_CONFIG_MAP
  ```

  Pour plus d'informations sur les modes d'authentification, consultez la section Modes [d'authentification de cluster](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html#authentication-modes).
+ Assurez-vous que le [rôle IAM](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html) que vous utilisez pour exécuter les opérations `CreateVirtualCluster` et `DeleteVirtualCluster` API dispose également des autorisations suivantes :

  ```
  {
    "Effect": "Allow",
    "Action": [
      "eks:CreateAccessEntry"
    ],
    "Resource": "arn:<AWS_PARTITION>:eks:<AWS_REGION>:<AWS_ACCOUNT_ID>:cluster/<EKS_CLUSTER_NAME>"
  }, 
  {
    "Effect": "Allow",
    "Action": [
      "eks:DescribeAccessEntry",
      "eks:DeleteAccessEntry",
      "eks:ListAssociatedAccessPolicies",
      "eks:AssociateAccessPolicy",
      "eks:DisassociateAccessPolicy"
    ],
    "Resource": "arn:<AWS_PARTITION>:eks:<AWS_REGION>:<AWS_ACCOUNT_ID>:access-entry/<EKS_CLUSTER_NAME>/role/<AWS_ACCOUNT_ID>/AWSServiceRoleForAmazonEMRContainers/*"
  }
  ```

### Concepts et terminologie
<a name="setting-up-cluster-access-cam-integration-concepts"></a>

Vous trouverez ci-dessous une liste de terminologies et de concepts liés à Amazon EKS CAM.
+ Cluster virtuel (VC) : représentation logique de l'espace de noms créé dans Amazon EKS. Il s'agit d'un lien 1:1 vers un espace de noms de cluster Amazon EKS. Vous pouvez l'utiliser pour exécuter des charges de travail Amazon EMR sur un cluster Amazon EKS au sein de l'espace de noms spécifié.
+ Namespace : mécanisme permettant d'isoler des groupes de ressources au sein d'un seul cluster EKS.
+ Politique d'accès : autorisations qui accordent l'accès et les actions à un rôle IAM au sein d'un cluster EKS.
+ Entrée d'accès : entrée créée à l'aide d'un rôle arn. Vous pouvez lier l'entrée d'accès à une politique d'accès pour attribuer des autorisations spécifiques dans le cluster Amazon EKS.
+ Cluster virtuel intégré d'entrée d'accès EKS : cluster virtuel créé [à l'aide des opérations d'API d'entrée d'accès](https://docs.aws.amazon.com/eks/latest/APIReference/API_Operations_Amazon_Elastic_Kubernetes_Service.html) d'Amazon EKS.

## Activez l'accès au cluster en utilisant `aws-auth`
<a name="setting-up-cluster-access-aws-auth"></a>

Vous devez autoriser Amazon EMR on EKS à accéder à un espace de noms spécifique de votre cluster en effectuant les actions suivantes : créer un rôle Kubernetes, lier le rôle à un utilisateur Kubernetes et associer l'utilisateur Kubernetes au rôle lié au service [https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/using-service-linked-roles.html](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/using-service-linked-roles.html). Ces actions sont automatisées dans `eksctl` lorsque la commande de mappage d'identité IAM est utilisée avec `emr-containers` comme nom de service. Vous pouvez effectuer ces opérations facilement à l'aide de la commande suivante.

```
eksctl create iamidentitymapping \
    --cluster my_eks_cluster \
    --namespace kubernetes_namespace \
    --service-name "emr-containers"
```

*my\$1eks\$1cluster*Remplacez-le par le nom de votre cluster Amazon EKS et remplacez-le par l'espace *kubernetes\$1namespace* de noms Kubernetes créé pour exécuter les charges de travail Amazon EMR. 

**Important**  
Vous devez télécharger la dernière version d'eksctl en suivant l'étape précédente. [Configurez kubectl et eksctl pour](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) utiliser cette fonctionnalité. 

### Étapes manuelles à suivre pour activer l'accès aux clusters pour Amazon EMR on EKS
<a name="setting-up-cluster-access-manual"></a>

Vous pouvez également suivre les étapes manuelles ci-dessous pour activer l'accès aux clusters pour Amazon EMR on EKS.

1. **Création d'un rôle Kubernetes dans un espace de noms spécifique**

------
#### [ Amazon EKS 1.22 - 1.29 ]

   Avec Amazon EKS 1.22 - 1.29, exécutez la commande suivante pour créer un rôle Kubernetes dans un espace de noms spécifique. Ce rôle accorde les autorisations RBAC nécessaires à Amazon EMR on EKS.

   ```
   namespace=my-namespace
   cat - >>EOF | kubectl apply -f - >>namespace "${namespace}"
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: emr-containers
     namespace: ${namespace}
   rules:
     - apiGroups: [""]
       resources: ["namespaces"]
       verbs: ["get"]
     - apiGroups: [""]
       resources: ["serviceaccounts", "services", "configmaps", "events", "pods", "pods/log"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
     - apiGroups: [""]
       resources: ["secrets"]
       verbs: ["create", "patch", "delete", "watch"]
     - apiGroups: ["apps"]
       resources: ["statefulsets", "deployments"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["batch"]
       resources: ["jobs"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["extensions", "networking.k8s.io"]
       resources: ["ingresses"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["rbac.authorization.k8s.io"]
       resources: ["roles", "rolebindings"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
     - apiGroups: [""]
       resources: ["persistentvolumeclaims"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete",  "deletecollection", "annotate", "patch", "label"]
   EOF
   ```

------
#### [ Amazon EKS 1.21 and below ]

   À l'aide d'Amazon EKS en version 1.21 et inférieure, exécutez la commande suivante pour créer un rôle Kubernetes dans un espace de noms spécifique. Ce rôle accorde les autorisations RBAC nécessaires à Amazon EMR on EKS.

   ```
   namespace=my-namespace
   cat - >>EOF | kubectl apply -f - >>namespace "${namespace}"
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: emr-containers
     namespace: ${namespace}
   rules:
     - apiGroups: [""]
       resources: ["namespaces"]
       verbs: ["get"]
     - apiGroups: [""]
       resources: ["serviceaccounts", "services", "configmaps", "events", "pods", "pods/log"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
     - apiGroups: [""]
       resources: ["secrets"]
       verbs: ["create", "patch", "delete", "watch"]
     - apiGroups: ["apps"]
       resources: ["statefulsets", "deployments"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["batch"]
       resources: ["jobs"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["extensions"]
       resources: ["ingresses"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["rbac.authorization.k8s.io"]
       resources: ["roles", "rolebindings"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
     - apiGroups: [""]
       resources: ["persistentvolumeclaims"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
   EOF
   ```

------

1. **Création d'une liaison de rôle Kubernetes adaptée à l'espace de noms**

   Exécutez la commande suivante pour créer une liaison de rôle Kubernetes dans l'espace de noms donné. Cette liaison de rôle accorde les autorisations définies dans le rôle créé à l'étape précédente à un utilisateur nommé `emr-containers`. Cet utilisateur identifie les [rôles liés au service pour Amazon EMR on EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/using-service-linked-roles.html) et permet ainsi à Amazon EMR on EKS d'effectuer les actions définies par le rôle que vous avez créé.

   ```
   namespace=my-namespace
   
   cat - <<EOF | kubectl apply -f - --namespace "${namespace}"
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: emr-containers
     namespace: ${namespace}
   subjects:
   - kind: User
     name: emr-containers
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: Role
     name: emr-containers
     apiGroup: rbac.authorization.k8s.io
   EOF
   ```

1. **Mise à jour la carte de configuration `aws-auth` de Kubernetes**

   Vous pouvez utiliser l'une des options suivantes pour associer le rôle lié au service Amazon EMR on EKS à l'utilisateur `emr-containers` associé au rôle Kubernetes à l'étape précédente.

   **Option 1 : utilisation de l'outil `eksctl`**

   Exécutez la commande `eksctl` suivante pour associer le rôle lié au service Amazon EMR on EKS à l'utilisateur `emr-containers`.

   ```
   eksctl create iamidentitymapping \
       --cluster my-cluster-name \
       --arn "arn:aws:iam::my-account-id:role/AWSServiceRoleForAmazonEMRContainers" \
       --username emr-containers
   ```

   **Option 2 : sans utiliser eksctl**

   1. Exécutez la commande suivante pour ouvrir la carte de configuration `aws-auth` dans l'éditeur de texte. 

      ```
      kubectl edit -n kube-system configmap/aws-auth
      ```
**Note**  
Si vous recevez un message d'erreur`Error from server (NotFound): configmaps "aws-auth" not found`, consultez les étapes décrites dans la section [Ajouter des rôles d'utilisateur](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) dans le guide de l'utilisateur Amazon EKS pour appliquer le stock ConfigMap. 

   1. Ajoutez les détails du rôle lié au service Amazon EMR on EKS dans la section `mapRoles` de la `ConfigMap`, sous `data`. Ajoutez cette section si elle n'existe pas déjà dans le fichier. La section `mapRoles` mise à jour sous les données ressemble à l'exemple suivant.

      ```
      apiVersion: v1
      data:
        mapRoles: |
          - rolearn: arn:aws:iam::<your-account-id>:role/AWSServiceRoleForAmazonEMRContainers
            username: emr-containers
          - ... <other previously existing role entries, if there's any>.
      ```

   1. Enregistrez le fichier et quittez votre éditeur de texte.

# Activer les rôles IAM pour le cluster EKS
<a name="setting-up-enable-IAM-roles"></a>

Les rubriques suivantes décrivent les options permettant d'activer les rôles IAM.

**Topics**
+ [Option 1 : activer l'identité du pod EKS sur le cluster EKS](setting-up-enable-IAM.md)
+ [Option 2 : activer les rôles IAM pour les comptes de service (IRSA) sur le cluster EKS](setting-up-enable-IAM-service-accounts.md)

# Option 1 : activer l'identité du pod EKS sur le cluster EKS
<a name="setting-up-enable-IAM"></a>

Les associations de l’identité du pod Amazon EKS offrent une capacité de gestion des informations d’identification à utiliser pour les applications, de la même façon que les profils d’instance Amazon EC2 fournissent des informations d’identification aux instances EC2. L’identité du pod Amazon EKS fournit des informations d’identification à vos charges de travail avec une API d’authentification EKS supplémentaire et un pod d’agent qui s’exécute sur chaque nœud.

Amazon EMR on EKS commence à prendre en charge l'identité des pods EKS depuis la version emr-7.3.0 pour le modèle de soumission. StartJobRun 

Pour plus d'informations sur les identités des pods EKS, reportez-vous à la section [Comprendre le fonctionnement d'EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html).

## Pourquoi choisir EKS Pod Identities ?
<a name="setting-up-enable-IAM-pod-identity-why"></a>

Dans le cadre de la configuration d'EMR, le rôle Job Execution doit établir des limites de confiance entre un rôle IAM et des comptes de service dans un espace de noms spécifique (des clusters virtuels EMR). Avec l'IRSA, cela a été réalisé en mettant à jour la politique de confiance du rôle EMR Job Execution. Cependant, en raison de la limite stricte de 4 096 caractères imposée à la politique de confiance IAM, il était nécessaire de partager un seul rôle IAM d'exécution de tâches sur un maximum de douze (12) clusters EKS.

Grâce au support d'EMR pour Pod Identities, la limite de confiance entre les rôles IAM et les comptes de service est désormais gérée par l'équipe EKS via l'association d'EKS pod identity. APIs

**Note**  
La limite de sécurité pour l'identité du pod EKS est toujours au niveau du compte de service, et non au niveau du pod.

## Considérations relatives à l'identité des
<a name="setting-up-enable-IAM-pod-identity-consider"></a>

Pour plus d'informations sur les limites relatives à l'identité des pods, consultez la section [Considérations relatives à l'identité des pods d'EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations).

## Préparer l'identité du pod EKS dans le cluster EKS
<a name="setting-up-enable-IAM-pod-eks-cluster"></a>

### Vérifiez si l'autorisation requise existe dans NodeInstanceRole
<a name="setting-up-enable-IAM-pod-eks-cluster-permission"></a>

Le rôle de nœud `NodeInstanceRole` nécessite une autorisation pour que l'agent puisse effectuer l'`AssumeRoleForPodIdentity`action dans l'API EKS Auth. Vous pouvez ajouter les éléments suivants à l'[Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/security-iam-awsmanpol.html#security-iam-awsmanpol-amazoneksworkernodepolicy), qui est défini dans le guide de l'utilisateur Amazon EKS, ou utiliser une politique personnalisée.

Si votre cluster EKS a été créé avec une version eksctl supérieure à **0.181.0,** Amazon EKSWorkerNodePolicy, y compris les `AssumeRoleForPodIdentity` autorisations requises, sera automatiquement attaché au rôle de nœud. Si l'autorisation n'est pas présente, ajoutez manuellement l'autorisation suivante à Amazon, EKSWorker NodePolicy qui permet d'assumer un rôle dans l'identité du pod. L'agent d'identité des pods EKS a besoin de cette autorisation pour récupérer les informations d'identification des pods.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks-auth:AssumeRoleForPodIdentity"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEKSAUTHAssumeroleforpodidentity"
    }
  ]
}
```

------

### Créer un module complémentaire pour l'agent d'identité EKS pod
<a name="setting-up-enable-IAM-pod-eks-cluster-agent"></a>

Utilisez la commande suivante pour créer le module complémentaire EKS Pod Identity Agent avec la dernière version :

```
aws eks create-addon --cluster-name cluster-name --addon-name eks-pod-identity-agent

kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```

Suivez les étapes suivantes pour créer le module complémentaire EKS Pod Identity Agent à partir de la console Amazon EKS :

1. Ouvrez la console Amazon EKS : 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 **Modules complémentaires**.

1. Choisissez **Obtenez plus de modules complémentaires**.

1. Cochez la case en haut à droite du module complémentaire de l’agent d’identité du pod EKS, puis sélectionnez **Suivant**.

1. Sur la page **Configurer les paramètres des modules complémentaires sélectionnés**, sélectionnez n'importe quelle version dans la liste déroulante **Version**.

1. (Facultatif) Développez les **Paramètres de configuration facultatifs** pour entrer une configuration supplémentaire. Par exemple, vous pouvez fournir un autre emplacement d’image de conteneur et `ImagePullSecrets`. Le schéma JSON avec les clés acceptées est présenté dans **Schéma de configuration du module complémentaire**.

   Saisissez les clés et les valeurs de configuration dans **Valeurs de configuration**.

1. Choisissez **Suivant**.

1. Vérifiez que les pods d'agent s'exécutent sur votre cluster via la CLI.

   `kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'`

Voici un exemple de sortie :

```
NAME                              READY   STATUS    RESTARTS      AGE
eks-pod-identity-agent-gmqp7      1/1     Running   1 (24h ago)   24h
eks-pod-identity-agent-prnsh      1/1     Running   1 (24h ago)   24h
```

Cela crée un nouveau nom DaemonSet dans l'espace de `kube-system` noms. L'agent Amazon EKS Pod Identity, qui s'exécute sur chaque nœud EKS, utilise cette [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html)action pour récupérer des informations d'identification temporaires à partir de l'API EKS Auth. Ces informations d'identification sont ensuite mises à disposition pour AWS SDKs celles que vous exécutez dans vos conteneurs.

Pour plus d'informations, consultez la condition préalable dans le document public : [Configurer l'agent d'identité Amazon EKS Pod](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html).

## Création d'un rôle d'exécution de Job
<a name="setting-up-enable-IAM-pod-create-job-role"></a>

### Création ou mise à jour du rôle d'exécution des tâches qui autorise EKS Pod Identity
<a name="setting-up-enable-IAM-pod-create-job-role-update"></a>

Pour exécuter des charges de travail avec Amazon EMR sur EKS, vous devez créer un rôle IAM. Dans cette documentation, nous appelons ce rôle le rôle d'exécution des tâches. Pour plus d'informations sur la création du rôle IAM, consultez la section [Création de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) dans le guide de l'utilisateur.

En outre, vous devez créer une politique IAM qui spécifie les autorisations nécessaires pour le rôle d'exécution de la tâche, puis associer cette politique au rôle pour activer EKS Pod Identity.

Par exemple, vous avez le rôle d'exécution de tâches suivant. Pour plus d'informations, consultez la section [Création d'un rôle d'exécution de tâche](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html).

```
arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole
```

**Important**  
Amazon EMR on EKS crée automatiquement des comptes de service Kubernetes, en fonction du nom de votre rôle d'exécution de tâches. Assurez-vous que le nom du rôle n'est pas trop long, car votre tâche risque d'échouer si la combinaison de `cluster_name``pod_name`, et `service_account_name` dépasse la limite de longueur.

**Configuration du rôle d'exécution des tâches** : assurez-vous que le rôle d'exécution des tâches est créé avec l'autorisation de confiance ci-dessous pour EKS Pod Identity. Pour mettre à jour un rôle d'exécution de tâche existant, configurez-le pour qu'il approuve le principal de service EKS suivant en tant qu'autorisation supplémentaire dans la politique de confiance. Cette autorisation de confiance peut coexister avec les politiques de confiance existantes de l'IRSA.

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

**Autorisation utilisateur** : les utilisateurs doivent être `iam:PassRole` autorisés à exécuter des appels d'`StartJobRun`API ou à soumettre des tâches. Cette autorisation permet aux utilisateurs de transmettre le rôle d'exécution des tâches à EMR sur EKS. Les administrateurs de tâches doivent avoir l'autorisation par défaut.

Vous trouverez ci-dessous l'autorisation requise pour un utilisateur :

```
{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole",
    "Condition": {
        "StringEquals": {
            "iam:PassedToService": "pods.eks.amazonaws.com"
        }
    }
}
```

Pour restreindre davantage l'accès des utilisateurs à des clusters EKS spécifiques, ajoutez le filtre AssociatedResourceArn d'attributs à la politique IAM. Il limite l'attribution des rôles aux clusters EKS autorisés, renforçant ainsi vos contrôles de sécurité au niveau des ressources.

```
"Condition": {
        "ArnLike": {
            "iam:AssociatedResourceARN": [
                "arn:aws:eks:us-west-2:111122223333:cluster/*"
            ]
        }
```

## Configurer les associations d'identité des pods EKS
<a name="setting-up-enable-IAM-pod-identity-asociations"></a>

### Prérequis
<a name="setting-up-enable-IAM-pod-identity-asociations-prereq"></a>

Assurez-vous que l'identité IAM qui crée l'association d'identité du pod, par exemple un utilisateur administrateur EKS, dispose de l'autorisation `eks:CreatePodIdentityAssociation` et`iam:PassRole`.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:CreatePodIdentityAssociation"
      ],
      "Resource": [
        "arn:aws:eks:*:*:cluster/*"
      ],
      "Sid": "AllowEKSCreatepodidentityassociation"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": [
        "arn:aws:iam::*:role/*"
      ],
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "pods.eks.amazonaws.com"
        }
      },
      "Sid": "AllowIAMPassrole"
    }
  ]
}
```

------

### Créer des associations pour le rôle et le compte de service EMR
<a name="setting-up-enable-IAM-pod-identity-asociations-emr-service"></a>

------
#### [ Create EMR role associations through the AWS CLI ]

Lorsque vous soumettez une tâche à un espace de noms Kubernetes, un administrateur doit créer des associations entre le rôle d'exécution de la tâche et l'identité du compte de service géré EMR. Notez que le compte de service géré EMR est automatiquement créé lors de la soumission de la tâche, dans la limite de l'espace de noms dans lequel la tâche est soumise.

Avec la version 2.24.0 AWS CLI (supérieure), exécutez la commande suivante pour créer des associations de rôles avec l'identité du pod.

Exécutez la commande suivante pour créer des associations de rôles avec pod identity :

```
aws emr-containers create-role-associations \
        --cluster-name mycluster \
        --namespace mynamespace \
        --role-name JobExecutionRoleIRSAv2
```

Remarque :
+ Chaque cluster peut avoir une limite de 1 000 associations. Le mappage des rôles et des espaces de noms de chaque tâche nécessitera 3 associations pour les modules émetteur de tâches, pilote et exécuteur.
+ Vous ne pouvez associer que des rôles appartenant au même AWS compte que le cluster. Vous pouvez déléguer l’accès d’un autre compte au rôle de ce compte que vous configurez pour que les identités du pod EKS utilisent. Pour un didacticiel sur la délégation d'accès`AssumeRole`, voir [Tutoriel IAM : déléguer l'accès entre AWS comptes à l'aide de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html).

------
#### [ Create EMR role associations through Amazon EKS ]

EMR crée un compte de service avec un certain modèle de dénomination lorsqu'une tâche est soumise. Pour créer des associations manuelles ou intégrer ce flux de travail au AWS SDK, procédez comme suit :

Nom du compte de service de construction :

```
emr-containers-sa-spark-%(SPARK_ROLE)s-%(AWS_ACCOUNT_ID)s-%(BASE36_ENCODED_ROLE_NAME)s
```

Les exemples ci-dessous créent une association de rôles pour un exemple de rôle d'exécution de Job JobExecutionRoleIRSAv2.

**Exemples d'associations de rôles :**

```
RoleName: JobExecutionRoleIRSAv2
Base36EncodingOfRoleName: 2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
```

**Exemple de commande CLI :**

```
# setup for the client service account (used by job runner pod)
# emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

# driver service account
# emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe        
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

# executor service account
# emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
```

------

Une fois que vous avez effectué toutes les étapes requises pour l'identification du pod EKS, vous pouvez ignorer les étapes suivantes pour la configuration de l'IRSA :
+ [Activer les rôles IAM pour les comptes de service (IRSA) sur le cluster EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html)
+ [Création d'un rôle d'exécution de tâches](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html)
+ [Mettre à jour la politique de confiance du rôle d'exécution des tâches](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html)

Vous pouvez passer directement à l'étape suivante : [Accorder aux utilisateurs l'accès à Amazon EMR](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html) sur EKS

## Supprimer les associations de rôles
<a name="setting-up-enable-IAM-pod-identity-asociations-delete-associations"></a>

Chaque fois que vous supprimez un cluster virtuel ou un rôle d'exécution de tâches et que vous ne souhaitez plus donner accès à EMR à ses comptes de service, vous devez supprimer les associations associées au rôle. Cela est dû au fait qu'EKS autorise les associations avec des ressources inexistantes (espace de noms et compte de service). Amazon EMR on EKS recommande de supprimer les associations si l'espace de noms est supprimé ou si le rôle n'est plus utilisé, afin de libérer de l'espace pour d'autres associations.

**Note**  
Les associations persistantes peuvent avoir un impact sur votre capacité à évoluer si vous ne les supprimez pas, car EKS limite le nombre d'associations que vous pouvez créer (limite souple : 1 000 associations par cluster). Vous pouvez répertorier les associations d'identité des pods dans un espace de noms donné pour vérifier s'il existe des associations persistantes qui doivent être nettoyées :

```
aws eks list-pod-identity-associations --cluster-name mycluster --namespace mynamespace
```

Avec la AWS CLI version 2.24.0 ou supérieure, exécutez la commande emr-containers suivante pour supprimer les associations de rôles d'EMR :

```
aws emr-containers delete-role-associations \
        --cluster-name mycluster \
        --namespace mynamespace \
        --role-name JobExecutionRoleIRSAv2
```

## Migrer automatiquement l'IRSA existant vers Pod Identity
<a name="setting-up-enable-IAM-pod-identity-auto-migrate"></a>

Vous pouvez utiliser l'outil eksctl pour migrer les rôles IAM existants pour les comptes de service (IRSA) vers des associations d'identité de pod :

```
eksctl utils migrate-to-pod-identity \
    --cluster mycluster \
    --remove-oidc-provider-trust-relationship \
    --approve
```

L'exécution de la commande sans l'`--approve`indicateur produira uniquement un plan reflétant les étapes de migration, et aucune migration réelle n'aura lieu.

## Résolution des problèmes
<a name="setting-up-enable-IAM-pod-identity-troubleshooting"></a>

### Ma tâche a échoué avec NoClassDefinitionFound ou ClassNotFound Exception pour le fournisseur d'informations d'identification, ou je n'ai pas réussi à obtenir le fournisseur d'informations d'identification.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-no-class"></a>

EKS Pod Identity utilise le fournisseur d'informations d'identification du conteneur pour récupérer les informations d'identification nécessaires. Si vous avez spécifié un fournisseur d'identifiants personnalisés, assurez-vous qu'il fonctionne correctement. Vous pouvez également vous assurer que vous utilisez une version du AWS SDK correcte qui prend en charge l'EKS Pod Identity. Pour plus d'informations, consultez la section [Commencer avec Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

### La tâche a échoué en raison de l'erreur « Impossible de récupérer les informations d'identification en raison de la limite de taille [x] » affichée dans le eks-pod-identity-agent journal.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds"></a>

EMR sur EKS crée des comptes de service Kubernetes en fonction du nom du rôle d'exécution de la tâche. Si le nom du rôle est trop long, EKS Auth ne parviendra pas à récupérer les informations d'identification car la combinaison de `cluster_name``pod_name`, et `service_account_name` dépasse la limite de longueur. Identifiez le composant qui occupe le plus d'espace et ajustez la taille en conséquence.

### La tâche a échoué avec l'erreur « Failed to Retrieve Credentials xxx » affichée dans le eks-pod-identity journal.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds-error"></a>

Ce problème peut être dû au fait que le cluster EKS est configuré sous des sous-réseaux privés sans être correctement configuré PrivateLink pour le cluster. Vérifiez si votre cluster se trouve dans un réseau privé et configurez-le AWS PrivateLink pour résoudre le problème. Pour obtenir des instructions détaillées, reportez-vous à la section [Commencer avec Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

# Option 2 : activer les rôles IAM pour les comptes de service (IRSA) sur le cluster EKS
<a name="setting-up-enable-IAM-service-accounts"></a>

La fonctionnalité des rôles IAM pour les comptes de service est disponible sur Amazon EKS en version 1.14 ou ultérieure et pour les clusters EKS mis à jour vers la version 1.13 ou ultérieure à partir du 3 septembre 2019. Pour utiliser cette fonctionnalité, vous pouvez mettre à jour les clusters EKS existants vers la version 1.14 ou une version ultérieure. Pour plus d'informations, consultez la rubrique [Mise à jour de la version Kubernetes d'un cluster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).

Si votre cluster prend en charge les rôles IAM pour les comptes de service, une URL d'émetteur [OpenID Connect](https://openid.net/connect/) lui est associée. Vous pouvez consulter cette URL dans la console Amazon EKS ou utiliser la AWS CLI commande suivante pour la récupérer.

**Important**  
Vous devez utiliser la dernière version de AWS CLI pour obtenir le résultat approprié de cette commande.

```
aws eks describe-cluster --name cluster_name --query "cluster.identity.oidc.issuer" --output text
```

Le résultat attendu est le suivant.

```
https://oidc.eks.<region-code>.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E
```

Pour utiliser les rôles IAM pour les comptes de service dans votre cluster, vous devez créer un fournisseur d'identité OIDC à l'aide d'[eksctl](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-eksctl) ou de la [AWS Management Console](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-console).

## Pour créer un fournisseur d'identité OIDC IAM pour votre cluster avec `eksctl`
<a name="setting-up-OIDC-eksctl"></a>

Vous pouvez vérifier la version de votre `eksctl` à l'aide de la commande suivante. Cette procédure suppose que vous avez installé `eksctl` et que votre version `eksctl` est 0.32.0 ou une version ultérieure.

```
eksctl version
```

Pour plus d'informations sur l'installation ou la mise à niveau d'eksctl, consultez la rubrique [Installation ou mise à niveau d'eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl).

Créez votre fournisseur d'identité OIDC pour votre cluster avec la commande suivante. Remplacez *cluster\$1name* par votre propre valeur.

```
eksctl utils associate-iam-oidc-provider --cluster cluster_name --approve
```

## Pour créer un fournisseur d'identité IAM OIDC pour votre cluster à l'aide du AWS Management Console
<a name="setting-up-OIDC-console"></a>

Récupérez l'URL de l'émetteur OIDC dans la description de votre cluster sur la console Amazon EKS, ou utilisez la commande suivante AWS CLI .

Utilisez la commande suivante pour récupérer l'URL de l'émetteur OIDC à partir de la AWS CLI.

```
aws eks describe-cluster --name <cluster_name> --query "cluster.identity.oidc.issuer" --output text
```

Suivez les étapes ci-dessous pour récupérer l'URL de l'émetteur OIDC à partir de la console Amazon EKS. 

1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Dans le volet de navigation, choisissez **Fournisseurs d'identité**, puis **Créer un fournisseur**.

   1. Sous **Provider Type (Type de fournisseur)**, choisissez **Choose a provider type (Choisir un type de fournisseur)**, puis choisissez **OpenID Connect**.

   1. Pour **Provider URL (URL du fournisseur**, collez l'URL de l'émetteur OIDC pour votre cluster.

   1. Pour Public ciblé, saisissez sts.amazonaws.com et choisissez **Étape suivante**.

1. Vérifiez que les informations du fournisseur sont correctes, puis choisissez **Créer (Create)** pour créer votre fournisseur d'identité.

# Création d'un rôle d'exécution des tâches
<a name="creating-job-execution-role"></a>

Pour exécuter des charges de travail sur Amazon EMR on EKS, vous devez créer un rôle IAM. Dans cette documentation, nous appelons ce rôle le *rôle d'exécution des tâches*. Pour plus d'informations sur la création de rôles IAM, consultez [Création de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) dans le Guide de l'utilisateur IAM. 

Vous devez également créer une politique IAM qui spécifie les autorisations pour le rôle d'exécution des tâches, puis associer la politique IAM au rôle d'exécution des tâches. 

La politique suivante pour le rôle d'exécution des tâches autorise l'accès aux cibles de ressources, Amazon S3 et CloudWatch. Ces autorisations sont nécessaires pour surveiller les tâches et les journaux d'accès. Pour suivre le même processus en utilisant AWS CLI : 

Créer un rôle IAM pour l'exécution des tâches : créons le rôle qu'EMR utilisera pour l'exécution des tâches. C'est le rôle que les tâches EMR assumeront lorsqu'elles s'exécuteront sur EKS.

```
cat <<EoF > ~/environment/emr-trust-policy.json
 {
   "Version": "2012-10-17",		 	 	 
   "Statement": [
     {
       "Effect": "Allow",
       "Principal": {
         "Service": "elasticmapreduce.amazonaws.com"
       },
       "Action": "sts:AssumeRole"
     }
   ]
 }
 EoF
  
 aws iam create-role --role-name EMRContainers-JobExecutionRole --assume-role-policy-document file://~/environment/emr-trust-policy.json
```

Ensuite, nous devons associer les politiques IAM requises au rôle afin qu'il puisse écrire des journaux sur s3 et Cloudwatch.

```
cat <<EoF > ~/environment/EMRContainers-JobExecutionRole.json
 {
     "Version": "2012-10-17",		 	 	 
     "Statement": [
         {
             "Effect": "Allow",
             "Action": [
                 "s3:PutObject",
                 "s3:GetObject",
                 "s3:ListBucket"
             ],
             "Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
         },
         {
             "Effect": "Allow",
             "Action": [
                 "logs:PutLogEvents",
                 "logs:CreateLogStream",
               "logs:DescribeLogGroups",
                 "logs:DescribeLogStreams"
             ],
             "Resource": [
                 "arn:aws:logs:*:*:*"
             ]
         }
     ]
 } 
 EoF
 aws iam put-role-policy --role-name EMRContainers-JobExecutionRole --policy-name EMR-Containers-Job-Execution --policy-document file://~/environment/EMRContainers-JobExecutionRole.json
```

**Note**  
L'accès doit être défini de manière appropriée et ne pas être accordé à tous les objets S3 du rôle d'exécution des tâches.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket"
      ],
      "Sid": "AllowS3Putobject"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:PutLogEvents",
        "logs:CreateLogStream",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": [
        "arn:aws:logs:*:*:*"
      ],
      "Sid": "AllowLOGSPutlogevents"
    }
  ]
}
```

------

Pour plus d'informations, consultez les [sections Utilisation des rôles d'exécution de tâches](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/iam-execution-role.html), [Configuration d'une exécution de tâche pour utiliser les journaux S3](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) et [Configuration d'une exécution de tâche pour utiliser CloudWatch les journaux](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch).

# Mise à jour la politique d'approbation du rôle d'exécution des tâches
<a name="setting-up-trust-policy"></a>

Lorsque vous utilisez les rôles IAM pour les comptes de service (IRSA) pour exécuter des tâches sur un espace de noms Kubernetes, un administrateur doit créer une relation d'approbation entre le rôle d'exécution des tâches et l'identité du compte de service géré EMR. La relation d'approbation peut être créée en mettant à jour la politique d'approbation du rôle d'exécution des tâches. Notez que le compte de service géré EMR est automatiquement créé lors de la soumission de la tâche, dans la limite de l'espace de noms dans lequel la tâche est soumise.

Pour mettre à jour la politique d'approbation, exécutez la commande suivante.

```
 aws emr-containers update-role-trust-policy \
       --cluster-name cluster \
       --namespace namespace \
       --role-name iam_role_name_for_job_execution
```

Pour de plus amples informations, veuillez consulter [Utilisation des rôles d'exécution de tâches avec Amazon EMR on EKS](iam-execution-role.md).

**Important**  
L'opérateur exécutant la commande ci-dessus doit disposer des autorisations suivantes : `eks:DescribeCluster`, `iam:GetRole`, `iam:UpdateAssumeRolePolicy`.

# Autorisation des utilisateurs à accéder à Amazon EMR on EKS
<a name="setting-up-iam"></a>

Pour toute action que vous effectuez sur Amazon EMR on EKS, vous avez besoin d'une autorisation IAM correspondant à cette action. Vous devez créer une politique IAM qui vous permet d'exécuter les actions Amazon EMR on EKS et l'attacher à l'utilisateur IAM ou au rôle que vous utilisez. 

Cette rubrique décrit les étapes à suivre pour créer une nouvelle politique et l'associer à un utilisateur. Elle couvre également les autorisations de base dont vous avez besoin pour configurer votre environnement Amazon EMR on EKS. Nous vous recommandons d'affiner les autorisations relatives à des ressources spécifiques dans la mesure du possible en fonction des besoins de votre entreprise.

## Création d'une nouvelle politique IAM et association de celle-ci à un utilisateur dans la console IAM
<a name="setting-up-iam-console"></a>

**Création d'une nouvelle politique IAM**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le volet de navigation gauche de la console IAM, choisissez **Politiques**.

1. Sur la page **Politiques**, choisissez **Créer une politique**.

1. Dans la fenêtre **Créer une politique**, accédez à l'onglet **Modifier JSON**. Créez un document de politique avec une ou plusieurs instructions JSON, comme indiqué dans les exemples suivant cette procédure. Ensuite, choisissez **Examiner la politique**.

1. Sur l’écran **Review policy** (Examiner la politique), saisissez votre **Policy Name** (Nom de politique), par exemple, `AmazonEMROnEKSPolicy`. Saisissez une description facultative, puis sélectionnez **Créer une politique**. 

**Attacher la politique à un utilisateur ou à un rôle**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 

1. Dans le panneau de navigation, choisissez **Politiques**.

1. Dans la liste des politiques, cochez la case en regard de la politique créée dans la section précédente. Vous pouvez utiliser le menu **Filtre** et la zone de recherche pour filtrer la liste de politiques. 

1. Sélectionnez **Policy Actions** (Actions de politique), puis sélectionnez **Attach** (Attacher).

1. Choisissez l'utilisateur ou le rôle auquel attacher la politique. Vous pouvez utiliser le menu **Filtre** et la zone de recherche pour filtrer la liste des entités du principal. Après avoir choisi l'utilisateur auquel attacher la politique, sélectionnez **Attacher la politique**.

## Autorisations pour la gestion des clusters virtuels
<a name="permissions-virtual-cluster"></a>

Pour gérer les clusters virtuels dans votre AWS compte, créez une politique IAM avec les autorisations suivantes. Ces autorisations vous permettent de créer, de répertorier, de décrire et de supprimer des clusters virtuels dans votre AWS compte.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "*"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "emr-containers.amazonaws.com"
        }
      },
      "Sid": "AllowIAMCreateservicelinkedrole"
    },
    {
      "Effect": "Allow",
      "Action": [
        "emr-containers:CreateVirtualCluster",
        "emr-containers:ListVirtualClusters",
        "emr-containers:DescribeVirtualCluster",
        "emr-containers:DeleteVirtualCluster"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEMRCONTAINERSCreatevirtualcluster"
    }
  ]
}
```

------

Amazon EMR est intégré à la gestion des accès aux clusters (CAM) d'Amazon EKS, ce qui vous permet d'automatiser la configuration des politiques AuthN et AuthZ nécessaires pour exécuter des tâches Amazon EMR Spark dans les espaces de noms des clusters Amazon EKS. Pour ce faire, vous devez disposer des autorisations suivantes :

```
{
  "Effect": "Allow",
  "Action": [
    "eks:CreateAccessEntry"
  ],
  "Resource": "arn:<AWS_PARTITION>:eks:<AWS_REGION>:<AWS_ACCOUNT_ID>:cluster/<EKS_CLUSTER_NAME>"
}, 
{
  "Effect": "Allow",
  "Action": [
    "eks:DescribeAccessEntry",
    "eks:DeleteAccessEntry",
    "eks:ListAssociatedAccessPolicies",
    "eks:AssociateAccessPolicy",
    "eks:DisassociateAccessPolicy"
  ],
  "Resource": "arn:<AWS_PARTITION>:eks:<AWS_REGION>:<AWS_ACCOUNT_ID>:access-entry/<EKS_CLUSTER_NAME>/role/<AWS_ACCOUNT_ID>/AWSServiceRoleForAmazonEMRContainers/*"
}
```

Pour plus d'informations, consultez [Automatiser l'activation de l'accès au cluster pour Amazon EMR sur](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html#setting-up-cluster-access-cam-integration) EKS.

Lorsque l'`CreateVirtualCluster`opération est invoquée pour la première fois depuis un AWS compte, vous devez également disposer des `CreateServiceLinkedRole` autorisations nécessaires pour créer le rôle lié à un service pour Amazon EMR sur EKS. Pour de plus amples informations, veuillez consulter [Utilisation des rôles liés à un service pour Amazon EMR on EKS](using-service-linked-roles.md). 

## Autorisations pour la soumission de tâches
<a name="permissions-submitting-jobs"></a>

Pour soumettre des tâches sur les clusters virtuels de votre AWS compte, créez une politique IAM avec les autorisations suivantes. Ces autorisations vous permettent de démarrer, de répertorier, de décrire et d'annuler des exécutions de tâches pour tous les clusters virtuels de votre compte. Vous devriez envisager d'ajouter des autorisations pour répertorier ou décrire les clusters virtuels, ce qui vous permet de vérifier l'état du cluster virtuel avant de soumettre des tâches.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "emr-containers:StartJobRun",
        "emr-containers:ListJobRuns",
        "emr-containers:DescribeJobRun",
        "emr-containers:CancelJobRun"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEMRCONTAINERSStartjobrun"
    }
  ]
}
```

------

## Autorisations pour le débogage et la surveillance
<a name="permissions-debugging-monitoring"></a>

Pour accéder aux journaux transmis à Amazon S3 et/ou pour consulter les CloudWatch journaux des événements de l'application dans la console Amazon EMR, créez une politique IAM avec les autorisations suivantes. Nous vous recommandons d'affiner les autorisations relatives à des ressources spécifiques dans la mesure du possible en fonction des besoins de votre entreprise.

**Important**  
Si vous n'avez pas créé de compartiment Amazon S3, vous devez ajouter une autorisation `s3:CreateBucket` à la déclaration de politique. Si vous n'avez pas créé de groupe de journaux, vous devez ajouter `logs:CreateLogGroup` à la déclaration de politique.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "emr-containers:DescribeJobRun",
        "elasticmapreduce:CreatePersistentAppUI",
        "elasticmapreduce:DescribePersistentAppUI",
        "elasticmapreduce:GetPersistentAppUIPresignedURL"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEMRCONTAINERSDescribejobrun"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowS3Getobject"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:Get*",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowLOGSGet"
    }
  ]
}
```

------

Pour plus d'informations sur la façon de configurer l'exécution d'une tâche pour envoyer des journaux vers Amazon S3 CloudWatch, consultez [Configurer une exécution de tâche pour utiliser les journaux S3](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) et [Configurer une exécution de tâche pour utiliser CloudWatch les journaux](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch).

# Enregistrement du cluster Amazon EKS dans Amazon EMR
<a name="setting-up-registration"></a>

L'enregistrement de votre cluster est la dernière étape nécessaire pour configurer Amazon EMR on EKS afin d'exécuter des charges de travail.

Utilisez la commande suivante pour créer un cluster virtuel portant le nom de votre choix pour le cluster Amazon EKS et l'espace de noms que vous avez configurés aux étapes précédentes.

**Note**  
Chaque cluster virtuel doit avoir un nom unique pour tous les clusters EKS. Si deux clusters virtuels portent le même nom, le processus de déploiement échouera même s'ils appartiennent à des clusters EKS différents. 

```
aws emr-containers create-virtual-cluster \
--name virtual_cluster_name \
--container-provider '{
    "id": "cluster_name",
    "type": "EKS",
    "info": {
        "eksInfo": {
            "namespace": "namespace_name"
        }
    }
}'
```

Vous pouvez également créer un fichier JSON qui inclut les paramètres requis pour le cluster virtuel, puis exécuter la commande `create-virtual-cluster` avec le chemin d'accès au fichier JSON. Pour de plus amples informations, veuillez consulter [Gestion des clusters virtuels](virtual-cluster.md).

**Note**  
Pour valider la création réussie d'un cluster virtuel, consultez l'état des clusters virtuels à l'aide de l'opération `list-virtual-clusters` ou en accédant à la page **Clusters virtuels** de la console Amazon EMR.