Kubernetes on Amazon Elastic Kubernetes Service (EKS) must authenticate to AWS APIs for tasks such as pulling images from Amazon ECR, publishing metrics to CloudWatch, or reading from DynamoDB. In 2025, there are four primary patterns for granting that access, each with its trade-offs in security, operational effort, and developer experience:
- Embedding Access & Secret Keys in the Application
- Attaching an IAM Role to Worker Nodes
- IAM Roles for Service Accounts (IRSA)
- EKS Pod Identity (successor to IRSA for many use-cases)
Below is a deep dive into how each method works, when to use it, and the pros and cons you need to weigh when securing workloads on EKS.
1. Embedding Access & Secret Keys in the Application
Embedding access and secret keys in an application involves manually creating an AWS access key ID and secret access key for an IAM user, then injecting those credentials into the application’s environment through various methods, such as environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY), storing them in secrets managers or Kubernetes config maps, or hard-coding them directly into the application source code or CI/CD pipeline variables. This method enables the application to authenticate with AWS services using static credentials; however, it introduces significant security and operational risks if not managed carefully.
Pros
| Benefit | Why it matters |
|---|---|
| Simplicity & familiarity | Works exactly like any SDK tutorial; no cluster configuration required. |
| Works everywhere | Functions in any runtime (containers, VMs, local laptop) because it relies only on the standard AWS credential chain. |
Cons
| Drawback | Impact |
|---|---|
| Security risk of long-lived keys | Keys can leak in git, CI logs, or container layers. Rotating them is painful and usually neglected. |
| Key sprawl & auditing pain | Each app has its unmanaged credential pair; visibility is low, and revocation is manual. |
| No pod-level isolation | Anyone in possession of the key can act under that IAM user, inside or outside the cluster. |
Verdict: Acceptable for quick prototypes, but avoid in production. Modern AWS best practice is to eliminate long-lived keys entirely.
2. Attaching an IAM Role to Worker Nodes
Attaching an IAM role to worker nodes involves assigning an instance profile (IAM role) to each EC2 instance in an EKS-managed or self-managed node group. Any pod scheduled on that node automatically inherits the IAM permissions via the EC2 Instance Metadata Service (IMDS), allowing the application to access AWS resources without embedding credentials. In the case of Fargate, a similar approach is used by assigning a task role to the Fargate profile, enabling pods to assume the role and interact with AWS services securely and without hard-coded keys.
Pros
| Benefit | Why it matters |
|---|---|
| Keyless | Uses short-lived STS tokens delivered by IMDS; no hard-coded secrets. |
| Low operational overhead | No per-pod configuration; works automatically for every container on the node. |
| Good for single-tenant clusters | If every workload needs similar privileges (e.g., dev sandbox), this is fast to implement. |
Cons
| Drawback | Impact |
|---|---|
| Coarse granularity | Every pod on the node receives identical permissions, violating least privilege. |
| Lateral-movement risk | Compromise of one pod grants the attacker the full node IAM role. |
| Scaling friction | As clusters grow, you often need multiple roles per workload; managing node groups per role becomes complex. |
Verdict: Still common in small or homogeneous clusters, but large multi-tenant environments should move to pod-scoped identities.
3. IAM Roles for Service Accounts (IRSA)
With IAM Roles for Service Accounts (IRSA), EKS first exposes an OpenID Connect (OIDC) issuer URL unique to the cluster. You then create an IAM role with a trust policy that allows authentication from this OIDC provider and a specific Kubernetes service account. This service account is annotated with the IAM role’s ARN using the key eks.amazonaws.com/role-arn. At runtime, the AWS SDK within the pod uses the service account’s projected OIDC token (a JWT) to request temporary AWS credentials from the AWS Security Token Service (STS), enabling secure, pod-level access to AWS services without storing static credentials.
Pros
| Benefit | Why it matters |
|---|---|
| Fine-grained, pod-level IAM | Achieves true least-privilege without per-node role explosion. |
| No credential leakage | Short-lived STS tokens delivered automatically; nothing to store. |
| Auditable mapping | Clear 1-to-1 mapping between service accounts and IAM roles. |
| Works on EC2 and Fargate | Unified experience across compute types. |
Cons
| Drawback | Impact |
|---|---|
| Initial setup complexity | Requires OIDC issuer thumbprint management, IAM trust policies, and service-account annotations. |
| Token bloat in env vars | Large projected JWTs can increase pod size, minor but sometimes inconvenient. |
| Per-role limit | AWS IAM default soft limit of 5,000 roles per account; large SaaS providers may hit this. |
Verdict: The de-facto standard from 2019-2023. Still fully supported and reliable, but has been superseded for many scenarios by EKS Pod Identity.
4. EKS Pod Identity
EKS Pod Identity simplifies pod-level authentication by enabling you to map Kubernetes service accounts directly to IAM roles without relying on OIDC tokens. After enabling Pod Identity on your cluster—either via the console or API – you create a Pod Identity Association (PIA) that links a service account to an IAM role. During pod runtime, the EKS credential provider agent (sidecar) securely injects short-lived SigV4 credentials into the pod through a local endpoint, eliminating the need for projected JWT tokens. The AWS SDK automatically retrieves these credentials using the AWS_EKS_POD_IDENTITY_AUTH_DSN environment variable, allowing the pod to access AWS services securely and seamlessly.
Pros
| Benefit | Why it matters |
|---|---|
| Even simpler than IRSA | No OIDC providers, thumbprints, or JWT handling. Setup is a single API call + annotation. |
| Lower latency & lighter tokens | Credentials are streamed directly; no 6 KB JWT projections. |
| Higher IAM role limits | Reuses IAM roles but supports role sessions, reducing the total number of roles you must create. |
| Transparent to SDKs | Works with any modern AWS SDK (≥v2.25 for Java, ≥boto3-1.34 for Python, etc.) without code changes. |
| Future-proof | Actively developed by AWS; roadmap includes trust-policy templates, cross-account support, and richer observability. |
Cons
| Drawback | Impact |
|---|---|
| Only for EKS ≥1.28 | Older clusters must upgrade. |
| New operational surface | Requires the Pod Identity agent to stay healthy; adds another DaemonSet to monitor. |
| Limited third-party tooling awareness (early 2025) | Some Helm charts still assume IRSA annotations; minor re-templating may be needed. |
Verdict: Recommended default for new clusters in 2025. It preserves least-privilege and removes most of IRSA’s friction.
Quick Breakdown
| Feature | Access Keys in App | Node IAM Role | IRSA | EKS Pod Identity |
|---|---|---|---|---|
| Least-Privilege Scope | App (global) | Node | Pod | Pod |
| Secret Rotation | Manual | STS (automatic) | STS (automatic) | STS (automatic) |
| Setup Effort | Very low | Low | Medium | Low |
| Operational Overhead | High (key mgmt) | Medium (node roles) | Medium (OIDC) | Low |
| Risk of Credential Leakage | High | Medium | Low | Low |
| Multi-Account Support | Yes (but messy) | Yes (per nodegroup) | Yes | Not yet (roadmap) |
| Ideal For | Quick PoCs | Small single-tenant clusters | Mature multi-tenant clusters pre-2024 | All new EKS clusters, large-scale |
Best-Practice Recommendations for 2025
- Greenfield clusters: Enable EKS Pod Identity from day one and grant workloads the minimum IAM permissions required.
- Existing clusters on IRSA: Migrate gradually by dual-annotating service accounts; both systems can coexist during transition.
- Edge or air-gapped use-cases: If the OIDC issuer or Pod Identity agent cannot reach AWS STS, continue using node IAM roles, but tightly scope what runs on those nodes.
- Never commit long-lived access keys to code or container images. If you must test locally, use
aws sso loginor short-term tokens from AWS STS.
Conclusion
AWS offers a continuum of authentication strategies for EKS, evolving from rudimentary key injection to sophisticated pod-scoped identities. In 2025, EKS Pod Identity delivers the strongest balance of security, simplicity, and performance, while IRSA remains a solid, battle-tested option. Node IAM roles and static keys still have niche roles but carry increasing security debt as clusters scale. Evaluate your organization’s tenancy model, compliance needs, and upgrade cadence, then choose the least-privileged approach that lets your developers move fast without ever handling a secret key again.
