EKS Pod Identity vs IRSA: Choosing the Right AWS IAM Pattern

A workload running in Amazon EKS may need access to S3, DynamoDB, Secrets Manager, or another AWS service. The difficult part is not calling the API. It is giving the right application the right permission without turning every deployment into a credential-distribution exercise.

EKS Pod Identity connects a Kubernetes service account to an AWS IAM role, allowing a supported SDK or the AWS CLI to obtain temporary credentials through its default credential chain. Instead of embedding access keys in a container, a Secret, or a CI variable, teams can define which workload needs which AWS actions.

This is a practical pattern for EKS workloads. It is not a claim that every Kubernetes runtime or every existing IAM design should change.

Why Kubernetes Security Breaks Down with Static AWS Credentials

Static AWS credentials are easy to introduce and hard to govern. A key can be copied into a Kubernetes Secret, Helm values file, CI system, local configuration, or backup. Each new location increases the set of systems and people that can expose it, and each rotation can become an application-release coordination task.

Kubernetes security improves when access is based on a workload identity and least-privilege permissions, rather than a long-lived key placed beside the workload. A node IAM role is not always the right answer either. When multiple applications share a node, a broad node role can grant more AWS access than one application needs.

The operating question should be specific:

“which service account in which namespace needs which AWS action on which resource?”

That question creates a reviewable boundary between the Kubernetes workload and the AWS permissions it receives.

EKS Pod Identity, AWS IAM, and Kubernetes Workload Identity

EKS Pod Identity associates an AWS IAM role with a Kubernetes service account in a particular EKS cluster and namespace. When a pod uses that service account, Amazon EKS sets the environment information that lets supported AWS SDKs and the AWS CLI use the Pod Identity credential path. See the Amazon EKS Pod Identity documentation for current setup and runtime requirements.

AWS IAM policies should describe the smallest useful set of actions and resources for the workload, while the service account identifies the workload that may use that policy. For example, a reporting job that reads a defined S3 prefix should not automatically receive broad S3 administration permissions.

The pattern has four core parts:

1. Create an AWS IAM policy for the workload's actual AWS API needs.
2. Create an AWS IAM role that trusts the pods.eks.amazonaws.com service principal.
3. Install the EKS Pod Identity Agent on eligible EKS worker nodes and create the role-to-service-account association.
4. Configure the deployment to use the intended Kubernetes service account and allow the SDK to use the default credential chain.

The team or automation creating the association needs iam:PassRole for the role it assigns. That is a useful control point because it separates defining IAM permissions from granting a service account the ability to use a role.

EKS Pod Identity Credential Path

This diagram shows the Kubernetes and AWS objects involved when a workload requests temporary AWS credentials.

Move From Static AWS Credentials to an AWS IAM Role

A safe migration begins with an inventory, not a Secret deletion. Identify the credential source the application uses today. It may be an AWS_ACCESS_KEY_ID environment variable, a mounted Secret, an external-secrets integration, the node role, or an IRSA configuration. The current source determines what needs to be removed and how you will validate the replacement.

Move one bounded workload at a time from static AWS credentials to a purpose-specific AWS IAM role. Start in a non-production environment. Define the IAM policy, create the role, install or verify the agent, and associate the role with the exact namespace and Kubernetes service account.

Create the association before deleting the old key source. AWS documents that credentials earlier in the default provider chain can continue to be selected after Pod Identity is configured. That enables a staged rollout, but it also creates an important verification requirement. A healthy pod does not prove that it is using Pod Identity. Review the EKS runtime documentation before planning the cutover.

After the association is in place, remove the legacy credential source in a controlled environment. Restart the workload when that is part of the deployment model, perform a representative allowed AWS operation, and confirm the identity in CloudTrail or the relevant application logs. Test an action outside the intended policy as well. An explicit denial is evidence that the policy boundary is working.

IRSA EKS vs EKS Pod Identity

IRSA EKS and EKS Pod Identity both let Kubernetes workloads use IAM permissions without placing AWS access keys in the application configuration. They do not use the same credential flow.

IRSA uses a projected web identity token and the AWS STS AssumeRoleWithWebIdentity operation. EKS Pod Identity uses an EKS-managed association and a Pod Identity Agent running on each eligible node. The agent retrieves temporary credentials through the EKS Auth API and makes them available to the workload's SDK.

The right choice is not “new versus old.” It is the identity mechanism that fits the workload runtime, platform constraints, and existing operating model. Existing IRSA workloads do not need to be rewritten merely because Pod Identity exists. Read the IRSA technical overview when a workload already depends on the OIDC-based pattern.

For a new workload on supported Linux EC2 worker nodes, Pod Identity can simplify the association and role-trust configuration. For a workload that runs on a platform Pod Identity does not support, or that has an established IRSA dependency, IRSA may remain the better fit.

Cloud IAM and Kubernetes Security Boundaries to Check

Cloud IAM is only as clear as the surrounding runtime controls. AWS documents that Pod Identity is supported for pods on Linux Amazon EC2 worker nodes in Amazon EKS. It is not available for Fargate, Windows nodes, AWS Outposts, EKS Anywhere, or self-managed Kubernetes clusters running on EC2.

Kubernetes security is not guaranteed by an IAM role association alone. AWS notes that containers are not a security boundary. If IMDS access is not restricted, a pod can also reach the node IAM role credentials. Review node-role permissions, IMDS restrictions, network and proxy configuration, and the role's trust policy as part of the same design.

There are operational limits too. A service account can have one directly associated IAM role, and Pod Identity associations are eventually consistent. Create or change an association in deployment or initialization workflows, not in a high-availability request path.

Kubernetes-to-AWS Authorization Boundaries

This diagram separates the workload identity, EKS association, IAM role and policy, and AWS resource access boundary.

Verify the AWS Identity Path, Not Only the Deployment

A successful rollout proves that the Kubernetes objects were accepted and the pods started. It does not prove that the workload made AWS calls with the intended AWS identity.

Use a release checklist that verifies the identity path:

• The deployment uses the intended Kubernetes service account.
• The EKS Pod Identity association references the expected cluster, namespace, service account, and AWS IAM role.
• The Pod Identity Agent is healthy on the node that runs the workload.
• The old static AWS credential source has been removed in the controlled test environment.
• An allowed AWS API call succeeds with the expected principal.
• An action outside the AWS IAM policy is denied.

This turns workload identity into an observable operating control instead of a manifest setting that is assumed to work.

Build AWS Identity into the Workload Design

Replacing access keys is an opportunity to make access ownership explicit. Kubernetes service accounts identify the workload. AWS IAM roles and policies describe the cloud permissions. Runtime verification shows which principal made the call.

Start with one bounded workload, verify the AWS identity path after the old key source is removed, and extend the pattern where the EKS runtime supports it.

For broader platform planning, see Das Meta's Cloud Infrastructure Management and Cloud Architecture Consulting.

Technical sources: Amazon EKS Pod Identity documentation; EKS runtime documentation; EKS IAM best-practice guidance; IRSA technical overview.

Key Takeaways

• Up to 5,000 EKS Pod Identity associations are supported per cluster. Treat that as a capacity limit to track, not a target to reach.
• One directly associated IAM role can be mapped to each Kubernetes service account. Create purpose-specific service accounts when permission boundaries differ.
• EKS Pod Identity automatically adds six session tags by default, including cluster, namespace, and service-account context. Those tags can support attribute-based access-control designs.
• Pod Identity association changes are eventually consistent and can take several seconds to become effective. Keep association changes outside high-availability request paths.
• A Kubernetes service account is namespaced. Review the cluster, namespace, and service-account context together when defining trust and access policies.