EKS clusters lag on an AWS auth deprecation, per The New Stack

The New Stack reports that 81% of Amazon EKS clusters still run an AWS EKS authentication method that the vendor has already deprecated, published as part of a wider look at Kubernetes fleet security management. For platform teams whose deploy pipelines target EKS, that share is a migration flag more than a headline. The auth path baked into your kubeconfigs, CI service accounts and IaC modules is on borrowed time, and the reported fleet share says most peers have not started moving yet.

The piece frames the gap as a fleet-scale problem. Clusters age in place, and the deploy pipelines wired against them inherit whichever auth style was current the day the cluster was first stood up. Over enough years, the installed base drifts behind the vendor's own guidance, and any large fleet ends up with a long tail of pipelines still speaking the older protocol. Per The New Stack, that tail is now the majority of clusters.

The report, as it stands, does not pin AWS to a specific removal date, and this write-up is not going to guess one. Read the 81% as a snapshot: it is the size of the migration you or your platform peers still owe, not a deadline.

Where this bites CI/CD

Two failure modes tend to show up on the day a cluster-auth deprecation flips from warned to removed.

Cluster access from pipelines is the loud one. Every job that authenticates to EKS through the deprecated flow, whether that is an aws eks update-kubeconfig call, a helm or kubectl step, or a Terraform provider pinned against the old auth surface, starts returning Unauthorized. The recovery is a re-plumb of the cluster's own auth model, which is slower and more coordinated than rolling back a normal deploy.

Automation identities are the quiet one. Non-human principals like CI runners, in-cluster controllers and GitOps agents are usually the last things anyone re-authenticates, because nobody notices they broke until a deploy fails. On a real platform team's fleet, the audit and swap-out of every service principal is where the actual work sits.

The reported 81% is a share, not an inventory. It says how many clusters across the sample the piece cites are still on the deprecated path. It does not say which of your clusters are, or which of your pipelines authenticate through them. If you have not run that inventory yet, the number is a signal that the industry has not either. Do it before the removal date lands, not after.