IRSA vs EKS Pod Identity: Architecture, Trust, and Tradeoffs

The Evolution of Kubernetes IAM on AWS: IRSA vs EKS Pod Identity

For platform engineers managing Amazon EKS clusters, the boundary between Kubernetes service accounts and AWS Identity and Access Management (IAM) has historically been porous and complex. The dominant pattern for years has been IRSA. However, AWS introduced EKS Pod Identity to address specific architectural friction points in IRSA. This article dissects the mechanism-level differences between IRSA and EKS Pod Identity, focusing on how trust policies, STS sessions, and credential injection differ in practice.

The IRSA Mechanism: Direct Federation and the Assumption Bottleneck

IRSA relies on a direct federation between a Kubernetes Service Account and an IAM Role. To understand the friction, we must look at the data flow when a workload needs AWS credentials.

In an IRSA setup, a Kubernetes Service Account is annotated with an IAM role ARN. When a pod starts, the Kubernetes API server projects a JSON Web Token (JWT) into the pod’s filesystem at /var/run/secrets/eks.amazonaws.com/serviceaccount/token. This token is signed by the Kubernetes API server and includes the audience claim sts.amazonaws.com.

The application code inside the pod must then use the AWS SDK to call sts:AssumeRoleWithWebIdentity. This call presents the JWT to AWS STS. STS validates the token against the OIDC provider associated with the EKS cluster. If valid, STS checks the IAM Role’s trust policy.

The trust policy is the critical security boundary. It typically looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:sub": "system:serviceaccount:my-namespace:my-service-account",
          "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

This mechanism has two significant operational costs. First, every pod that needs AWS credentials must execute an HTTP request to STS. This adds latency to startup and consumes network resources. Second, the trust policy must explicitly list the service account name and namespace. If you have hundreds of microservices, you must manage hundreds of IAM roles or use wildcard conditions, which can complicate auditing and least-privilege enforcement.

EKS Pod Identity: Decoupling via the Agent

EKS Pod Identity changes the trust model by introducing an intermediary: the Pod Identity Agent. This agent runs as a daemonset on the worker nodes, not in the pods themselves.

When a pod is configured with a Pod Identity association, it no longer needs an IAM role ARN in its annotations. Instead, it uses a standard Kubernetes Service Account. The Pod Identity Agent on the node detects the pod’s service account and the associated IAM role ARN (stored in the EKS control plane metadata).

The mechanism proceeds as follows:

1. The Pod Identity Agent calls the EKS Auth API, which assumes the IAM role using sts:AssumeRole.
2. The agent injects the resulting temporary credentials (Access Key, Secret Key, Session Token) into the pod’s environment variables or file system.
3. The application code accesses AWS services using these injected credentials, just like before, but without ever calling STS directly.

This shift moves the credential acquisition burden from the application container to the node-level agent. The trust policy for the IAM role also changes. Instead of referencing the OIDC provider and specific service accounts, it references the Pod Identity Agent’s service-linked role or a specific principal associated with the EKS cluster’s pod identity capabilities.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}

Note that the exact condition keys may vary based on AWS updates, but the key insight is that the trust is delegated to the EKS control plane’s ability to authorize the agent, rather than the pod presenting a valid JWT.

Comparative Analysis: Tradeoffs in Implementation

The choice between IRSA and Pod Identity hinges on three factors: operational complexity, security granularity, and legacy compatibility.

Operational Complexity

IRSA requires manual annotation of service accounts and careful management of IAM role trust policies. For large clusters with dynamic namespaces, this can become unwieldy. Pod Identity simplifies this by decoupling the pod from the IAM role. The association is managed via the eksctl CLI or Terraform, and the agent handles the credential rotation and injection. This reduces the cognitive load on developers, who no longer need to understand OIDC tokens or STS assumptions.

Security Granularity

IRSA’s trust policy allows for fine-grained conditions based on the service account subject (sub) and additional tags. This is useful for strict least-privilege models where you want to ensure that only a specific service account can assume a role. Pod Identity also supports tagging, but the primary security boundary is the association itself. If an attacker compromises a pod, they can potentially misuse the injected credentials unless additional network policies or IAM permissions restrict access. However, IRSA’s reliance on the JWT means that if the token is leaked, it can be used until expiration, whereas Pod Identity credentials are rotated more frequently by the agent.

Legacy and Non-EKS Contexts

IRSA remains the only viable option for workloads running on self-managed nodes, on-premises Kubernetes clusters using OIDC, or in hybrid environments. Pod Identity is exclusive to EKS and requires the Pod Identity Agent to be installed on the node group. If you use managed node groups, Pod Identity is the recommended path forward; Fargate workloads still require IRSA, since Pod Identity is not supported there.

Best Practices and Migration Path

For new deployments, AWS recommends EKS Pod Identity. It reduces the attack surface by eliminating the need for pods to handle JWTs and makes credential management more centralized. However, migration from IRSA is not always straightforward. Existing IAM roles with trust policies pointing to OIDC providers must be updated to trust the Pod Identity service.

Platform engineers should audit their current IAM roles to identify those that are heavily dependent on specific service account conditions. These roles may require rearchitecting to use tag-based conditions or broader trust policies if moving to Pod Identity. Additionally, ensure that the Pod Identity Agent is deployed and updated regularly, as it is a critical component of the security chain.

Conclusion

IRSA laid the groundwork for secure Kubernetes workloads on AWS by bridging OIDC and IAM. However, its reliance on direct STS assumptions from within pods introduces latency and operational complexity. EKS Pod Identity addresses these issues by offloading credential acquisition to a node-level agent, simplifying trust policies and improving scalability. For platform engineers, adopting Pod Identity represents a shift towards more automated, less error-prone infrastructure, provided the cluster is fully managed by EKS.