IAM Roles for Service Accounts (IRSA) Guide for EKS

If an application on EKS needs to upload an image to an S3 bucket, how do you grant this permission?

• Wrong Way: Generating Access Key / Secret Key and embedding it in the pod (Security risk, rotation difficulty).
• Old Way: Granting S3 permission to the Worker Node's (EC2) IAM role. (All pods on that node get this permission, very dangerous).
• Correct Way: IRSA (IAM Roles for Service Accounts).

What is IRSA?

IRSA is a feature that maps Kubernetes Service Accounts to AWS IAM Roles. This way, only the pod using that Service Account has the permissions of that IAM role. Other pods cannot access it.

How to Install?

1. OIDC Provider: Create the IAM OIDC provider for your EKS cluster (Done once during cluster setup).
2. IAM Policy: Create a JSON policy granting S3 permission.
3. IAM Role: Create a role using this policy. In the Trust Relationship section, require trusting the EKS OIDC provider and a specific Service Account name (e.g., my-app-sa).
4. Service Account: Create a Service Account named my-app-sa on the Kubernetes side and add the role ARN as an annotation:

   metadata:
     annotations:
       eks.amazonaws.com/role-arn: arn:aws:iam::123:role/my-s3-role
   

Usage

When you launch your pod with this Service Account, EKS automatically injects AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE environment variables into the pod. AWS SDKs (Boto3, Go SDK, etc.) recognize these variables and automatically authenticate. You don't need to make any changes to your code.