When I was building the AusMart EKS platform, I had to decide how pods would authenticate to AWS services. The two options: IRSA (IAM Roles for Service Accounts) and the newer EKS Pod Identity.

The Problem

Every microservice needs AWS credentials. The catalog service reads from DynamoDB. The orders service writes to SQS. The checkout service fetches secrets from Secrets Manager. Each service should only have access to what it needs — nothing more.

Why Not IRSA?

IRSA has been the standard for years. It works by annotating Kubernetes service accounts with an IAM role ARN, and the OIDC provider handles the token exchange.

The problem is what happens when it breaks.

If the OIDC provider is misconfigured, or the service account annotation is wrong, or the trust policy doesn’t match — the pod doesn’t get an error. It falls back to the node’s instance profile. Suddenly your catalog pod has the same permissions as the EC2 node it’s running on. You won’t notice until an audit, or worse, an incident.

IRSA fails silently.

Why Pod Identity

EKS Pod Identity takes a different approach. You create an association between the service account and the IAM role at the EKS API level. The EKS Pod Identity Agent (a DaemonSet) intercepts credential requests and provides the right role.

If the association is wrong or missing — the pod gets AccessDeniedException. Immediately. Loudly. Your monitoring picks it up. Your logs show it. The developer knows something is wrong before the code even runs.

Pod Identity fails loudly.

The Decision

For a production platform where security matters — and especially in environments with compliance requirements like PCI-DSS — I want failures to be obvious. Silent fallbacks are how privilege escalation bugs hide in plain sight for months.

Pod Identity also has simpler configuration. No OIDC provider to manage. No trust policy JSON to get right. The association is a single API call:

aws eks create-pod-identity-association \
  --cluster-name ausmart \
  --namespace catalog \
  --service-account catalog-sa \
  --role-arn arn:aws:iam::role/catalog-role

Less configuration means fewer places to make mistakes.

What I Learned

The best security decisions aren’t always about adding more controls. Sometimes they’re about choosing the tool that tells you loudest when something is wrong.

Every security group, every IAM role, every encryption key in the AusMart platform follows this principle: fail loud, fail fast, fail safe.