For most of Amazon EKS's history, every cluster shipped with the same quiet dependency: a single Kubernetes ConfigMap named aws-auth, hand edited by whoever last needed to grant someone access. AWS deprecated that model in favor of a newer, API driven alternative called access entries, and its own guidance has recommended the switch for some time. Adoption has not followed. According to the 2025 Kubernetes Security Report from Wiz, 81% of EKS clusters are still running on the older ConfigMap based method, against AWS's own recommendation.
That gap matters more than it looks like it should, because aws-auth was never just a quirky legacy setting. It was, and in most fleets still is, the single artifact standing between an IAM principal and full control of a Kubernetes cluster. A YAML file with no schema validation, no built-in versioning beyond whatever your GitOps tool provides, and no dedicated audit trail is not a comfortable place to keep the answer to "who can do what on production." Every week a team stays on the old model is a week that question gets harder to answer with confidence, particularly as more workloads inside those same clusters are agents and automation acting on IAM roles rather than humans typing kubectl commands.
The mechanics of the ConfigMap approach are simple enough to explain in a sentence, which is part of the problem. The AWS IAM Authenticator running on the EKS control plane reads a ConfigMap in kube-system, matches the calling IAM principal against the mapRoles or mapUsers entries in that file, and grants whatever Kubernetes username and group the entry specifies. Everything downstream, RBAC bindings, cluster-admin access, node bootstrap permissions, traces back to that one object.
In practice, that design produces a specific and recurring set of failures across fleets we have reviewed:
Access entries replace the ConfigMap with a first-class EKS API resource, and the model is worth understanding in some detail before you touch a production cluster. Every cluster has an authenticationMode, and it can be one of three values: CONFIG_MAP, the legacy behavior; API_AND_CONFIG_MAP, a transitional mode where both the ConfigMap and access entries are honored; and API, where the ConfigMap is ignored entirely and access entries are the only source of truth. Moving between these modes is a one-way trip. You can go from CONFIG_MAP to API_AND_CONFIG_MAP to API, but AWS does not let you step back down once you have moved forward, which is the single most important fact to internalize before you start.
An access entry itself binds an IAM principal, typically a role, to an entry type and one or more access policies. The entry type tells EKS what kind of principal this is: STANDARD for a normal human or automation role, EC2_LINUX, EC2_WINDOWS, FARGATE_LINUX, and HYBRID_LINUX for node identities that need to bootstrap into the cluster. Access policies are the part that actually feels like an upgrade over the ConfigMap: AmazonEKSClusterAdminPolicy, AmazonEKSAdminPolicy, AmazonEKSEditPolicy, and AmazonEKSViewPolicy give you AWS-managed, EKS-specific permission tiers, and each one can be associated with an access scope that is either the whole cluster or a specific set of namespaces. That namespace-level scoping is genuinely new territory. Getting the equivalent behavior out of the ConfigMap meant hand-authoring RBAC RoleBindings per namespace and hoping nobody removed the matching ConfigMap entry without also cleaning up the binding.
The part that will actually change your day to day operations is that access entries are managed entirely through the EKS API, which means eks:CreateAccessEntry, eks:AssociateAccessPolicy, and every other mutation shows up in CloudTrail with an actor, a timestamp, and a request ID. It also means Terraform, CloudFormation, and the AWS CLI can manage cluster access the same way they manage every other piece of infrastructure, instead of being the one part of your EKS setup that lives outside your normal change process.
The risk in this migration is not that access entries are hard to configure. It is that the mode switch is irreversible and a rushed cutover can leave you or your automation without a valid path back into a cluster. A sequence that has held up well across the migrations we have run looks like this.
It is tempting to file this under routine platform hygiene, the kind of migration that gets a ticket, a sprint, and a shrug. The context that makes it more urgent is what is increasingly running inside these clusters. Kubernetes 1.34 shipped Dynamic Resource Allocation as a stable feature specifically to make EKS and other clusters better hosts for GPU-bound AI workloads, and organizations are deploying agents and automation directly into cluster namespaces at a pace that outstrips how carefully most teams are scoping the IAM roles those workloads run under. A ConfigMap that grants broad, hard to audit access was already a liability when every principal in it was a human with a badge and a manager. It is a much bigger one when a growing share of those principals are non-human identities acting continuously and at machine speed, which is exactly the pattern our AI agent identity work keeps surfacing across client environments.
Access entries do not solve that problem by themselves, but they give you the primitive you need to solve it: an auditable, API-managed, namespace-scoped grant that can be reasoned about in the same change management process as everything else in your infrastructure. Treat the migration as the foundation for a real access review, not a lift-and-shift of whatever the ConfigMap already said.
Start the audit this quarter even if you do not plan to flip authentication modes right away. Reading your current aws-auth ConfigMap with fresh eyes, and asking who actually still needs each grant, is valuable independent of the migration itself. When you do migrate, respect the one-way nature of the mode switch: move to API_AND_CONFIG_MAP first, validate with a canary principal, mirror node identities explicitly, and only flip to API-only once every principal has been proven to work under the new model. Do not let the fact that 81% of clusters have not moved yet read as reassurance. It reads as backlog, and backlog on an authentication system is the kind of technical debt that turns into an incident report. If your platform team is weighing this migration alongside a broader cloud security review, our IT consultancy practice helps engineering leaders sequence exactly this kind of infrastructure change without introducing new risk in the process.
Before we start, please share a few details so we can follow up with you.
End this conversation? Your chat will be emailed to us.