Note: This post assumes an AWS Elastic Kubernetes (EKS) cluster. Using IRSA with other cluster providers is possible but requires extra configuration.

What is IRSA?

IAM Roles for Service Accounts (IRSA) is a way to give your Kubernetes pods permission to access AWS resources, like uploading files to S3 buckets or inserting items into Dynamodb. This is accomplished by linking the pod’s service account in Kubernetes to an IAM role in AWS, so that the pod effectively assumes the required AWS IAM role.

Why IRSA?

The simplest alternative to IRSA is to create an IAM user that can assume the necessary IAM role, and then create AWS credentials (Access Key Id and Secret Access Key) that can be passed to the pod as a Kubernetes secret. The downside to this is the creation of static credentials and the need to manage these credentials by creating Kubernetes secrets, rotating the keys, etc. IRSA allows your pods to assume IAM roles without the need to create and manage static credentials.

How it works

IRSA relies on the OIDC identity provider associated with your EKS cluster. When a pod needs to access AWS resources, it requests a JSON Web Token (JWT) from the OIDC provider, which serves as proof of the pod’s identity.

Figure 1: IRSA Flow

sequenceDiagram
    participant Pod
    participant AWS STS
    participant oidc as OIDC Provider (EKS Cluster)
    participant AWS Services

    Pod->>oidc: Request OIDC token (JWT)
    oidc-->>Pod: Returns JWT as proof of identity
    Pod->>AWS STS: AssumeRoleWithWebIdentity (presents JWT proving identity)
    AWS STS-->>Pod: Issues temporary AWS credentials (access key ID, secret access key, and session token)
    Pod->>AWS Services: API calls, authed with temporary credentials

How to implement