AWS Retired This EKS Auth Method — and 81% of Clusters Haven't Noticed
Cloud Platform EngineeringAWS deprecated the aws-auth ConfigMap authentication method for Elastic Kubernetes Service — but according to The New Stack’s fleet security analysis, 81% of EKS clusters are still running the legacy method. For platform teams managing production Kubernetes, that’s a migration backlog that compounds risk with every month it sits.
What Happened
The aws-auth ConfigMap was EKS’s original mechanism for mapping IAM roles and users to Kubernetes RBAC permissions. AWS built an API-based authentication replacement — now the default for new clusters — that provides better auditability, more granular access controls, and a cleaner separation between AWS IAM and Kubernetes RBAC management.
AWS deprecated the ConfigMap method and encouraged migration to the new EKS API access mode, but deprecation announcements in Kubernetes infrastructure land quietly. Unlike breaking changes that force migration at upgrade time, this one is opt-in — which explains the 81% figure.
Why It Matters
The ConfigMap approach carries structural security problems that the API-based replacement was designed to solve. Manual ConfigMap edits are error-prone: a misconfigured entry can silently lock out users or, conversely, grant unintended cluster-admin access. There’s no audit trail when ConfigMap entries change — you know what the current state is, but not who changed it or when.
The API-based authentication surfaces every IAM-to-RBAC mapping through AWS CloudTrail, providing the audit trail that compliance regimes increasingly require. Access changes go through IAM policies, which can be versioned, reviewed in code, and attached to standard change management workflows.
The 81% adoption gap also represents a maintenance liability: as AWS invests in access management tooling for the API method, ConfigMap-based clusters will fall further behind the tooling ecosystem. EKS version rollback capabilities and newer cluster management patterns are optimized for the API access model.
What This Means for Platform Teams
The migration path is available via eksctl and the AWS console. For clusters with complex RBAC configurations, the main work is auditing existing ConfigMap entries and translating them into the equivalent access entries. AWS documentation covers the specific API calls; the practical challenge is mapping legacy ConfigMap structures that have accumulated over months or years of informal edits.
Teams running EKS through infrastructure-as-code (Terraform, CDK) should prioritize updating their cluster definitions to specify API access mode explicitly, rather than relying on the deprecated default. Any new cluster created today should be on API access mode from day one.
The timeline for forced migration hasn’t been announced, but AWS’s pattern with deprecated Kubernetes features is typically a 12–18 month window before removal. Given how long the 81% figure has persisted, waiting for forced migration means absorbing a rushed change under time pressure.
The So What
If you’re in the 81%, the ConfigMap-to-API-access migration belongs in your next sprint, not your next quarter. The security posture improvement is real — audit trails, cleaner IAM separation, and compatibility with modern tooling all matter. The migration effort is bounded and well-documented. The case for delay is weak; the case for a planned, non-urgent migration is strong.
Source: The New Stack
Content created with AI assistance and reviewed for accuracy.
Join the conversation
Stack Insiders is our free community for readers who want to go deeper — share resources, ask questions, and connect with others across every vertical we cover.
Join Stack Insiders →