Pod Identity

Pod Identity—often called IRSA v2—is the latest, native EKS method for assigning AWS IAM roles to Kubernetes pods. In this guide, you’ll learn how Pod Identity improves on Kube2IAM and IRSA by streamlining permissions management, removing annotation overhead, and integrating role mappings directly into the EKS control plane.

Recap: Kube2IAM vs. IRSA

Before diving into Pod Identity, here’s a quick comparison of earlier approaches:

Kube2IAM uses iptables rules to redirect 169.254.169.254 traffic to a proxy, which then fetches credentials based on pod annotations. IRSA introduced an OIDC identity provider and webhook that injects AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN into pod environments—trading complexity of iptables for OIDC setup.

Introducing Pod Identity

Pod Identity modernizes IRSA by embedding role-to-service-account mappings in the EKS control plane. Key benefits include:

• No external OIDC provider
• No pod-level AWS annotations
• Local credential proxy via DaemonSet
• Support for tag-based access control (ABAC)

Architecture Overview

Pods continue calling the AWS SDK normally. A mutating webhook in the EKS control plane injects environment variables pointing to a local, node-hosted proxy. A privileged DaemonSet uses host networking to listen for SDK requests, then interacts with the EKS API to issue temporary credentials.

This proxy authenticates using the node’s EC2 instance role and retrieves the correct IAM role for each service account.

Role-to-Service-Account Association

With Pod Identity, you no longer annotate ServiceAccount objects. Instead, run an EKS CLI command:

aws eks associate-service-account-role \
  --cluster-name my-cluster \
  --namespace default \
  --service-account my-app-sa \
  --role-arn arn:aws:iam::123456789012:role/MyPodRole

EKS stores this mapping internally. Your pod specs stay clean—no AWS-specific annotations needed.

Tag-Based Credentials (ABAC)

Pod Identity fully supports AWS attribute-based access control. Tag your AWS resources (for example, Environment=dev on an S3 bucket) and reference those tags in your IAM policies. At credential time, EKS evaluates both:

1. The service account ➔ IAM role mapping
2. Any resource tags defined in IAM policies

Request Flow

1. Submit a Pod spec referencing a ServiceAccount (no AWS annotations).
2. EKS webhook mutates the Pod spec, injecting AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE toward a local IP (e.g., 169.254.x.x).
3. At runtime, the AWS SDK in the pod calls the local proxy.
4. The proxy reads the service account token, contacts the EKS control plane, and requests credentials.
5. EKS checks the service-account→role mapping and any tag-based policies, then issues temporary credentials.
6. The proxy returns credentials to the SDK, which uses them for AWS API calls (e.g., PutObject to S3).

Limitations & Coexistence

You can run both IRSA and Pod Identity in the same cluster. EKS will prioritize Pod Identity for credential injection but still support IRSA workloads during your migration.

Feature Comparison

Next Steps

Now that Pod Identity handles IAM at the pod level, explore how to control ingress and egress with VPC security groups for Kubernetes workloads.

Links and References

• Amazon EKS Pod Identity Guide
• Kubernetes Service Accounts
• AWS IAM ABAC