Découvrez comment EKS Pod Identity permet aux pods d'accéder aux AWS services

Privilège minimal : vous pouvez attribuer des autorisations IAM à 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 à l'Amazon EC2 Instance Metadata Service (IMDS) est restreint, les conteneurs d'un pod peuvent uniquement récupérer les informations d'identification pour le rôle IAM associé au compte de service utilisé par le conteneur. Un conteneur n'a jamais accès aux informations d'identification utilisées par d'autres conteneurs dans d'autres pods. Si l'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 des 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é — La journalisation des accès et des événements est disponible AWS CloudTrail pour 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 celle de l'administration des 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"
            }

Évolutivité — Chaque ensemble d'informations d'identification temporaires est utilisé par le service EKS Auth dans EKS Pod Identity, et non par chaque AWS SDK que vous exécutez dans chaque module. Ensuite, l'agent d'identité Amazon EKS Pod qui s'exécute sur chaque nœud émet les informations d'identification au SDKs. Ainsi, la charge est réduite à une fois pour chaque nœud et n'est pas dupliquée dans chaque pod. Pour plus de détails sur le processus, consultez Découvrez le fonctionnement d'EKS Pod Identity.

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

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

EKS Pod Identity Agent : L'agent Pod Identity est requis pour utiliser EKS Pod Identity. L'agent s'exécute en tant que Kubernetes DaemonSet sur les nœuds du cluster, fournissant des informations d'identification uniquement aux pods du même nœud. Il utilise le port d'occupation du hostNetwork nœud 80 et 2703 l'adresse locale du lien (169.254.170.23pour IPv4, [fd00:ec2::23] pour IPv6). S'il IPv6 est désactivé dans votre cluster, désactivez-le IPv6 pour le Pod Identity Agent. Pour en savoir plus, voir Désactiver IPv6 dans l'agent d'identité EKS Pod.

Cohérence éventuelle : les associations EKS Pod Identity sont finalement cohérentes, avec des délais 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 à haute disponibilité. Effectuez plutôt ces actions dans le cadre de routines d'initialisation ou de configuration distinctes et moins fréquentes. Pour en savoir plus, consultez la section Groupes de sécurité par pod dans le guide des meilleures pratiques d'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'no_proxy/NO_PROXYenvironnement afin d'éviter l'échec des demandes adressées à l'agent EKS Pod Identity. Si vous utilisez des groupes de sécurité pour les pods avec le AWS VPC CNI, définissez l'ENABLE_POD_ENIindicateur sur « true » et le POD_SECURITY_GROUP_ENFORCING_MODE drapeau sur « standard ». Pour en savoir plus, voir 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.

Nœuds de travail du cluster qui sont des EC2 instances Amazon 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.

Des pods qui s'exécutent n'importe où, sauf sur EC2 les instances Linux Amazon. 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 EC2 instances Amazon Windows ne sont pas pris en charge.