AWS IAM Role Assumption in EKS: The Ultimate Guide to Kubernetes Security
When deploying workloads on Amazon Elastic Kubernetes Service (EKS), one of the most critical operational challenges is managing how your pods interact securely with other AWS services such as S3, DynamoDB, or SQS. This is exactly where AWS IAM Role Assumption in EKS — implemented through IRSA (IAM Roles for Service Accounts) — becomes absolutely essential.
What is IAM Role Assumption in EKS?
Historically, many developers assigned broad IAM permissions directly to underlying worker nodes. This created a massive security vulnerability: any pod scheduled on that node automatically inherited all of the node's permissions. IRSA solves this by allowing each individual pod to assume a specific AWS IAM role, enforcing granular security controls at the application tier. Your invoicing microservice can write to a specific billing S3 bucket while a frontend pod on the exact same node has absolutely no access to that bucket.
The Core Solution: IRSA
IRSA leverages an OIDC (OpenID Connect) identity provider to establish a secure, dynamic trust relationship between your Kubernetes cluster and AWS IAM. Every EKS cluster hosts a public OIDC identity provider URL. When a pod is deployed with a Service Account annotated with an IAM role ARN, the EKS control plane automatically injects a cryptographically signed JWT. The AWS SDK inside the pod uses this JWT to call the AssumeRoleWithWebIdentity API against AWS STS, which validates the token and returns temporary, short-lived credentials.
Why You Must Use IRSA
IRSA eliminates the noisy neighbor security risk entirely — a compromised container cannot pivot to access resources belonging to another service on the same node. Every API call is logged in AWS CloudTrail under the specific assumed role session name, making compliance audits significantly easier. Credentials provided by STS are temporary and rotate automatically, drastically reducing the risk of credential leakage and eliminating the need to manually manage static access keys as Kubernetes Secrets.
Critical Configuration Components
For role assumption to work flawlessly, three components must be aligned: the cluster's OIDC issuer URL must be registered within AWS IAM as a trusted identity provider; the IAM role must feature a trust policy explicitly allowing sts:AssumeRoleWithWebIdentity scoped to the specific OIDC provider, namespace, and Service Account; and the Kubernetes Service Account must be annotated with the eks.amazonaws.com/role-arn annotation. Missing or typographically incorrect annotations are the most common cause of role assumption failures in production environments.