EKS Pod Identity: temporary AWS credentials per ServiceAccount

Study notes

• Pod Identity is the current recommended way to give EKS workloads AWS permissions. You install the EKS Pod Identity Agent add-on, which runs as a DaemonSet. You then create a Pod Identity association, a small AWS object that says: for this cluster, namespace and ServiceAccount, use this IAM role. When a Pod using that ServiceAccount calls an AWS SDK, the SDK asks the agent for credentials, the agent calls the EKS Auth service, which verifies the association and obtains temporary credentials from STS for the role, and returns them. Press the right arrow to follow the five steps.
• The IAM role's trust policy is simple and identical for every cluster: it trusts the pods.eks.amazonaws.com service principal for sts:AssumeRole and sts:TagSession. In contrast with IRSA, there is no per-cluster OIDC provider to create and no cluster-specific condition in the trust policy, so the same role can be reused by many clusters, and the ServiceAccount needs no annotation. Credentials are temporary and rotate automatically.
• Operational points: recent AWS SDKs support the container credentials provider this relies on, so old SDK versions may need upgrading. Pod Identity is not available for Fargate Pods, where IRSA is used instead, and it is EKS-specific, whereas IRSA's OIDC mechanism also works on other Kubernetes distributions. Check the current support matrix.
• Security payoff: credentials are scoped to a ServiceAccount's role, not the node's role. Combined with blocking Pod access to the node metadata service, a compromised Pod can only do what its own role allows.

Deck map