IRSAIAM Roles for Service Accounts

• AWS EKS IRSA docs: https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html
• STS AssumeRoleWithWebIdentity: https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html
• Kubernetes ServiceAccount / TokenRequest API: https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#service-account-token-volume-projection
• IAM OIDC providers: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html

​

How IRSA works (summary)

1. The pod requests a bound service account token (a projected JWT) from the Kubernetes TokenRequest API.
2. The pod sends that JWT to AWS STS using AssumeRoleWithWebIdentity, specifying the IAM role ARN.
3. STS validates the JWT against the role’s trust policy (which references the cluster OIDC provider and constrains sub claims).
4. If valid, STS returns temporary AWS credentials that the pod uses to call AWS services (S3, DynamoDB, etc.).
5. When credentials expire the pod repeats the token + STS flow to refresh them.

​

Key components required for IRSA

​

Quick example: ServiceAccount YAML

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

​

Example IAM trust policy (simplified)

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

​

High-level sequence (step-by-step)

1. Create or register the cluster OIDC provider in the AWS account (EKS exposes the issuer URL after cluster creation).
2. Create an IAM role whose trust policy lists the OIDC provider as the Federated principal and permits sts:AssumeRoleWithWebIdentity. Constrain sub to the service account(s) that should assume the role.
3. Create a Kubernetes ServiceAccount annotated with the role ARN (annotation eks.amazonaws.com/role-arn).
4. Deploy pods that use that ServiceAccount. Pods request a bound token from the TokenRequest API and exchange it with STS.
5. STS validates the token and returns temporary credentials. The pod uses these credentials to call AWS APIs.
6. Token/credential rotation is handled by repeating the TokenRequest + STS exchange when credentials expire.

​

Operational and scale considerations

• OIDC provider limits: AWS accounts have limits on the number of IAM OIDC providers you can register. If you run many clusters in a single account, you must plan for OIDC provider limits and account boundaries.

• Bootstrapping and automation: The cluster OIDC issuer URL is available only after cluster creation. Automated CI/CD flows that attempt to fully provision IAM roles before cluster creation should instead create the cluster first (or delay role trust policy creation until the OIDC provider is known).

• Cross-cluster reuse and multi-account designs: Since IAM is per-account, reusing a single IAM role across multiple clusters requires trusting multiple OIDC providers or making broader trust policies. Both options increase complexity and may widen blast radius. Consider one role per cluster/namespace pattern for clearer boundaries.
• Runtime and refresh behavior: IRSA provides short-lived credentials via STS. Ensure workloads handle credential rotation or use AWS SDKs with automatic refresh support.

​

Management implications

• Alignment with Kubernetes: IRSA maps AWS permissions into Kubernetes ServiceAccounts, improving auditability and reducing pod annotation sprawl.
• Added AWS-side configuration: You must manage OIDC providers and trust policies in IAM, which introduces operational overhead when managing many clusters or regions.
• Alternatives: Node-scoped IAM (kube2iam/kiam) gives coarser-grained control (node-level) and may be simpler for small deployments. Newer EKS pod-identity integrations and community projects continue to evolve, offering different trade-offs.

​

Alternatives and future directions

• Use IRSA when you want fine-grained pod-level IAM permissions mapped directly to ServiceAccounts.
• Consider node-scoped approaches (kube2iam, kiam) for simpler, smaller clusters where node-level scoping is acceptable.
• Explore EKS-native pod-identity integrations or newer community projects if they reduce operational overhead for your environment.