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. # Activer les rôles IAM pour le cluster EKS 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 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 ? 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 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 ### Vérifiez si l'autorisation requise existe dans NodeInstanceRole 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 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 ### Création ou mise à jour du rôle d'exécution des tâches qui autorise EKS Pod Identity 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 < ### Prérequis 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 ------ #### [ 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 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 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 ### 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. 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. 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. 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 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..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` 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 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 --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 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 < ~/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 < ~/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 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`.