Use EKS Pod Identity for new Amazon EKS workloads when the node type, AWS SDK, add-on, Region, and account design support it. Keep IRSA where it already works well, where workloads run on unsupported environments such as AWS Fargate or Windows nodes, or where an established OIDC-based cross-account pattern is a deliberate requirement. Both methods provide temporary AWS credentials to Kubernetes workloads; the safer choice depends on the operating environment, not on replacing IRSA everywhere at once.
A migration should be staged. Inventory every service account and role, confirm Pod Identity prerequisites, add the new role trust without removing the IRSA trust, create one association, restart only a controlled workload, verify the credential source and allowed AWS actions, and retain a documented rollback. Remove the old service-account annotation and OIDC trust only after observation shows that the new path is stable and least privilege is preserved.
What you need to know
- AWS recommends EKS Pod Identity whenever possible, but IRSA remains supported and is still appropriate for several environments.
- Pod Identity removes the per-cluster IAM OIDC provider requirement and centralizes service-account-to-role mappings in EKS associations.
- The Pod Identity Agent, EKS Auth API access, a supported AWS SDK, node-role permission, and the correct IAM role trust are all prerequisites.
- Create the Pod Identity association before removing existing credentials; the SDK credential chain makes a staged cutover possible.
- Validate the caller identity, permitted actions, denied actions, audit trail, failure behavior, and rollback before retiring IRSA configuration.
What is the difference between EKS Pod Identity and IRSA?
EKS Pod Identity and IAM roles for service accounts solve the same high-level problem: they give a Kubernetes workload temporary AWS credentials without placing long-lived access keys in a container. The difference is how trust is established and how credentials reach the application.
With IRSA, an EKS cluster has an OpenID Connect issuer. An IAM OIDC provider is created for the cluster, a Kubernetes service account is annotated with an IAM role, and the role trust policy limits which OIDC subject may call AWS Security Token Service with AssumeRoleWithWebIdentity. The workload's AWS SDK exchanges a projected web identity token for temporary role credentials.
With EKS Pod Identity, the IAM role trusts the EKS service principal pods.eks.amazonaws.com. An EKS association maps a cluster, namespace, and service account to that role. An agent runs on eligible nodes, exchanges the projected pod token with the EKS Auth API through AssumeRoleForPodIdentity, and exposes temporary credentials through the SDK container credential provider.
| Decision area | EKS Pod Identity | IRSA |
|---|---|---|
| Trust anchor | EKS service principal and an EKS association | Per-cluster OIDC provider and IAM trust conditions |
| Credential delivery | Pod Identity Agent and EKS Auth API | AWS STS AssumeRoleWithWebIdentity |
| Cluster configuration | Association managed through EKS APIs | IAM role annotation on the service account |
| Session context | EKS session tags support cluster, namespace, and service-account context | No equivalent EKS Pod Identity session-tag model |
| Platform reach | Purpose-built for supported Amazon EKS environments | Also supports EKS Anywhere, ROSA, and self-managed Kubernetes patterns |
Continue reading: Kubernetes Platform definition · AWS: grant workloads access with service accounts ↗
Choose Pod Identity or IRSA by operating constraint
Choose Pod Identity for a new workload when the team wants a simpler EKS-native association, does not want to create an IAM OIDC provider for every cluster, expects to reuse roles across clusters, or wants session tags for attribute-based access control. AWS currently recommends Pod Identity whenever possible. That recommendation is a starting point, not permission to ignore compatibility and change risk.
Keep IRSA when the workload runs on an environment that Pod Identity does not support, including AWS Fargate and Windows nodes according to current AWS guidance, or when the application uses an unsupported AWS SDK. IRSA is also reasonable when it is already standardized, audited, and stable, especially if a migration would deliver little operational benefit.
A mixed cluster is valid. A platform team can use Pod Identity for compatible new applications and retain IRSA for legacy or exceptional workloads. The important control is to record which credential path each service account should use and prevent node-role credentials or embedded keys from silently becoming a third path.
| Situation | Preferred starting point | Reason |
|---|---|---|
| New application on supported EC2-based nodes | EKS Pod Identity | Simpler cluster association and no per-cluster OIDC provider |
| Existing, reliable IRSA deployment | Keep IRSA or migrate selectively | Avoid change without a clear operational benefit |
| Pod on AWS Fargate or Windows node | IRSA | Pod Identity Agent is not supported in these environments |
| Multi-cluster role reuse | EKS Pod Identity | One service-principal trust can support associations across clusters |
| Direct OIDC federation pattern already required | IRSA | The existing trust and controls may match the intended architecture |
| Cross-account resource access | Evaluate both | Pod Identity uses role chaining; IRSA can use direct OIDC trust or chaining |
Continue reading: Amazon EKS complete guide · AWS EKS multi-account guidance ↗
Check every Pod Identity prerequisite
Do not create an association until the cluster, nodes, network, SDK, and IAM roles are ready. The EKS Pod Identity Agent is installed as an EKS add-on on ordinary supported nodes and is preinstalled in EKS Auto Mode. The agent must run on every eligible node that can host the workload. Its node role needs permission for eks-auth:AssumeRoleForPodIdentity.
Nodes must reach the EKS Auth API. Private-subnet designs may need an AWS PrivateLink interface endpoint for that API. The agent listens on defined local IPv4 and IPv6 addresses; AWS documents an agent setting for nodes where IPv6 loopback is unavailable. Treat agent health and EKS Auth connectivity as production dependencies, not one-time installation checks.
The application or add-on must use an AWS SDK version that supports the container credential provider used by Pod Identity. A container image can start normally while an older SDK fails to discover credentials, so test the exact image digest that will run in production. Also check the current compatibility table for EKS-managed add-ons rather than assuming every installed version supports Pod Identity.
- Supported EKS cluster and platform version in the selected Region.
- Eligible node type with the Pod Identity Agent running and ready.
- Network access from nodes to the EKS Auth API, including private endpoint design where required.
- Node role permission for eks-auth:AssumeRoleForPodIdentity.
- Supported AWS SDK or AWS CLI version inside the deployed image.
- IAM role trust for pods.eks.amazonaws.com with sts:AssumeRole and sts:TagSession.
- Operator permission to create the EKS association and pass the selected IAM role.
Continue reading: AWS: set up the Pod Identity Agent ↗
Build an identity inventory before migration
Begin with an evidence register, not a bulk script. For every Kubernetes service account, record the cluster, namespace, workload owner, controller, node type, current IAM role, attached and inline policies, permissions boundary, role trust, service-account annotation, SDK family and version, target AWS resources, cross-account calls, and CloudTrail evidence of actual use.
Separate workload permissions from node permissions. A pod that has been falling back to the EC2 node role may appear healthy even when IRSA is broken. Use IAM Access Analyzer, CloudTrail, application logs, and a controlled test to understand which actions and resources are required. Remove unused permissions as a separate reviewed change when possible; combining a credential migration with an unbounded policy rewrite makes failures harder to diagnose.
Classify workloads by migration risk. Start with a stateless, low-impact workload that uses a modern SDK and a small permission set. Delay critical controllers, storage components, ingress systems, payment workloads, and cross-account automations until the team has observed at least one successful cutover and rollback exercise.
| Record | Why it matters | Evidence |
|---|---|---|
| Service account and workload | Defines the association and restart scope | Rendered manifests and live Kubernetes objects |
| Current credential path | Reveals IRSA, node-role, or static-key fallback | Environment, token mounts, SDK logs, and caller identity |
| IAM role and policy | Preserves least privilege during cutover | Role trust, policies, boundary, and Access Analyzer |
| SDK and image | Confirms container credential-provider support | Image digest, dependency lockfile, and runtime version |
| AWS API use | Defines positive and negative tests | CloudTrail events and application runbooks |
| Owner and rollback | Makes the change reversible | Named approver, maintenance window, and recovery step |
Continue reading: EKS security best practices
Configure the role and Pod Identity association
The target IAM role must trust the EKS Pod Identity service principal and allow both sts:AssumeRole and sts:TagSession. AWS security guidance recommends adding appropriate condition keys, such as organization-level source conditions, to reduce confused-deputy risk. Design the condition for the actual account and organization structure; do not paste an example without verifying what values EKS will supply.
Create the association with the cluster name, Kubernetes namespace, service-account name, and IAM role ARN. The association is an EKS resource; it does not require adding a new annotation to the Kubernetes service account. The caller needs permission to pass the role, so restrict who can create or update associations and audit those API calls.
A service account can have one Pod Identity role association, while a role may be reused by multiple associations. Reuse does not justify broad permissions. Session tags can support attribute-based conditions, but tags and policies must be tested together so a namespace or cluster cannot receive access intended for another workload.
# Confirm the agent add-on before changing a workload
aws eks describe-addon \
--cluster-name example-cluster \
--addon-name eks-pod-identity-agent
# Create one association for one controlled service account
aws eks create-pod-identity-association \
--cluster-name example-cluster \
--namespace application \
--service-account orders-reader \
--role-arn arn:aws:iam::111122223333:role/orders-reader
# Record the returned association ID, then verify the mapping
aws eks list-pod-identity-associations \
--cluster-name example-clusterContinue reading: AWS: understand how Pod Identity works ↗ · AWS EKS identity and access best practices ↗
Migrate one workload with a reversible cutover
Keep the IRSA trust and service-account annotation in place during the first cutover. Add Pod Identity trust to the existing role or use a new role with equivalent reviewed permissions, install and validate the agent, then create the association. New or restarted pods receive the Pod Identity environment variables and projected token; existing pods should not be assumed to change without recreation.
AWS explains that the SDK credential provider chain stops at the first valid source. Pod Identity uses the container credential provider. Credentials configured earlier in the chain can continue to win, which is useful for staged migration but can also hide the path actually being used. Remove embedded environment credentials and explicit credential-provider code from the test case, and collect evidence showing which identity the application receives.
Restart only the selected deployment or job during a controlled window. Run the business transaction that depends on AWS access, verify the caller identity, inspect CloudTrail, and confirm both allowed and intentionally denied actions. Observe credential refresh rather than stopping after a single successful call. If the application fails, restore the previous deployment state or remove the association and return to the verified IRSA path according to the runbook.
A safe migration sequence
Treat each step as an evidence gate. Do not remove the old trust merely because the pod started.
- Freeze the service-account, role, policy, image, and test baseline.
- Add Pod Identity trust while retaining the existing IRSA trust.
- Confirm agent health, EKS Auth connectivity, and supported SDK behavior.
- Create one association and record its identifier and change owner.
- Restart only the selected workload and verify the credential source.
- Test required API actions, expected denials, refresh, scaling, and node rescheduling.
- Observe for an agreed period before removing the IRSA annotation and OIDC trust statement.
Continue reading: EKS upgrade runbook
Validate identity, permissions, and failure behavior
Validation must prove more than successful authentication. From the test workload, call STS GetCallerIdentity or use equivalent SDK logging in a protected test path to confirm the assumed role. In CloudTrail, check the role session, source cluster context, expected service actions, and absence of unexplained node-role use. Do not expose credentials or full tokens in logs.
Run positive tests for each essential API path and negative tests for actions and resources the workload must not access. Recreate the pod, scale the deployment, reschedule it to another eligible node, and observe credential refresh over time. Confirm that the workload fails safely if the association is removed, the agent is unavailable, or EKS Auth connectivity is blocked in a non-production test.
Rollback is configuration recovery, not credential reuse. Keep the previous IRSA trust and annotation until Pod Identity has passed the observation window. Record the commands and approvals required to remove the association, restart the workload, and confirm that IRSA resumes. If a policy changed at the same time, retain a reviewed previous version so the team can separate permission failure from credential-path failure.
- Correct role returned for the intended cluster, namespace, and service account.
- Required AWS API calls succeed against only the intended resources.
- Unapproved actions and resources remain denied.
- New pods, scaled replicas, and rescheduled pods receive credentials.
- Credential refresh works without application restart or manual keys.
- CloudTrail shows the expected sessions and no hidden node-role fallback.
- Documented rollback restores the previous path within the maintenance objective.
Handle cross-account access and unsupported workloads
For cross-account access, AWS documents Pod Identity role chaining. The association points to a role in the same account as the EKS cluster, and that role assumes a target role in the resource account. Current EKS association options can identify a target role for this pattern. Review both trust policies, the effective permissions across the chain, session duration, audit records, and the application's SDK behavior.
IRSA can use an OIDC provider in the target account for direct AssumeRoleWithWebIdentity or use role chaining. If the organization already has a controlled direct-federation pattern, do not migrate solely to reduce the number of visible resources. Compare auditability, quota behavior, separation of duties, incident response, and the operational owner for each trust relationship.
Keep a documented exception list for Fargate, Windows nodes, older SDKs, unsupported add-ons, EKS Anywhere, ROSA, self-managed Kubernetes, and any Region or platform limitation in current AWS documentation. Revisit exceptions during image updates, add-on upgrades, and cluster lifecycle reviews rather than allowing them to become permanent undocumented debt.
Continue reading: Amazon ECS vs EKS comparison · AWS: IAM roles for service accounts ↗
Operate workload identity as a controlled service
After migration, treat Pod Identity associations as production access resources. Manage them through version-controlled infrastructure, require review for role and association changes, and reconcile the intended mapping against the EKS API. Alert on unexpected CreatePodIdentityAssociation, UpdatePodIdentityAssociation, and DeletePodIdentityAssociation activity, as well as changes to role trust and permission policies.
Patch the Pod Identity Agent through the normal add-on lifecycle and monitor its availability on eligible nodes. Include EKS Auth reachability in private-network tests. During cluster upgrades, verify the agent and workload SDK compatibility alongside networking, storage, controllers, and other add-ons rather than treating identity as independent of the platform lifecycle.
Review roles and associations on a schedule and when a workload, namespace, owner, account, or data classification changes. Delete orphaned associations, narrow unused permissions, rotate away from static keys, and retain evidence of the review. A simpler credential mechanism is valuable only when the organization continues to operate least privilege, observability, and change control around it.
Continue reading: EKS security best practices checklist
Frequently asked questions
Does EKS Pod Identity replace IRSA?
No. AWS recommends EKS Pod Identity whenever possible, but IRSA remains supported. IRSA is still appropriate for unsupported Pod Identity environments, established OIDC patterns, and workloads where a migration has no justified operational benefit.
Can EKS Pod Identity and IRSA run in the same cluster?
Yes. A cluster can use Pod Identity for compatible workloads and IRSA for others. During migration, both trust paths may temporarily exist, but teams must verify which credential provider the application actually uses before removing the old configuration.
Does EKS Pod Identity work with AWS Fargate?
No, current AWS guidance lists Fargate as an environment where EKS Pod Identity is not supported. Use IRSA for eligible Fargate workloads and recheck AWS documentation before changing the design.
How should a team roll back a Pod Identity migration?
Retain the verified IRSA trust and service-account annotation through the observation window. If Pod Identity fails, remove or disable the association as documented, restart the controlled workload, verify that IRSA credentials return, and confirm both required access and expected denials before closing the rollback.