AWS EKS Support

EKS IRSA vs EKS Pod Identity: pick one and set it up correctly.

Pods should get their own IAM permissions instead of sharing the node role. IAM Roles for Service Accounts (IRSA) and EKS Pod Identity both do this, with different setup and limits. We choose per cluster, configure trust correctly and fix the AccessDenied errors that follow.

IRSAOIDC provider per cluster
Pod IdentityAgent add-on and associations
Trust policyMost common failure point
Node roleShould not carry app permissions

When You Need This

The situations where this work pays for itself.

Signs it is time

  • Pods use the node instance role and have far more access than needed
  • Pods fail with AccessDenied or WebIdentityErr when calling AWS
  • You manage many clusters and the OIDC provider and trust policy per cluster is painful
  • You are adding a new add-on or controller that needs AWS permissions
  • An audit asks for per-workload IAM

What you get

  • Mapping of workloads to least-privilege roles
  • IRSA or Pod Identity configuration in code
  • Corrected trust policies and service account setup
  • Reduced node instance role

How we do it

A clear, safe process you can follow along with.

1. Inventory what uses AWS

We list workloads that call AWS APIs and what they actually call, using CloudTrail and IAM Access Analyzer policy generation, so each role starts from observed need instead of a wildcard.

2. Understand the two mechanisms

With IRSA, a Kubernetes service account is annotated with eks.amazonaws.com/role-arn and the pod gets a projected web identity token; the role trusts the cluster OIDC provider. With Pod Identity, the eks-pod-identity-agent add-on runs on nodes and you create an association between a service account and a role that trusts pods.eks.amazonaws.com.

3. Choose per cluster

Pod Identity avoids the per-cluster OIDC provider and trust policy edits, so roles are reusable across clusters, and supports session tags. IRSA works in more environments, and some platform types or older SDKs and tools are limited to it. We check current compatibility notes before choosing.

4. Create roles with tight trust

For IRSA the trust policy scopes the sub claim to system:serviceaccount:namespace:name and the aud to sts.amazonaws.com. For Pod Identity the trust allows pods.eks.amazonaws.com with sts:AssumeRole and sts:TagSession. We attach least-privilege policies, not AdministratorAccess.

5. Check SDK and add-on support

The AWS SDK in the container must be a version that supports the chosen credential provider. We confirm the pod has the injected environment variables and that no fallback to the node role hides a misconfiguration.

6. Debug AccessDenied

We exec into a pod and run aws sts get-caller-identity to see which identity it has. A node role result means the mapping did not apply, often because the pod was created before the annotation or association, or the service account name or namespace is mismatched.

7. Remove node role access

Once pods have their own roles, we reduce the node role to what the kubelet needs, and block pod access to the instance metadata service with a hop limit of 1 where applicable.

Mistakes we help you avoid

Common ways this goes wrong, and what we do instead.

Wildcard sub in the trust policy

Every service account in the cluster can then assume the role.

Forgetting to restart pods

Credentials are injected at pod creation, so existing pods keep the old identity.

Leaving broad permissions on the node role

Any pod that can reach the metadata service inherits them.

Mismatched service account or namespace

A single typo in the trust or association causes AccessDenied.

Frequently Asked Questions

What is the difference between IRSA and EKS Pod Identity?

Both give pods IAM credentials. IRSA uses the cluster OIDC provider and annotations, and Pod Identity uses an agent and an association managed by EKS, with simpler cross-cluster role reuse.

Does Pod Identity work on Fargate?

Check the current EKS documentation, as supported compute types differ between the two mechanisms. IRSA is the established option for Fargate.

Why do pods still use the node role?

The service account was not annotated or associated, the pod pre-dates the change, or the SDK is too old to use the new credential provider. get-caller-identity from inside the pod confirms it.

Want Help With EKS IRSA vs EKS Pod Identity: pick one and set it up correctly?

Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.

Schedule Appointment › No commitment required