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 : 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. Lorsque vous utilisez Pod Identities, les conteneurs du Pod disposent également des autorisations attribuées auRôle IAM de nœud Amazon EKS, sauf si vous bloquez l'accès du Pod au Amazon EC2 Instance Metadata Service (IMDS). 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.

Vous pouvez associer un rôle IAM à chaque compte de service Kubernetes dans chaque cluster. Vous pouvez modifier le rôle mappé au compte de service en modifiant l’association des identités du pod EKS.

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èsAssumeRole, voir Déléguer l'accès entre AWS comptes à l'aide de rôles IAM dans le Guide de l'utilisateur IAM.

L’agent d’identité du pod EKS est nécessaire. Il s'exécute en tant que Kubernetes DaemonSet sur vos nœuds et ne fournit des informations d'identification qu'aux pods du nœud sur lequel il s'exécute. Pour plus d’informations sur la compatibilité de l’agent d’identité du pod EKS, consultez la section suivante Restrictions relatives à l’identité du pod EKS.

À l'instar du comportement AWS IAM, les associations EKS Pod Identity sont finalement cohérentes et peuvent prendre plusieurs secondes pour être efficaces après le retour réussi de l'appel d'API initial. Vous devez concevoir vos applications de sorte qu'elles tiennent compte de ces retards potentiels. Nous vous recommandons de ne pas inclure la création/mise à jour de l'association Pod Identity dans les chemins de code critiques à haute disponibilité de votre application. Au lieu de cela, procédez aux modifications dans une routine d'initialisation ou d'installation distincte que vous exécutez moins souvent.

Si vous utilisez le groupe de sécurité pour les pods avec l'agent Pod Identity, vous devrez peut-être définir l'POD_SECURITY_GROUP_ENFORCING_MODEindicateur pour le AWS VPC CNI. Pour plus d'informations sur les considérations relatives au groupe de sécurité pour les pods, consultezAttribuer des groupes de sécurité à des pods individuels.

L’agent d’identité du pod EKS utilise le hostNetwork du nœud et il utilise le port 80 et le port 2703 sur une adresse locale de liaison sur le nœud. Cette adresse est 169.254.170.23 pour IPv4 et [fd00:ec2::23] pour les IPv6 clusters.

Si vous désactivez IPv6 des adresses ou empêchez les adresses IPv6 IP de l'hôte local, l'agent ne peut pas démarrer. Pour démarrer l'agent sur des nœuds qui ne peuvent pas être utilisésIPv6, suivez les étapes décrites Désactiver IPv6 dans l'agent d'identité EKS Pod pour désactiver la IPv6 configuration.

Si vos pods utilisent un proxy, vous devez vous assurer d'ajouter 169.254.170.23 pour IPv4 et [fd00:ec2::23] pour IPv6 dans les variables d'NO_PROXYenvironnementno_proxy/injectées dans les pods. Sinon, les demandes envoyées par les pods d'application au eks-pod-identity-agent DaemonSets échoueraient car les demandes seraient envoyées au proxy et le proxy ne serait pas en mesure d'acheminer l'adresse IP.

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.