EKS Pod Identity has been generally available for long enough that the decision between it and the older IRSA (IAM Roles for Service Accounts) is no longer academic. The AWS documentation treats them as roughly equivalent, with a preference for Pod Identity for new workloads. For general application access to AWS APIs, that is approximately true. For supply chain workloads — signers, SBOM generators, policy enforcers, release publishers — the choice is less obvious, because the trust semantics and failure modes differ in ways that matter at the margin.
I have rolled out both in production EKS fleets and migrated between them more than once. This is the comparison I wish I had at the start.
Why does the choice matter for supply chain workloads specifically?
Because supply chain workloads usually hold privileged identities — they can sign artifacts, push to registries, modify attestations — and the cost of a misconfigured identity is a compromised release. For a web application that reads from DynamoDB, the difference between Pod Identity and IRSA is mostly operational. For a signing service, the difference is trust boundary design.
The two mechanisms both provide short-lived STS credentials to pods. They differ in how the trust is established, what the credential carrier looks like, and what happens when something fails.
IRSA uses the EKS-native OIDC issuer. The service account has an annotation pointing at an IAM role; the pod runs with the service account; the pod's projected service account token is exchanged for STS credentials via the OIDC trust relationship on the IAM role. This is a fully standards-based flow and it works anywhere an OIDC-compatible cluster can issue tokens.
Pod Identity uses a cluster-attached EKS agent that injects credentials directly into the pod. The trust is established through a Pod Identity Association resource on the cluster; there is no OIDC exchange from the pod's perspective. AWS handles the credential delivery through a node-local endpoint.
Both produce short-lived credentials. Both scope identities at the service account level. The differences show up in the details.
What are the supply chain-relevant differences in trust model?
Pod Identity's trust is cluster-scoped: an association is defined on the cluster and takes effect for the service account in that cluster. IRSA's trust is issuer-scoped: the IAM role trusts the cluster's OIDC issuer URL, which means that any cluster using the same issuer can assume the role. That difference is subtle and it has bitten me in production.
The IRSA issuer scoping matters if you ever restore a cluster from backup, recreate a cluster with the same issuer, or use a shared issuer across multiple clusters. If you have two clusters with the same OIDC issuer, an IAM role trusted by that issuer can be assumed by service accounts in either cluster. Most EKS deployments do not share issuers, but some do — particularly organizations that run blue/green clusters behind a load balancer — and the trust boundary is not what you would naively expect.
Pod Identity does not have this problem because the trust is on the cluster object directly. A role associated with cluster A cannot be assumed by workloads in cluster B, even if cluster B somehow has the same service account name and namespace. For supply chain workloads where the trust boundary is important, this is a meaningful simplification.
The counter-argument is that Pod Identity is AWS-proprietary and IRSA is a portable OIDC pattern. If you want the same identity model to work on clusters outside AWS, or if you want to federate from EKS to another cloud's resources using the same OIDC tokens, IRSA is the abstraction that keeps working. Pod Identity does not.
Which one handles rotation and revocation better?
Pod Identity has better rotation semantics out of the box; IRSA has more control for teams that already own their rotation tooling. Pod Identity credentials are managed entirely by AWS, with a refresh cadence that the EKS agent handles. You do not configure the TTL, you do not see the refresh logic, and you generally do not need to. Revocation is handled by removing the Pod Identity Association, which takes effect cluster-wide within seconds.
IRSA credentials are refreshed by the AWS SDK using the projected service account token. The projected token has a configurable TTL — the default is an hour — and the SDK handles rotation. Revocation requires either removing the service account annotation and restarting pods, or updating the IAM role's trust policy to exclude the specific subject. Neither is instant, and if pods cache their credentials, there is a window where a revoked identity still works.
For supply chain workloads, the revocation question is the one that matters. If a signer is compromised, how fast can I turn off its ability to sign? With Pod Identity, it is seconds — delete the association, the EKS agent refuses to issue further credentials. With IRSA, it is as fast as the IAM policy change propagates plus the credential TTL of the compromised pod, which could be up to an hour.
How do authorization boundaries compare?
Pod Identity supports session tags that include the cluster name, namespace, and service account. IRSA supports session tags via the subject claim, but the decomposition is less convenient. For authorization policies that discriminate on which cluster or namespace the workload is in, Pod Identity is the better primitive.
The concrete example: you have a production signing key in KMS, and you want to allow only workloads in the signing namespace of the production cluster to use it. With Pod Identity, the key policy has a condition like aws:PrincipalTag/eks-cluster-name = prod and aws:PrincipalTag/kubernetes-namespace = signing. With IRSA, you have to parse the subject claim in the role's trust policy, and the condition language is more awkward.
This decomposition also makes Pod Identity easier to reason about in CloudTrail. Every API call from a Pod Identity workload is logged with the cluster, namespace, and service account in the session identity. For incident response on a supply chain compromise, that telemetry is directly actionable.
What about the Pod Identity Agent as a failure domain?
The EKS Pod Identity Agent is a daemonset on each node. If it fails, no workload on that node can get credentials. This is a single-node failure mode; the broader cluster keeps running. Most teams will not notice until a specific workload starts failing with credential errors.
IRSA does not have this failure domain. Credentials are fetched directly via STS with no cluster-level agent in the path. For workloads that need to tolerate infrastructure failures — which includes most release-critical supply chain jobs — this is a point in IRSA's favor.
The mitigation for Pod Identity is monitoring: alert on the agent daemonset's health, and have a fallback path for critical workloads. Alternatively, run critical supply chain workloads on dedicated node pools with aggressive health checks so that a failed agent causes the node to drain rather than silently failing pods.
Which one should I pick for new supply chain work in 2026?
Pod Identity for clusters that will stay on AWS, IRSA for clusters that need OIDC portability, and never mix them for the same workload. The failure mode of mixing is that a single service account ends up with both configurations, the precedence is not obvious, and debugging the wrong credential is miserable.
The migration from IRSA to Pod Identity is generally smooth if you audit IAM role trust policies before removing the OIDC trust. Leave both configured during a transition window, confirm the workload is using Pod Identity via CloudTrail, then remove the IRSA annotation and the OIDC clause from the role's trust policy.
How Safeguard.sh Helps
Safeguard.sh tracks EKS Pod Identity and IRSA associations across the fleet and correlates them with reachability analysis on the workloads using each identity, so privileged supply chain credentials are audited against the code paths that actually use them — reachability cuts 60 to 80 percent of identity-related findings that would otherwise surface in compliance reports. Griffin AI generates Pod Identity Associations, IRSA trust policies, and session tag-based authorization rules from the existing workload graph and alerts when they drift from the Git source of truth. Safeguard's SBOM module joins every identity to the artifacts it signs or publishes at 100-level dependency depth, its TPRM module tracks external roles any federated identity can assume, and container self-healing rewrites workload manifests automatically when a patched image needs to be deployed with the correct supply chain identity.