🔐 Part 1 — IRSA vs EKS Pod Identity (Clear Comparison)

First — say this in interview:

Both IRSA and Pod Identity solve the same problem: giving pods AWS permissions without using node IAM role or static keys — but they use different mechanisms.

That’s a strong start.

✅ What Problem Both Solve

Without IRSA/Pod Identity:

Pod → uses node IAM role ➡ every pod gets same permissions ➡ huge blast radius risk ❌

Both solutions give: ✅ pod-level IAM ✅ least privilege ✅ no static credentials ✅ auditable access

🥇 IRSA — IAM Roles for Service Accounts

IRSA = OIDC + STS + ServiceAccount token method

Flow:

ServiceAccount → OIDC token → STS AssumeRoleWithWebIdentity → temp creds

✅ IRSA Characteristics

Uses Kubernetes OIDC issuer
Uses projected service account token
Pod calls STS directly
No agent required
Mature & widely used
Works everywhere EKS supports OIDC
Fully AWS-native method

🆕 EKS Pod Identity (Newer Model)

Pod Identity = agent-based credential vending

Flow:

Pod → Pod Identity Agent → EKS control plane → STS → creds

✅ Pod Identity Characteristics

Uses node agent (DaemonSet)
Does not require OIDC provider setup
Simpler config
Central credential broker
AWS-managed control plane integration
Less token plumbing visible

⚖️ IRSA vs Pod Identity — Interview Comparison Table (in words)

Say this verbally:

IRSA

OIDC based
no agent
pod talks to STS
more setup
very mature
fully transparent flow

Pod Identity

agent based
simpler setup
control plane mediated
newer feature
easier for teams
less moving parts for users

🧠 Interview Positioning Answer

If asked “which would you choose?”

Say:

Today I default to IRSA because it’s mature and widely adopted, but for new clusters I evaluate Pod Identity for simpler operational setup — especially when platform teams want centralized credential brokering.

That sounds balanced and senior.

🪪 Part 2 — What is OIDC (In EKS Context)

Don’t give textbook OAuth speech. Interviewers want EKS-specific OIDC.

✅ What is OIDC here?

OIDC = identity token issuer standard using signed JWT tokens.

In EKS:

Kubernetes API server acts as an OIDC issuer for service accounts.

Each cluster exposes:

https://oidc.eks.<region>.amazonaws.com/id/<cluster-id>

This is a public identity provider endpoint.

✅ What It Issues

Kubernetes issues signed JWT tokens for service accounts.

Token contains:

service account name
namespace
audience
expiry
issuer

These tokens are cryptographically signed.

✅ Why AWS Trusts It

You register this OIDC issuer with IAM as an OIDC identity provider.

IAM then trusts tokens signed by that issuer.

That trust enables STS web identity role assumption.

🔁 Part 3 — What is STS AssumeRoleWithWebIdentity

This is the core of IRSA. Many candidates fail here.

✅ Definition (Interview Style)

AssumeRoleWithWebIdentity is an STS API that allows a role to be assumed using an external OIDC/JWT token instead of AWS credentials.

No AWS keys required.

✅ IRSA Flow — Step by Step (Say This in Interview)

1️⃣ Pod runs with ServiceAccount 2️⃣ Kubernetes injects OIDC JWT token file 3️⃣ Pod calls STS AssumeRoleWithWebIdentity 4️⃣ STS validates token against IAM OIDC provider 5️⃣ Trust policy matches subject 6️⃣ STS returns temporary AWS credentials 7️⃣ SDK uses creds automatically

That’s the full chain.

📜 Trust Policy Example Logic (Conceptual)

Role trust policy says:

“Allow assume role if:

token issuer = this cluster OIDC
subject = this service account
namespace = this namespace”

This is how least privilege is enforced.

🔐 Why This Is Secure

✅ Security Properties

short-lived tokens
cryptographically signed
scoped to service account
no stored secrets
no node-role sharing
fully auditable in CloudTrail

⚠️ Common Interview Trap — Node Role vs IRSA

If interviewer asks:

“Why not just use node IAM role?”

Answer:

Because that gives every pod the same AWS permissions. A single pod compromise becomes full node privilege escalation. IRSA/Pod Identity reduces blast radius to pod level.

Strong answer.

🧨 Real Failure Modes (Bonus Interview Points)

Mention these = senior signal:

OIDC provider not created → IRSA fails
wrong audience field → STS reject
trust policy subject mismatch
token expired → auth errors
clock skew issues
service account annotation wrong

🧠 One-Shot Senior Interview Summary Answer

If they ask open-ended:

“Explain IRSA, OIDC, and web identity STS together.”

Say:

In EKS, IRSA uses the cluster’s OIDC issuer to generate signed service account tokens. IAM trusts that OIDC provider. Pods present the token to STS using AssumeRoleWithWebIdentity, which validates the token and issues temporary credentials for the mapped IAM role. That gives pod-level least-privilege AWS access without static keys or node-role overexposure.

✅ Scenario 1 — Access S3 from Pod using IRSA (IAM Roles for Service Accounts)

IRSA works by:

Linking Kubernetes ServiceAccount → IAM Role
Using OIDC federation
Pod gets AWS creds via projected token + STS AssumeRoleWithWebIdentity

Step 0 — Preconditions

EKS cluster exists
kubectl configured
AWS CLI configured
You have cluster admin access

Step 1 — Enable OIDC provider for EKS cluster

Check if exists:

aws eks describe-cluster --name <cluster-name> \
  --query "cluster.identity.oidc.issuer" --output text

Associate OIDC provider (if not already):

eksctl utils associate-iam-oidc-provider \
  --cluster <cluster-name> \
  --approve

Step 2 — Create IAM policy for S3 access

Example: read access to one bucket

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject","s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
      ]
    }
  ]
}

Create it:

aws iam create-policy \
  --policy-name eks-s3-read \
  --policy-document file://policy.json

Step 3 — Create IAM role for ServiceAccount

Using eksctl (simplest):

eksctl create iamserviceaccount \
  --name s3-sa \
  --namespace default \
  --cluster <cluster-name> \
  --attach-policy-arn arn:aws:iam::<acct>:policy/eks-s3-read \
  --approve

This does:

Creates IAM role
Adds trust policy with OIDC
Annotates ServiceAccount

Step 4 — Verify ServiceAccount annotation

kubectl get sa s3-sa -o yaml

You should see:

annotations:
  eks.amazonaws.com/role-arn: arn:aws:iam::<acct>:role/...

Step 5 — Use SA in Pod spec

apiVersion: v1
kind: Pod
metadata:
  name: s3-test
spec:
  serviceAccountName: s3-sa
  containers:
  - name: app
    image: amazon/aws-cli
    command: ["sleep","3600"]

Step 6 — Test inside pod

kubectl exec -it s3-test -- sh
 
aws s3 ls s3://my-app-bucket

Done. That’s IRSA working.

✅ Scenario 2 — Access S3 using EKS Pod Identity (Newer Method)

Blunt truth: This is operationally cleaner than IRSA. No OIDC fiddling. No SA annotations. AWS manages the credential injection via a Pod Identity Agent.

Pod Identity works by:

EKS control plane + Pod Identity Agent
IAM role bound directly to k8s ServiceAccount
Uses EKS credential service instead of STS web identity token

Step 0 — Preconditions

EKS version supports Pod Identity
AWS CLI updated
Add-on install allowed

Step 1 — Install Pod Identity Agent addon

aws eks create-addon \
  --cluster-name <cluster-name> \
  --addon-name eks-pod-identity-agent

Verify:

kubectl get pods -n kube-system | grep pod-identity

Step 2 — Create IAM role for pod

Trust policy is different from IRSA — uses pods.eks.amazonaws.com

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

Create role:

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

Attach S3 policy:

aws iam attach-role-policy \
  --role-name eks-pod-s3-role \
  --policy-arn arn:aws:iam::<acct>:policy/eks-s3-read

Step 3 — Create Pod Identity Association

This is the key step (no annotation needed):

aws eks create-pod-identity-association \
  --cluster-name <cluster-name> \
  --namespace default \
  --service-account s3-sa \
  --role-arn arn:aws:iam::<acct>:role/eks-pod-s3-role

Step 4 — Create ServiceAccount (plain)

apiVersion: v1
kind: ServiceAccount
metadata:
  name: s3-sa
  namespace: default

No annotations. Nothing fancy.

Step 5 — Pod spec same as before

spec:
  serviceAccountName: s3-sa

Step 6 — Test

kubectl exec -it s3-test -- aws s3 ls

Works.

⚔️ IRSA vs Pod Identity — Real Differences (No Marketing Talk)

🔹 Setup Complexity

IRSA

Needs OIDC provider
Needs trust policy with condition keys
Needs SA annotations
More moving parts

Pod Identity

No OIDC
No annotations
Single AWS association command
Cleaner

Winner → Pod Identity

🔹 Maturity

IRSA

Production proven for years
Used everywhere
Tooling ecosystem supports it

Pod Identity

Newer
Still rolling into org standards
Some enterprises not fully migrated yet

Winner → IRSA (today)

🔹 Security Model

Both are strong if configured correctly.

But mistakes happen more with IRSA because:

Wrong trust conditions
OIDC misbinding
Copy-paste policies

Pod Identity removes many human error points.

Winner → Pod Identity

🔹 Multi-cluster / Cross-account

IRSA:

Easier to design complex federation

Pod Identity:

Currently more cluster-local oriented

Winner → IRSA

🔹 Operational Burden

IRSA:

More YAML + IAM glue
More debugging pain

Pod Identity:

Less cognitive load
Easier onboarding for teams

Winner → Pod Identity

Eks Upgrade K8 Objects