IRSA to Pod Identity: Simplifying Secure Access in EKS

🚀 Demystifying AWS EKS Pod Identity: The Next Evolution Beyond IRSA

In the world of cloud-native architectures, secure identity management for workloads is non-negotiable. As Kubernetes continues to dominate container orchestration, AWS has steadily refined how Pods authenticate to AWS services — evolving from IRSA (IAM Roles for Service Accounts) to the newer, streamlined Pod Identity model.
Let’s unpack this transformation, understand how it works under the hood, and explore why it matters for DevOps engineers designing production-grade EKS clusters.

🔹 The Challenge: Secure AWS Access from Inside Pods

Applications running inside Pods often need to interact with AWS services — S3, DynamoDB, Secrets Manager, or CloudWatch.
Traditionally, this required embedding static credentials (Access Key and Secret Key) inside environment variables or configuration files.

That approach is risky:

1. Credentials can leak through logs or misconfigured volumes.
2. Rotation is manual and error-prone.
3. It violates the principle of least privilege.

AWS solved this elegantly with IRSA, and now even more seamlessly with Pod Identity.

🔹 IRSA: The OIDC Bridge Between Kubernetes and IAM

IRSA introduced a secure way for Pods to assume IAM roles using OIDC (OpenID Connect) federation.
Here’s the flow:
1. You create a Kubernetes Service Account (KSA).
2. You create an IAM Role with required permissions.
3. You configure a trust policy allowing tokens from your EKS cluster’s OIDC provider.
4. You annotate the Service Account with the IAM Role ARN.
5. When a Pod runs under that Service Account, AWS STS issues short-lived credentials automatically.

This was revolutionary — no static secrets, no manual rotation, and fine-grained IAM control per Pod.

But it came with operational overhead: managing OIDC providers, trust policies, and JSON conditions for every role.

🔹 Enter Pod Identity: Simplifying the Federation

AWS introduced EKS Pod Identity to remove that complexity.
Instead of manually configuring OIDC trust, AWS deploys a Pod Identity Agent (PIA) inside your cluster.

aws eks create-pod-identity-association \
  --cluster-name my-cluster \
  --namespace default \
  --service-account my-app-sa \
  --role-arn arn:aws:iam::<account-id>:role/MyAppRole

1. The Pod Identity Agent (a DaemonSet running on worker nodes) intercepts credential requests from Pods.
2. It calls the EKS Auth API (eks-auth:AssumeRoleForPodIdentity).
3. AWS STS issues short-lived credentials for the mapped IAM role.
4. The agent then returns those credentials to the Pod.

No OIDC trust JSON. No manual federation setup. Just declarative mapping.

🔹 Where the Pod Identity Agent Runs

A common misconception is that PIA runs in the control plane. In reality, it runs as a DaemonSet on worker nodes, ensuring proximity to your Pods.
Each node hosts a local endpoint (169.254.170.23) — similar to EC2’s metadata service — that Pods use to request credentials.
This design ensures low latency and isolates credential delivery per node.

🔹 IRSA vs Pod Identity: A Quick Comparison

🔹 Terraform Integration

resource "aws_eks_addon" "pod_identity_agent" {
  cluster_name  = aws_eks_cluster.my_cluster.name
  addon_name    = "eks-pod-identity-agent"
  addon_version = "v1.0.0-eksbuild.1"
}

🔹 Security and Operational Benefits

• No static credentials — short-lived STS tokens only.
• Automatic rotation — handled by AWS.
• Least privilege enforcement — per Service Account.
• Simplified setup — no manual OIDC trust management.
• Auditable mappings — via aws eks list-pod-identity-associations.

🔹 Real-World Use Case

Imagine a microservice that uploads logs to S3. With Pod Identity: You create a Service Account log-uploader-sa. Associate it with an IAM role granting s3:PutObject. Deploy your Pod with that Service Account. The Pod Identity Agent automatically provides credentials scoped to that role — no secrets, no manual rotation, no risk.

🔹 Closing Thoughts

Pod Identity represents the natural evolution of AWS’s identity model for Kubernetes. It abstracts away the OIDC complexity of IRSA while preserving its security principles. For architects and DevOps engineers, this means simpler infrastructure code, cleaner IAM boundaries, and stronger security posture.

As AWS continues to unify identity management across EC2, Lambda, and EKS, Pod Identity is a glimpse into the future — where every workload securely authenticates without ever touching a static key.