Amazon EKS — EKS Pod Identity

EKS Pod Identity is a simpler alternative to IRSA. It eliminates the need for OIDC providers and complex trust policies — you create a pod identity association directly via the EKS API.

---

How It Works

1. Install the Pod Identity Agent add-on (runs as a DaemonSet)
2. Create a pod identity association linking an IAM role to a K8s ServiceAccount
3. The agent intercepts AWS SDK credential requests from pods
4. Pods automatically receive temporary credentials for their associated IAM role

---

Setup

Step 1 — Install Pod Identity Agent

aws eks create-addon \
  --cluster-name my-cluster \
  --addon-name eks-pod-identity-agent

Verify:

kubectl get pods -n kube-system -l app.kubernetes.io/name=eks-pod-identity-agent

Step 2 — Create the IAM Role

The trust policy for Pod Identity is simpler than IRSA:

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

aws iam create-role \
  --role-name S3ReaderPodIdentity \
  --assume-role-policy-document file://pod-identity-trust.json

aws iam attach-role-policy \
  --role-name S3ReaderPodIdentity \
  --policy-arn arn:aws:iam::123456789:policy/S3ReadPolicy

Step 3 — Create the Pod Identity Association

aws eks create-pod-identity-association \
  --cluster-name my-cluster \
  --namespace production \
  --service-account s3-reader-sa \
  --role-arn arn:aws:iam::123456789:role/S3ReaderPodIdentity

Step 4 — Create the ServiceAccount and Pod

apiVersion: v1
kind: ServiceAccount
metadata:
  name: s3-reader-sa
  namespace: production
  # No annotation needed! (unlike IRSA)
---
apiVersion: v1
kind: Pod
metadata:
  name: s3-test
  namespace: production
spec:
  serviceAccountName: s3-reader-sa
  containers:
    - name: app
      image: amazon/aws-cli:latest
      command: ["sleep", "infinity"]

kubectl exec s3-test -n production -- aws s3 ls s3://my-bucket/

---

IRSA vs Pod Identity

Feature	IRSA	Pod Identity
OIDC provider required	Yes	No
Trust policy complexity	Complex (OIDC URL + conditions)	Simple (pods.eks.amazonaws.com)
ServiceAccount annotation	Required (eks.amazonaws.com/role-arn)	Not required
Cross-account	Via trust policy conditions	Native (same trust policy)
Association management	IAM + K8s (distributed)	EKS API (centralized)
Fargate support	Yes	Yes (EKS 1.29+)
Region dependency	Trust policy contains region-specific OIDC URL	Region-independent
Reusability	Role tied to specific cluster OIDC	Role reusable across clusters

---

Cross-Account Access

Pod Identity simplifies cross-account access:

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

---

Managing Associations

# List associations
aws eks list-pod-identity-associations --cluster-name my-cluster

# Describe a specific association
aws eks describe-pod-identity-association \
  --cluster-name my-cluster \
  --association-id a-abcdef1234567890

# Delete an association
aws eks delete-pod-identity-association \
  --cluster-name my-cluster \
  --association-id a-abcdef1234567890

---

Migration from IRSA

1. Install the Pod Identity Agent add-on
2. Create Pod Identity associations for each ServiceAccount
3. The agent takes precedence — pods automatically use Pod Identity
4. Remove the eks.amazonaws.com/role-arn annotation from ServiceAccounts
5. Clean up IRSA IAM roles when confirmed

Tip: Pod Identity and IRSA can coexist during migration. Pod Identity takes precedence when both are configured.

---

Best Practices

1. Use Pod Identity for new clusters — simpler setup and management
2. Centralize associations — manage all pod-role mappings via EKS API
3. Use SourceAccount condition for cross-account — restricts which accounts can use the role
4. One role per application — maintain least privilege
5. Migrate from IRSA incrementally — both can coexist during transition

---