Amazon EKS Pod Identity maps an IAM role to a Kubernetes service account without requiring an IAM OIDC provider or service-account annotation. An EKS Pod Identity association is created through the EKS control plane for a specific cluster, namespace, and service account. The EKS Pod Identity Agent on Linux EC2 worker nodes supplies temporary credentials to pods that use the associated service account through supported AWS SDK credential chains.
Within AWS Architecture and Operations, Pod Identity is the preferred place to solve “which AWS APIs may this workload call?” at the Kubernetes workload identity boundary instead of letting pods inherit the worker-node instance profile.
The feature is simpler than IRSA in many organizations because the IAM role trusts one EKS service principal rather than an OIDC issuer unique to each cluster.
The association lives in EKS, not in the Kubernetes ServiceAccount object
Creating a Pod Identity association does not add annotations or metadata to the service account.
The association exists in the EKS control plane and references cluster, namespace, service account, and IAM role.
This separates Kubernetes object management from IAM role association and makes cluster/IAM responsibilities clearer across platform and security teams.
The IAM role trusts pods.eks.amazonaws.com
Roles used by Pod Identity need a trust policy allowing the pods.eks.amazonaws.com service principal to call sts:AssumeRole and sts:TagSession.
Session tags can carry cluster, namespace, and service-account context and can be used in policy conditions.
Use those conditions when one reusable role should be limited to specific EKS workload identities rather than every association in the account.
The Pod Identity Agent is required on the nodes
The managed add-on runs a DaemonSet on cluster nodes and participates in credential delivery for pods on the same node.
Monitor agent health and compatibility during Kubernetes upgrades.
A correct association will not help a pod on a node where the agent is absent or unhealthy.
Supported workloads currently require Linux EC2 worker nodes
AWS documents that EKS Pod Identity is not available for Fargate pods, Windows EC2 pods, EKS Anywhere, Outposts, or generic Kubernetes clusters on EC2.
Mixed clusters therefore need a deliberate identity strategy for unsupported compute types.
Do not remove IRSA or another credential path until every workload class in scope supports Pod Identity.
Each service account can have one Pod Identity role per cluster
An association maps one service account to one IAM role in the cluster, although the same IAM role can be reused across multiple service accounts/associations.
For workloads that need cross-account access, the Pod Identity role can assume a second role in the target account according to normal IAM delegation.
Keep the initial pod role narrow and avoid one service account shared by unrelated applications merely to reuse permissions.
Supported SDKs use the default credential chain
EKS injects environment information that supported AWS SDK versions use to retrieve Pod Identity credentials.
Applications generally do not need custom credential code if they already use the default SDK provider chain.
Inventory runtime/SDK versions before migration because old SDKs can ignore the new provider and fall back to node credentials if IMDS remains accessible.
Restrict IMDS to protect credential isolation
A pod that can reach EC2 Instance Metadata Service can potentially use the node IAM role in addition to its workload identity depending on node configuration and network restrictions.
Use IMDSv2 and hop-limit/network controls or other EKS best practices so ordinary pods cannot fall back to broad node credentials.
Least privilege is only achieved if the workload identity is also the only useful AWS credential source available to the pod.
Association creation requires iam:PassRole
The principal creating the Pod Identity association must be authorized to pass the selected IAM role.
This is an important governance boundary: cluster administrators should not be able to attach arbitrary privileged roles unless IAM policy explicitly allows it.
Use permissions boundaries/role naming or resource conditions so platform automation can associate only approved workload-role classes.
Reuse improves multi-cluster administration
IRSA roles often include one trust relationship per cluster OIDC provider. Pod Identity can reuse a role with the common EKS service principal and association/session-tag constraints.
This can simplify fleets with development, staging, production, and regional clusters.
Still review whether one role should really span all environments; independent roles can provide stronger blast-radius and policy-change separation.
Monitor associations as production identity configuration
Inventory every cluster/namespace/service-account to role mapping and alert on unexpected changes.
CloudTrail, EKS configuration exports, IAM Access Analyzer, and policy-as-code can help detect drift.
An application deployment may be unchanged while a Pod Identity association grants it new privileges, so association changes belong in security change review.
Pod Identity succeeds when pods receive exactly the AWS permissions their service account represents
The mature design uses the agent, supported SDKs, restricted IMDS, group-owned service accounts, scoped IAM roles, session-tag conditions, and controlled iam:PassRole.
EKS Pod Identity simplifies credential plumbing; the engineering work remains defining workload boundaries and permissions that stay least-privilege as clusters and teams scale.
Pod Identity session tags can strengthen policy boundaries. EKS can pass tags describing the cluster, namespace, service account, and related association context into STS sessions. IAM policies can use these tags so one reusable role is usable only from approved workloads, reducing the risk that a broad trust policy on pods.eks.amazonaws.com becomes overly permissive.
Namespace design therefore becomes part of IAM architecture. If platform teams reuse the same service-account name in many namespaces, the Pod Identity association and trust conditions must distinguish them. Avoid generic service accounts such as app across unrelated workloads unless the association policy is equally explicit.
Cross-account access should use role chaining rather than trying to associate a role from another account directly. The Pod Identity role belongs to the cluster’s account; it can receive permission to assume a target-account role. This keeps the EKS association simple while the target account retains control over who may enter.
Migration from IRSA should be staged workload by workload. Create the Pod Identity association, confirm the SDK resolves Pod Identity credentials, restrict IMDS, and verify CloudTrail identity context before removing the old IRSA annotation/role relationship. Running both during transition can be useful, but the credential-provider precedence should be tested so you know which identity the application is actually using.
Add-ons can also use Pod Identity where supported. AWS lets EKS add-ons reference Pod Identity associations during create/update. Keep addon IAM roles separate from application roles and use AWS’s documented recommended policies/permissions for components such as controllers and drivers.
Credential failures should be diagnosable from the pod. Verify the agent DaemonSet, service account, association, injected environment variables/token path, SDK version, STS errors, and IAM role trust/policy in sequence. Avoid “fixing” Pod Identity by adding broad permissions to the node role, because that masks the workload identity problem.
Association limits should be considered in very large shared clusters. AWS currently supports thousands of Pod Identity associations per cluster, but one association per service account can still create operational sprawl if every deployment creates unique service-account/role pairs. Standardize patterns and ownership metadata so IAM inventory remains reviewable.
Policy-as-code should compare desired associations with EKS state. Because there is no Kubernetes annotation showing the role, ordinary kubectl inspection cannot reveal the full AWS permission mapping. Export associations through EKS APIs/IaC and include them in access reviews and incident response inventories.
Pod Identity should be part of namespace onboarding templates. Creating a namespace, service account, IAM role, association, NetworkPolicy, and workload deployment as one reviewed unit reduces the chance an application launches first with node-role credentials and receives least privilege later. Platform automation can make the secure identity path the easiest path.
CloudTrail session tags make investigations easier when enabled and preserved. Security teams can trace an AWS API call back to cluster, namespace, and service account context instead of seeing only a generic node role. Keep those tags available in centralized audit pipelines and avoid stripping the fields that distinguish workloads.
Role reuse should be balanced against blast radius. Reusing one role across many clusters simplifies trust policy, but one permission change then affects every associated workload. Separate roles by environment or application criticality where independent approval and rollback are valuable.
Pod Identity migrations should include a negative test: remove or deny one required IAM action and confirm the application fails with the Pod Identity role rather than silently succeeding through the node role. This proves credential isolation is real and prevents a hidden fallback from undermining least privilege.
Pod Identity should be included in cluster-upgrade regression tests. Upgrade the EKS control plane, Pod Identity Agent add-on, node AMI, and critical SDK-based workloads in a canary environment and confirm credentials continue to resolve with the expected role/session tags. Identity plumbing is easy to overlook because ordinary Kubernetes readiness probes may pass even while every AWS API call returns credential errors.
For secrets-heavy workloads, remember that Pod Identity grants AWS API permissions; it does not itself inject application secrets. Use Secrets Manager, Parameter Store, or another governed secret system and let the Pod Identity role authorize only the exact secret paths the service needs. This keeps credential delivery and secret content as separate security layers.
