Learn how EKS Pod Identity grants pods access to Amazon services

Least privilege – You can scope IAM permissions to a service account, and only Pods that use that service account have access to those permissions. This feature also eliminates the need for third-party solutions such as kiam or kube2iam.

Credential isolation – When access to the Amazon EC2 Instance Metadata Service (IMDS) is restricted, a Pod’s containers can only retrieve credentials for the IAM role that’s associated with the service account that the container uses. A container never has access to credentials that are used by other containers in other Pods. If IMDS is not restricted, the Pod’s containers also have access to the Amazon EKS node IAM role and the containers may be able to gain access to credentials of IAM roles of other Pods on the same node. For more information, see Restrict access to the instance profile assigned to the worker node.

Auditability – Access and event logging is available through Amazon CloudTrail to help facilitate retrospective auditing.

Independent operations – In many organizations, creating OIDC identity providers is a responsibility of different teams than administering the Kubernetes clusters. EKS Pod Identity has clean separation of duties, where all configuration of EKS Pod Identity associations is done in Amazon EKS and all configuration of the IAM permissions is done in IAM.

Reusability – EKS Pod Identity uses a single IAM principal instead of the separate principals for each cluster that IAM roles for service accounts use. Your IAM administrator adds the following principal to the trust policy of any role to make it usable by EKS Pod Identities.

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

Scalability — Each set of temporary credentials are assumed by the EKS Auth service in EKS Pod Identity, instead of each Amazon SDK that you run in each pod. Then, the Amazon EKS Pod Identity Agent that runs on each node issues the credentials to the SDKs. Thus the load is reduced to once for each node and isn’t duplicated in each pod. For more details of the process, see Understand how EKS Pod Identity works.

Up to 5,000 EKS Pod Identity associations per cluster to map IAM roles to Kubernetes service accounts are supported.

IAM Role Association: Each Kubernetes service account in a cluster can be associated with one IAM role from the same Amazon account as the cluster. To change the role, edit the EKS Pod Identity association. For cross-account access, delegate access to the role using IAM roles. To learn more, see Delegate access across Amazon accounts using IAM roles in the IAM User Guide.

EKS Pod Identity Agent: The Pod Identity Agent is required to use EKS Pod Identity. The agent runs as a Kubernetes DaemonSet on cluster nodes, providing credentials only to pods on the same node. It uses the node’s hostNetwork, occupying port 80 and 2703 on the link-local address (169.254.170.23 for IPv4, [fd00:ec2::23] for IPv6). If IPv6 is disabled in your cluster, disable IPv6 for the Pod Identity Agent. To learn more, see Disable IPv6 in the EKS Pod Identity Agent.

Eventual Consistency: EKS Pod Identity associations are eventually consistent, with potential delays of several seconds after API calls. Avoid creating or updating associations in critical, high-availability code paths. Instead, perform these actions in separate, less frequent initialization or setup routines. To learn more, see Security Groups Per Pod in the EKS Best Practices Guide.

Proxy and Security Group Considerations: For pods using a proxy, add 169.254.170.23 (IPv4) and [fd00:ec2::23] (IPv6) to the no_proxy/NO_PROXY environment variables to prevent failed requests to the EKS Pod Identity Agent. If using Security Groups for Pods with the Amazon VPC CNI, set the ENABLE_POD_ENI flag to ‘true’ and the POD_SECURITY_GROUP_ENFORCING_MODE flag to ‘standard’. To learn more, see Assign security groups to individual Pods.

Amazon EKS cluster versions listed in the previous topic EKS Pod Identity cluster versions.

Worker nodes in the cluster that are Linux Amazon EC2 instances.

Amazon Outposts.

Amazon EKS Anywhere.

Kubernetes clusters that you create and run on Amazon EC2. The EKS Pod Identity components are only available on Amazon EKS.

Pods that run anywhere except Linux Amazon EC2 instances. Linux and Windows pods that run on Amazon Fargate (Fargate) aren’t supported. Pods that run on Windows Amazon EC2 instances aren’t supported.