Découvrir comment l’identité du pod Amazon EKS accorde aux pods l’accès aux services AWS

Moindre privilège : vous pouvez définir les autorisations IAM sur un compte de service et seuls les pods qui utilisent ce compte de service ont accès à ces autorisations. Cette fonctionnalité élimine également le besoin de solutions tierces telles que kiam ou kube2iam.

Isolation des informations d’identification : lorsque l’accès au service de métadonnées d’instance (IMDS) Amazon EC2 est restreint, les conteneurs d’un pod ne peuvent récupérer que les informations d’identification du rôle IAM associé au compte de service utilisé par le conteneur. Un conteneur n’a jamais accès aux informations d’identification qui sont utilisées par d’autres conteneurs dans d’autres pods. Si IMDS n’est pas restreint, les conteneurs du Pod ont également accès au rôle IAM du nœud Amazon EKS et les conteneurs peuvent être en mesure d’accéder aux informations d’identification des rôles IAM d’autres Pods sur le même nœud. Pour plus d'informations, consultez Restreindre l'accès au profil d'instance affecté au composant master.

Auditabilité : l’accès et la journalisation des événements sont disponibles via AWS CloudTrail afin de faciliter l’audit rétrospectif.

Opérations indépendantes : dans de nombreuses organisations, la création de fournisseurs d’identité OIDC relève de la responsabilité d’équipes différentes de celles qui administrent les clusters Kubernetes. L’identité du pod EKS présente une séparation nette des tâches, où toute la configuration des associations de l’identité du pod EKS est effectuée dans Amazon EKS et toute la configuration des autorisations IAM est effectuée dans IAM.

Réutilisabilité : l’identité du pod EKS utilise un seul principal IAM au lieu des principaux distincts pour chaque cluster que les rôles IAM des comptes de service utilisent. Votre administrateur IAM ajoute le principal suivant à la politique d’approbation de n’importe quel rôle pour le rendre utilisable par les identités du pod EKS.

            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            }

Capacité de mise à l’échelle : chaque ensemble d’informations d’identification temporaires est pris en charge par le service d’authentification EKS dans l’identité du pod EKS, au lieu de chaque kit SDK AWS que vous exécutez dans chaque pod. Ensuite, l’agent de l’identité du pod Amazon EKS qui s’exécute sur chaque nœud émet les informations d’identification aux kits SDK. La charge est ainsi réduite à une seule fois pour chaque nœud et n’est pas dupliquée dans chaque pod. Pour plus de détails sur le processus, consultez Comprendre le fonctionnement de l’identité du pod Amazon EKS.

Jusqu’à 5 000 associations d’identité du pod EKS par cluster sont prises en charge pour mapper les rôles IAM aux comptes de service Kubernetes.

Association de rôles IAM : chaque compte de service Kubernetes d’un cluster peut être associé à un rôle IAM du même compte AWS que le cluster. Pour modifier le rôle, modifiez l’association d’identité du pod EKS. Pour l’accès intercompte, déléguez l’accès au rôle à l’aide des rôles IAM. Pour en savoir plus, consultez Déléguer l’accès entre les comptes AWS à l’aide des rôles IAM dans le Guide de l’utilisateur IAM.

Agent d’identité du pod EKS : l’agent d’identité du pod est nécessaire pour utiliser l’identité du pod EKS. L’agent s’exécute en tant que DaemonSet Kubernetes sur les nœuds du cluster, fournissant des informations d’identification uniquement aux pods du même nœud. Il utilise le hostNetwork du nœud, occupant les ports 80 et 2703 sur l’adresse locale de liaison (169.254.170.23 pour IPv4, [fd00:ec2::23] pour IPv6). Si IPv6 est désactivé dans votre cluster, désactivez IPv6 pour l’agent d’identité du pod EKS. Pour en savoir plus, consultez Désactiver IPv6 dans l’agent d’identité du pod EKS.

Cohérence à terme : les associations d’identité du pod EKS sont cohérentes à terme, avec des retards potentiels de plusieurs secondes après les appels d’API. Évitez de créer ou de mettre à jour des associations dans des chemins de code critiques et à haute disponibilité. Effectuez plutôt ces actions dans des routines d’initialisation ou de configuration distinctes et moins fréquentes. Pour en savoir plus, consultez Groupes de sécurité par pod dans le Guide des bonnes pratiques EKS.

Considérations relatives au proxy et au groupe de sécurité : pour les pods utilisant un proxy, ajoutez 169.254.170.23 (IPv4) et [fd00:ec2::23] (IPv6) aux variables d’environnement no_proxy/NO_PROXY afin d’éviter les échecs de demandes vers l’agent d’identité du pod EKS. Si vous utilisez des groupes de sécurité pour les pods avec le CNI VPC AWS, définissez l’indicateur ENABLE_POD_ENI sur « true » et l’indicateur POD_SECURITY_GROUP_ENFORCING_MODE sur « standard ». Pour en savoir plus, consultez Attribuer des groupes de sécurité à des pods individuels.

Les versions du cluster Amazon EKS répertoriées dans la rubrique précédente Versions du cluster de l’identité du pod EKS.

Les composants master du cluster qui sont des instances Amazon EC2 Linux.

AWS Outposts.

Amazon EKS Anywhere.

Clusters Kubernetes que vous créez et exécutez sur Amazon EC2. Les composants de l’identité du pod Amazon EKS sont uniquement disponibles sur Amazon EKS.

Les pods qui s’exécutent n’importe où, à l’exception des instances Amazon EC2 Linux. Les pods Linux et Windows qui s’exécutent sur AWS Fargate (Fargate) ne sont pas pris en charge. Les pods qui s’exécutent sur des instances Amazon EC2 Windows ne sont pas pris en charge.