All posts
Kubernetes

EKS Access in 2026: Access Entries, Pod Identity, and Retiring the aws-auth ConfigMap

By

November 2, 2026

6 min read

Access entries replace the aws-auth ConfigMap for people, and Pod Identity replaces IRSA's OIDC plumbing for pods. What each does, what migrates automatically (only the cluster creator), the limits (5,000 Pod Identity associations, no Fargate or Windows), and a migration order that doesn't lock anyone out.

EKS
EKS Access Entries
Pod Identity
IAM
Security

People: access entries instead of aws-auth

An access entry associates an IAM principal with Kubernetes permissions, through EKS's own API rather than a ConfigMap inside the cluster. AWS calls access entries the best way to grant users access to the Kubernetes API. Permissions come from AWS-managed access policies or from Kubernetes groups you bind with RBAC.

  • Managed in the EKS API, so CloudFormation, Terraform and CDK define access at cluster creation.

  • Recoverable: a broken grant can be fixed through the EKS API without access to the Kubernetes API, which a mistyped aws-auth entry never allowed.

  • Audited in CloudTrail, with IAM features such as MFA behind them.

Want a second opinion on this for your system?

Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.

Pods: Pod Identity instead of IRSA

Pod Identity

IRSA

Setup

An association in EKS; trust principal pods.eks.amazonaws.com

An OIDC provider per cluster in IAM; a trust policy per cluster

Reuse across clusters

Same role, no trust-policy change

Trust policy edited for each cluster

Who does what

EKS team creates associations; IAM team owns roles

Both teams touch IAM

Where it works

Linux EC2 nodes on EKS

Also Fargate

Limits

5,000 associations per cluster; one role per service account

IAM OIDC provider limits

A migration order that doesn't lock anyone out

  1. Switch the authentication mode to API_AND_CONFIG_MAP, so both work.

  2. Create an access entry for every role in aws-auth, with the narrowest access policy that fits.

  3. Test each role with kubectl auth can-i; then remove its aws-auth line.

  4. When aws-auth is empty, switch to API only.

  5. For pods, install the Pod Identity Agent (Auto Mode includes it), create associations, and move one service at a time from IRSA annotations to Pod Identity; keep IRSA for Fargate pods.

  6. Restrict IMDS on nodes, so pods can't fall back to the node's role.

hoolco Monthly Review

Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.

As of November 2, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.