IRSA, AWS's first serious answer to giving Kubernetes pods scoped IAM permissions, has been the de facto pattern on EKS since 2019. EKS Pod Identity landed in late 2023 as a replacement and AWS has been steadily pushing customers toward it through 2024 and 2025. By 2026, most new EKS deployments default to Pod Identity, and most established clusters are somewhere in the middle of a migration that nobody fully scoped. This post is the playbook for finishing that migration cleanly.
A note: Pod Identity and IRSA can coexist on the same cluster, and that is fine as a long-term state in many cases. The goal is not to eliminate IRSA reflexively; it is to migrate the workloads where Pod Identity provides real value and leave the rest alone.
How does Pod Identity actually differ from IRSA?
IRSA works by configuring an OIDC provider that AWS trusts for the cluster, mapping Kubernetes service accounts to IAM roles via a trust policy on each role, and injecting a projected service account token that the AWS SDK exchanges for temporary credentials. The mechanism is elegant but operationally heavy: every IAM role needs a trust policy referencing the specific OIDC issuer for the cluster, which means every cluster has its own per-role configuration overhead.
Pod Identity replaces the OIDC trust dance with an EKS-native association resource. You create an association tying a service account in a specific namespace to an IAM role, and the EKS Pod Identity Agent on the node handles credential delivery. The role's trust policy now just needs to trust pods.eks.amazonaws.com, which is identical across clusters. The operational impact: per-cluster role configuration goes away, cross-cluster role reuse becomes trivial, and the IAM trust policies stop accumulating cluster-specific cruft.
What are the actual migration steps?
Inventory first. List every IRSA-configured service account across every cluster, with the role it maps to and the workloads using it. The teams we see migrate fastest are the ones that build this inventory before changing any configuration. It surfaces the surprises early: service accounts that point to roles nobody owns, roles with trust policies covering clusters that no longer exist, and workloads using IRSA that should have been deleted three quarters ago.
Then deploy the EKS Pod Identity Agent to each cluster. The agent runs as a DaemonSet and the installation is well-documented; budget about an hour per cluster including testing. Create Pod Identity associations for each service account, in parallel with the existing IRSA configuration. The credential resolution order means Pod Identity takes precedence when both are configured, so the cutover happens implicitly once the association exists. After verifying workloads are using Pod Identity credentials, remove the IRSA-specific annotations from the service accounts and clean up the OIDC trust policy entries on the IAM roles.
What are the operational gotchas?
The first gotcha: not every AWS SDK version supports Pod Identity. The credential provider chain in older SDKs does not know to look for the Pod Identity Agent endpoint. AWS SDK for Java 1.x, AWS SDK for Python earlier than boto3 1.29, and several language SDKs from before 2023 need explicit upgrades. Run the SDK version audit before the cutover, not during the cutover.
The second gotcha: cross-account role assumption patterns sometimes break in subtle ways. IRSA's OIDC-based trust model is natively comfortable with cross-account configurations; Pod Identity introduces an extra hop through the EKS service principal that requires more explicit IAM configuration. The migration path is documented but the documentation has improved through 2025 and earlier writeups missed edge cases. Read the current AWS documentation for cross-account scenarios specifically, not blog posts from 2024.
The third gotcha: the Pod Identity Agent is a critical-path dependency. If the agent fails on a node, workloads on that node lose AWS credentials. The monitoring story for the agent improved with the 2025 EKS releases but it is not as battle-tested as the IRSA flow, which had no such agent. Set up explicit alerting on agent health and credential failure rates during the migration window.
When should I keep IRSA?
Keep IRSA for workloads that already work and are not changing. Migration for its own sake produces risk without value. The cases where Pod Identity provides clear benefit are new workloads, workloads that need cross-cluster role reuse, and clusters with very large numbers of service-account-to-role mappings where the per-role trust policy maintenance burden is meaningful.
Keep IRSA for workloads using SDK versions that do not support Pod Identity and cannot be upgraded for legitimate reasons. We see this most often with vendor-provided container images that pin older SDK versions and do not receive timely updates. Pushing those workloads through the migration creates pressure on the vendor to upgrade, which is sometimes the right answer and sometimes not. Make the call deliberately rather than reflexively.
How do I audit the migration safely?
The audit pattern that catches most migration bugs: instrument credential acquisition logging on a sample of workloads, compare credential source before and after the migration, and verify that the actual IAM permissions being exercised match expectations in CloudTrail. The instrumentation is straightforward for most language SDKs and the comparison is mechanical.
The bug pattern we see most often: a workload migrates to Pod Identity successfully and continues to function, but a different code path in the same workload silently falls through to the EC2 instance metadata service and acquires the node's IAM role credentials instead. This was always a risk with IRSA too, but Pod Identity's behavior during agent failures makes it slightly more likely. CloudTrail will show calls being made by the node role rather than the intended Pod Identity role, which is the canary you want to watch for. Build a CloudWatch alarm against unexpected node role usage and the audit is largely automated.
How Safeguard Helps
Safeguard's policy gates enforce IAM hygiene across your EKS deployments, including detection of workloads that fall through to node role credentials instead of using their assigned Pod Identity or IRSA configuration. SBOM analysis flags container images that pin older AWS SDK versions which will not work with Pod Identity, so the migration audit happens against your actual deployed image inventory rather than the intended one. Griffin AI surfaces AWS-specific CVEs and configuration drift against your cluster fleet, and TPRM scoring tracks vendor-provided images that may delay your migration timeline. Reachability analysis confirms which AWS API calls each workload actually makes, which is the data you need to scope Pod Identity associations correctly rather than over-permissioning roles out of caution.