🔐 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.