AI Governance: Between the Prompt and the Policy
October 2, 2026
aws-auth ConfigMap Deprecated – EKS Access Entries Are the Way Forward
BLOG
5 min.
If you’ve been running Amazon Web Services (AWS) Elastic Kubernetes Service (EKS) clusters for any length of time, you’ve probably had that moment. Staring at an aws-auth ConfigMap YAML file at 2 AM, trying to figure out why a new team member can’t access the cluster. Maybe you mistyped a Role Amazon Resource Name (ARN). Maybe someone applied a bad edit and locked out the entire ops team. I’ve been there. More than once.
The good news? AWS has officially deprecated the aws-auth ConfigMap for EKS authentication. Its replacement, EKS Access Entries via the Cluster Access Management (CAM) API, resolves long-standing operational headaches. But the aws-auth ConfigMap deprecation also marks something more significant: a shift in how authentication and authorization work at the cluster boundary, with real implications for how security teams govern access to Kubernetes workloads.
If you haven’t started migrating yet, now is the time. And if you’re treating this as a simple technical migration, you may be leaving the most valuable part on the table.
TL;DR: AWS deprecated the aws-auth ConfigMap in favor of EKS Access Entries, fixing long-standing security and auditability gaps. The real value is treating the migration as a chance to rethink how cluster access is governed.
Key Takeaways:
- EKS Access Entries eliminate the ConfigMap’s biggest risks: no CloudTrail visibility, single-resource fragility and disconnection from AWS-native IaC and managed policies.
- Copying existing ConfigMap mappings 1:1 into access entries preserves stale permissions and over-privileged roles, which is the most common migration mistake.
- Organizations that connect EKS access to their broader IAM strategy, define deliberate access tiers and plan for auditability get a durable security model, not just a format change.
The aws-auth ConfigMap: A Brief Eulogy
For years, the aws-auth ConfigMap was the way to map IAM principals to Kubernetes Role Based Access Control (RBAC) groups in EKS. It worked. But it came with some well known pain points.
It’s a single Kubernetes resource. One bad kubectl apply and you could lock yourself or everyone, out of the cluster. I once watched a team lose cluster access for two hours because of a YAML indentation error. Two hours. On a production cluster. Somebody brought donuts the next morning as an apology and honestly that made it worse because then we were all stress eating.
The security problem runs deeper than a mere inconvenience. When one misconfigured resource can sever access to an entire cluster (or worse, grant unintended access), the blast radius of a simple human error becomes difficult to contain.
No audit trail. Changes to the ConfigMap didn’t show up in AWS CloudTrail. You had to rely on Kubernetes audit logs, which many teams weren’t shipping or monitoring.
No AWS API integration. You couldn’t manage it with Terraform, CloudFormation or the AWS CLI in a first class way. It was always a workaround. A kubectl command bolted onto your IaC pipeline.
No access policies. You couldn’t associate AWS managed access policies with ConfigMap entries. Everything had to be wired through Kubernetes RBAC manually.
AWS has officially moved on with the aws-auth ConfigMap deprecation. The move forward stands to resolve significant security limitations and frustrations.
What Changes Now That the aws-auth ConfigMap is Deprecated?
EKS Access Entries move authentication management from a Kubernetes-native resource to the EKS API itself. That distinction matters more than it sounds. They fundamentally change how you grant IAM principals access to your clusters. Instead of editing a Kubernetes ConfigMap, you now manage access through the EKS API itself. An access entry associates a set of Kubernetes permissions directly with an IAM identity, a role or user, at the AWS control plane level.
Here’s what makes this better:
Full Cloud-Trail Visibility: Native auditability of access controls. Tracking, monitoring and reporting on access changes becomes a seamless part of the process.
Infrastructure-as-Code, Natively: Access entries are managed through the EKS API, which means full CloudTrail logging, Terraform and CloudFormation support and CLI management. Your IaC pipelines just got a lot cleaner.
AWS Managed Access Policies: You can attach predefined EKS access policies (like AmazonEKSClusterAdminPolicy, AmazonEKSEditPolicy or AmazonEKSViewPolicy) directly to an access entry. No more hand rolling ClusterRoleBindings for common use cases.
Blast Radius Containment:. You can’t accidentally lock yourself out by botching a YAML file. Access entries are individual resources. Adding or removing one doesn’t risk the others.
Kubernetes Group Mapping Still Available: If you need custom RBAC, you can still map access entries to Kubernetes groups. That flexibility still exists, it’s just no longer the only option.
How to Migrate to EKS Entries Without Increasing Risk
When you migrate, you’ll need to set your cluster’s authentication mode. EKS gives you two options.
- API_AND_CONFIG_MAP means both access entries and the aws-auth ConfigMap are active. This is your transition state. Use it while you migrate existing entries.
- API means only access entries are active. The ConfigMap is ignored entirely. This is your target state.
The practical path starts with enabling API_AND_CONFIG_MAP first, migrating all your entries, validating everything, then switching to API mode. Don’t try to do it all at once. And before you remove any aws-auth entries that were auto created for managed node groups or Fargate profiles, double check that equivalent access entries exist. EKS creates some of these automatically, but it’s worth verifying. There could exist certain conditions where the automatic creation didn’t pick up everything cleanly, so just look before you leap.
Rethink EKS Access Governance While the Door is Open
The deprecation of aws-auth ConfigMap creates an inflection point for teams to rethink how access to Amazon EKS is governed. For years, the ConfigMap provided a cluster-level mechanism for mapping IAM principals to Kubernetes identities and groups. With EKS access entries and Cluster Access Management, AWS now provides a more integrated way to manage those relationships through the EKS API.
But there’s an important distinction between migrating access and revisiting access.
It’s tempting to take the roles and groups already defined in aws-auth,recreate them as access entries and consider the migration complete. That preserves the existing model but it doesn’t necessarily answer some of the more important questions.
- Who actually needs access to this cluster?
- What level of access does each identity need?
- Does EKS access governance align with how identity is managed across the rest of the AWS environment?
- Are privileged permissions limited to the people and workloads that need them?
- What happens to that access when someone changes roles or leaves the organization?
Connect EKS to Your Broader IAM Strategy
One of the most common mistakes is treating EKS authentication as its own thing, completely disconnected from how the rest of the AWS environment is governed. Your clusters don’t exist in isolation. The people and workloads accessing them are the same ones accessing S3 buckets, RDS instances, Lambda functions and other AWS services.
If your organization uses AWS IAM Identity Center or federates identities through Entra ID, Okta or another IdP, your EKS access should flow through that same identity fabric.
The same idea applies to workloads. Human access and workload access are two different problems. IRSA and EKS Pod Identity exist specifically to give pods scoped access to AWS services without sharing credentials or roles meant for human users. Keeping those boundaries clean pays off when someone from compliance asks you to explain who has access, why they have it, what they can do and how that access is removed when it is no longer needed without a whiteboard, a collection of spreadsheets, and four caveats.
Define Access Tiers Before Creating Entries
This is a step that gets skipped too often. Before creating access entries, figure out what tiers of access make sense for your organization. Some teams need four tiers, some need two.
The point isn’t to follow a template. The point is to make a deliberate decision about who can do what, so that six months from now you’re not staring at a list of access entries with no idea why half of them exist.
EKS access policies make this easier because they give you predefined permission sets maintained by AWS. AmazonEKSClusterAdminPolicy, AmazonEKSViewPolicy and so on. You don’t have to hand roll ClusterRoleBindings for every common use case. That said, if your teams have needs that the managed policies don’t cover, you can still map access entries to Kubernetes groups and wire up custom RBAC. The flexibility is there. Just make sure you’re reaching for custom RBAC because you need it, not because it’s what you’ve always done.
Plan for the Audit Question Now
There is a question that eventually gets asked, usually by someone from security or compliance: “Who has access to what and why?“
The ability to answer that question cleanly comes down to strategy, not tooling. Now that the deprecated aws-auth ConfigMap has given way to access entries living in the AWS API with full CloudTrail coverage, the tooling side is significantly improved.
The strategy still requires deliberate steps:
- Tag your access entries and roles consistently.
- Document your access tiering model, even if it’s just a page in your internal wiki.
- Ensure IaC reflects reality: access entries in your Terraform state must match what is running in production.
- Establish ownership and business justification (including that entry created for a contractor six months ago).
- Build deprovisioning into the lifecycle
- Review access periodically
The old model made this kind of governance almost impossible at scale. The new model makes it achievable. Be certain that your migration isn’t recreating foundational problems in a new format.
Start the Migration Today
The deprecation of the aws-auth ConfigMap isn’t just a technical migration. It’s an opportunity. An opportunity to modernize your access management, align with IAM best practices and reduce the operational risk that comes with managing a single, fragile Kubernetes resource.
If you’re still on the ConfigMap, start planning your migration now. If you’re building new clusters, go straight to API mode and never look back.
Need help with your migration? Contact us and we’ll help you start where you are and define a deliberate IAM and access strategy that uses roles over users, scopes access by responsibility and leverages AWS managed policies wherever possible.
FAQs
Will AWS remove the aws-auth ConfigMap entirely?
AWS has deprecated the aws-auth ConfigMap but has not announced a removal date. Migration is still strongly recommended. Deprecation means no new features or fixes and future versions may drop support entirely.
What is the difference between IRSA and EKS Pod Identity?
IRSA (IAM Roles for Service Accounts) maps Kubernetes service accounts to IAM roles using OIDC. EKS Pod Identity simplifies this by removing the OIDC dependency and managing the association through the EKS API. Both scope workload access without sharing human credentials.
Can I use EKS Access Entries with Terraform?
Yes. EKS Access Entries are managed through the EKS API, which means native support for Terraform, CloudFormation and the AWS CLI. This is a major improvement over the aws-auth ConfigMap, which required kubectl workarounds in IaC pipelines.
How do I handle emergency access to an EKS cluster after migration?
Define a break-glass access entry with cluster admin permissions tied to a tightly scoped IAM role. Restrict that role behind MFA and log every assumption in CloudTrail. This ensures emergency access exists without weakening your day-to-day access model.
Keegan Justis is a seasoned professional renowned for his expertise in cloud native services and DevSecOps practices tailored for AI-focused SaaS startups. Keegan excels in designing resilient cloud infrastructures that support the demands of AI applications while maintaining rigorous security standards. Beyond technology, Keegan enjoys reading, staying active with workouts and cherishing time with his wife.
Search
Categories
Recent Posts
Cloud Security Assessments: Why, When and How Often?
October 1, 2026
Managing Agentic AI: Why the Control Plane Problem Is an AI Problem
September 29, 2026