81% of EKS clusters still run the auth method AWS already told teams to leave

Amazon EKS has deprecated the aws-auth ConfigMap, the hand-edited object that maps IAM identities to in-cluster permissions, in favor of a newer API-driven mechanism ^[1]. A 2025 Kubernetes Security Report cited by The New Stack found that 81% of EKS clusters still run the older method, contrary to AWS's own security guidance ^[3].

That leaves roughly one in five clusters moved ^[14]. For anyone running a fleet, the arithmetic is worse than it sounds: the deprecated path is not something you inherited from one neglected team, it is the default state of the estate.

The New Stack characterizes the ConfigMap as manually edited and hard to audit ^[2]. Note what is not being alleged. Nobody says it stops working; the objection is to the control surface, not the function. A cluster whose access list is a YAML object edited by hand is a cluster where "who can reach the API server, and who granted them that" is answered by reading a file and trusting whoever read it.

Where that object sits is what makes it more than a lint warning. The four Cs model splits the cloud-native attack surface into Code, Container, Cluster and Cloud, layers that are distinct but tightly coupled, so a weakness in one cascades into the others ^[5]. The New Stack's own illustration is that a misconfigured cloud IAM role can hand an attacker access to the Kubernetes API ^[6]. The aws-auth ConfigMap is precisely the joint where a Cloud-layer identity becomes a Cluster-layer privilege. The same article argues Code and Cloud are reasonably well practiced, because teams carried those disciplines over from existing workflows, while the real gaps sit at the Container and Cluster layers ^[8]. An artifact on the seam tends to be governed by whichever side has the weaker habit.

The habits are the underlying issue. VM-era practice assumed a known IP per host, one application per VM and a simple network, and that predictability made policy straightforward to write and enforce ^[11]. Kubernetes offers none of it: pods start and stop, workloads move between nodes, and clusters scale up and down with demand ^[12]. A manually maintained identity map is a static artifact carried into a system that does not hold still.

Downstream, The New Stack reports that roughly two-thirds of organizations have delayed or slowed deployments because of Kubernetes-related security concerns ^[4]. The article places that figure alongside the 81% but does not claim the ConfigMap causes the delays ^[15]. Read it as a description of the tax, not a causal chain.

Two things to watch. First, provenance: the 81% is attributed only to "a 2025 Kubernetes Security Report", with no publisher, sample size or method given in the piece ^[13], so it is a directional read on fleet composition rather than a measured baseline. Second, the forcing function, or lack of one. The article names no removal date for the ConfigMap and does not name the API-driven replacement ^[16]. Deprecated-but-still-working is a state platform teams can occupy for years, and on these numbers most of them are. Whether the migration happens before or after something external demands a full list of who holds cluster admin is, at this point, a scheduling decision.