EKS Authentication Mechanisms - IRSA vs Pod Identity from an Attacker's Lens

Originally published on Medium in January 2026. Updated November 2026.

Imagine conducting a red team assessment for a client and you stumble into their EKS cluster through a misconfigured service. Now, what can you do from here? 
This is exactly what got me thinking: most people understand EKS internals and underlying authentication mechanisms from a DevOps perspective, but what do they look like through an attacker’s eyes? This post is a part of my “Breaking Kubernetes” series, where I will walk through various attack vectors I’ve encountered in real engagements. Today, we’re starting with the fundamentals   for EKS workload Identities - understanding how IRSA and Pod Identity actually work before we start breaking them.

Why This Matters?

I’ve been doing cloud penetration testing for about two years now, and time and again I’ve come across EKS clusters that can be compromised due to authentication misconfigurations or over permissive identity. DevOps teams often think, “How can an attacker even get inside the cluster?” so they go easy on internal hardening.
We keep making the same mistakes because we don’t think like attackers when we’re designing these systems.
The worst part? Most of these compromises could have been prevented if teams understood what these authentication mechanisms actually do under the hood.

There are two authentication mechanisms in AWS EKS: IRSA and Pod Identity.

We will understand both of these and then explore how an attacker finds this knowledge and leverage them for attacks.

IRSA: The Old Reliable (With Some Quirks)

IAM Roles for Service Accounts has been around since 2019, and honestly, it’s pretty clever. Instead of jamming AWS access keys into your pods (please tell me you’re not still doing that ;) ) or using over permissive instance profile role. IRSA uses OpenID Connect to let your pods assume IAM roles temporarily.

Here’s what actually happens when your pod needs to talk to AWS:

1. EKS sets up an OIDC provider endpoint (something like https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED891D7173E53JM9B716D3041E )
2. Your service account gets annotated with an IAM role ARN.
3. The EKS admission controller notices this and injects some environment variables and a token file.
4. Your application uses these to exchange the token for temporary AWS credentials

The magic happens in that token file at /var/run/secrets/eks.amazonaws.com/serviceaccount/token . It’s a JWT that basically says “I’m this service account in this namespace, and I promise I’m running in your EKS cluster.”

What This Looks Like in Practice

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: production
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/MyAppRole

When a pod uses this service account, EKS automatically injects:

• AWS_ROLE_ARN environment variable
• AWS_WEB_IDENTITY_TOKEN_FILE environment variable 
• The actual JWT token file

The AWS SDK picks these up automatically and handles the token exchange with STS.

The Trust Relationship That Makes It Work

The IAM role needs to trust your OIDC provider:

{  
  "Version": "2012-10-17",  
  "Statement": [  
    {  
      "Effect": "Allow",  
      "Principal": {  
        "Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED891D7173E53JM9B716D3041E"  
      },  
      "Action": "sts:AssumeRoleWithWebIdentity",  
      "Condition": {  
        "StringEquals": {  
          "oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED891D7173E53JM9B716D3041E:sub": "system:serviceaccount:production:my-app-sa"  
        }  
      }  
    }  
  ]  
}

That StringEquals condition on sub is crucial: it’s what stops other service accounts and namespaces from assuming your role. In production, also pin the aud claim to sts.amazonaws.com.

Pod Identity: The New Kid on the Block

AWS announced Pod Identity in late 2023, and it’s their attempt to simplify this whole process. Instead of dealing with OIDC providers and trust policies, you just tell EKS this service account should have this role and it handles the rest.

The architecture is different too. There’s a Pod Identity Agent running as a DaemonSet on every node, and it acts as a local credential service for your pods.

Setting It Up

The setup is refreshingly simple:

# Install the Pod Identity Agent addon
aws eks create-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent

# Create the association
aws eks create-pod-identity-association \
  --cluster-name my-cluster \
  --namespace production \
  --service-account my-app-sa \
  --role-arn arn:aws:iam::123456789012:role/MyAppRole

No OIDC provider. No trust policy modifications. No annotations on service accounts. The Pod Identity Agent handles credential retrieval and caching automatically.

How It Actually Works

When your pod needs AWS credentials:

1. The AWS SDK makes a request to the Pod Identity Agent (running on ‘169.254.170.23:80’)
2. The agent validates that the pod is allowed to use the requested role.
3. It retrieves credentials from EKS and caches them locally.
4. Your pod gets temporary credentials, just like with IRSA.

The difference is that all the token exchange happens between the agent and EKS APIs, not between your pod and STS.

Here’s what’s interesting from an attacker’s perspective: Pod Identity still uses a token file, but it’s located at ‘/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token’ .

This token can be sent in the authorization header to the Pod Identity Agent to retrieve AWS credentials , a detail that becomes crucial when we start thinking about exploitation techniques.

Attack Surface

Now here’s where it gets interesting from a red team perspective. Both systems are trying to solve the same problem: “How do we prove that this specific pod, running in this specific namespace, is allowed to assume this IAM role?”

But they solve it differently, which means they can be abused differently.

IRSA’s Attack Surface

With IRSA, the JWT token is sitting right there in the pod’s filesystem. If I compromise your pod, I can:

• Read the token file directly
• Extract the environment variables
  - Use the token from anywhere (until it expires)

The token is also fairly long-lived (1 hour by default) and gets refreshed automatically. From an attacker’s perspective, that’s a nice window of opportunity.

Pod Identity’s Attack Surface

Pod Identity is more interesting. The AWS credentials themselves never sit in the pod’s filesystem; the agent hands them out on request. Every pod can reach the agent at 169.254.170.23 by design, because that is how the SDK gets credentials. What protects it is the token check: the agent only returns credentials for a valid projected token that matches a Pod Identity association.

So if I compromise your pod, I can read that token and ask the agent for the same credentials your application gets. The credentials are still tied to your role and its permissions, but anything that role can do, I can do. The attack surface is different from IRSA, not absent.

What’s Coming Next

Understanding these authentication mechanisms is just the starting point. In the next post, I’ll walk through specific techniques for extracting and abusing tokens from both systems, including some methods I’ve used in real engagements.

We will cover:

• Token extraction techniques that go beyond just reading files
• How to abuse stolen tokens from outside the cluster
• Persistence mechanisms that survive pod restarts
• Detection evasion strategies

For now, I’d encourage you to go poke around your own EKS clusters. Look at how your service accounts are configured. Check what tokens are actually mounted in your pods. Understanding the legitimate flow is essential before you can spot the illegitimate ones.

A Quick Note

Everything I’m sharing in this series comes from authorised penetration testing engagements. Don’t use these techniques on systems you don’t own or don’t have explicit permission to test.

That said, if you’re defending EKS environments, understanding how these attacks work is essential. The threat actors certainly understand them.

What authentication mechanism are you using in your EKS clusters? Have you seen any interesting misconfigurations in the wild? Feel free to Dm me ,I’m always curious to hear what other security folks are seeing out there.

Next up: “EKS Token Theft and Abuse  :Compromising IRSA and Pod Identity Authentication”