EKS: Pod Identity and IRSA

03 Aug, 2025

Source material:

• https://www.youtube.com/watch?v=aUjJSorBE70&pp=0gcJCccJAYcqIYzv

The purpose of Pod Identity is to allow EKS workloads to connect to other AWS services in a secure way.

Previously, this was done by IRSA, which associates an IAM Role with a Kubernetes Service Account and configure Pods to use it.

IRSA is still available to use, but Pod Identity aims to provide a more streamlined approach. The main benefit is that Pod Identity does not require an OIDC provider, so you can use a single IAM Role across multiple clusters.

IRSA requires the cluster to have an OIDC provider. This becomes somewhat of a burden when you are running a lot of clusters. With IRSA, an IAM Role's trust policy is specifically configured to trust the OIDC provider of a single EKS cluster. You can't use the same IAM Role for a Service Account in a different cluster because the OIDC provider is not the same, and the trust policy has (probably) not been configured to trust the other OIDC provider. You can edit the trust policy to trust multiple OIDC providers but this becomes hard to maintain.

This is the flow with IRSA + OIDC:

1. A Pod is created with a serviceAccountName annotation
2. An EKS webhook injects special env vars (AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE) and mounts a volume that contains a signed OIDC token into the pod
3. The application in the Pod makes a request to an AWS service (e.g. with boto3)
4. The application finds the special env vars and reads the OIDC token from the volume path and calls the sts AssumeRoleWithWebIdentity API
5. IAM verifies the role assumption request from sts
6. sts issues temporary credentials scoped to the permissions of the granted IAM Role
7. The application receives the temporary credentials and caches them and uses them for all AWS requests

Pod Identity requires:

• An IAM Role that defines the permissions for a Pod(s)
• A Pod Identity Agent - a Kubernetes Deployment that should probably be installed as an EKS Addon. It mutates the Pod spec to make sure it has the right credentials. No more OIDC provider or tokens.
• An Association - an EKS configuration that ties together the IAM Role ARN + namespace + Service Account.

Here is the flow with Pod Identity:

1. Prerequisites need to be met -- Pod Identity Agent is installed, IAM Role exists, an Association has been created.
2. A Pod is created and configured to use the associated Service Account
3. Pod Identity Agent detects a new pod and mutates the pod spec before the application starts. It injects env vars, most notably AWS_CONTAINER_CREDENTIALS_RELATIVE_URI, which is the local credentials endpoint served by the Pod Identity Agent.
4. Application makes a request to an AWS API via an SDK -- PIA runs as a daemonset, so every Pod will be able to reach it.
5. The SDK makes a request to the Agent's credentials endpoint
6. Agent provides valid, temporary credentials and the application uses them for AWS API requests

#eks #kubernetes