IRSA or EKS Pod Identity: how do pods get AWS permissions?

Summary

Both give a Kubernetes ServiceAccount an IAM role so pods get short-lived AWS credentials without static keys. IRSA (IAM Roles for Service Accounts) uses the cluster's OIDC provider and a trust policy per role referencing the cluster and ServiceAccount. EKS Pod Identity, the newer option, uses an EKS-managed agent and pod identity associations created through the EKS API, with a simpler trust policy that can be reused across clusters.

Longer Answer

Pod Identity advantages: no OIDC provider to set up per cluster, role trust policies that do not change per cluster, associations managed alongside the cluster, and session tags for attribute-based access control. IRSA remains necessary in some cases (for example self-managed Kubernetes on EC2, or pods on Fargate, which Pod Identity has not supported; check the current docs), and many existing setups use it.

Either way, avoid granting permissions to the node instance role, because every pod on the node could use them; restrict pod access to the instance metadata service (IMDSv2 with hop limit 1).

Key Points

• Both map ServiceAccounts to IAM roles.
• IRSA: OIDC provider + per-cluster trust.
• Pod Identity: EKS agent + associations, reusable trust.
• Never rely on the node role; restrict IMDS.