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.
Option 1 : activer l'identité du pod EKS sur le cluster EKS
Les associations Amazon EKS Pod Identity permettent de gérer les informations d'identification de vos applications, de la même manière que les profils d' EC2 instance Amazon fournissent des informations d'identification aux EC2 instances Amazon. 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.
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.
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'AssumeRoleForPodIdentityaction dans l'API EKS Auth. Vous pouvez ajouter les éléments suivants à l'Amazon EKSWorker NodePolicy, 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.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks-auth:AssumeRoleForPodIdentity" ], "Resource": "*" } ] }
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 :
Ouvrez la console Amazon EKS : console Amazon EKS
. 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.
Choisissez l'onglet Modules complémentaires.
Choisissez Obtenez plus de modules complémentaires.
Cochez la case en haut à droite du module complémentaire de l’agent d’identité du pod EKS, puis sélectionnez Suivant.
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.
(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 affiché dans Schéma de configuration du module complémentaire.Saisissez les clés et les valeurs de configuration dans Valeurs de configuration.
Choisissez Next (Suivant).
Vérifiez que les pods d'agent sont exécutés 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 AssumeRoleForPodIdentityaction 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.
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 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, voir Création d'un rôle d'exécution de tâche.
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_namepod_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'StartJobRunAPI 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
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 etiam:PassRole.
{ "Effect": "Allow", "Action": [ "eks:CreatePodIdentityAssociation", ], "Resource": "* or role-arn" }, { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "* or role-arn", "Condition": { "StringEquals": { "iam:PassedToService": "pods.eks.amazonaws.com" } } }] }
Créer des associations pour le rôle et le compte de service EMR
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 :
Vous pouvez passer directement à l'étape suivante : Accorder aux utilisateurs l'accès à Amazon EMR 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'--approveindicateur 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.
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 pourra pas récupérer les informations d'identification car la combinaison de cluster_namepod_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.
