Cloud Security
Most EKS Clusters Lag Behind AWS's Recommended Security Update Despite Deprecation
Eight in ten Amazon EKS clusters continue using an outdated authentication method that AWS has deprecated, revealing a persistent gap between cloud-native security guidance and actual practice.
The New Stack
The migration toward Kubernetes infrastructure has reshaped how enterprises manage cloud-native environments over the past decade. Yet this shift masks a critical security challenge: many teams operate under the false assumption that Kubernetes provides built-in protection alongside its operational flexibility. In reality, the technology demands multi-layered vigilance across distinct security dimensions that far exceed traditional VM environments.
This security gap appears acutely in access control practices. AWS has moved away from the legacy aws-auth ConfigMap—a manually edited approach vulnerable to audit gaps—toward an API-driven authentication alternative. However, according to the 2025 Kubernetes Security Report, a striking 81% of EKS clusters continue using the deprecated method, directly contradicting AWS's own guidance.
The consequences ripple downstream. Roughly two-thirds of enterprises report slowing or delaying Kubernetes deployments because of security concerns, pointing to a widening gap between cloud-native security theory and operational reality.
Why Traditional Security Approaches Fall Short#
The Kubernetes security community established a foundational framework for cloud-native threats known as the "four Cs": Code, Container, Cluster, and Cloud. Each layer presents distinct risks, and vulnerabilities at any level can cascade across the others—a misconfigured IAM role, for instance, can unlock unauthorized access to the Kubernetes API itself.
The structural differences between Kubernetes and legacy infrastructure make VM-era security practices inadequate. Virtual machines operate predictably: each has a static IP, runs a single application, and uses straightforward networking. By contrast, Kubernetes environments are inherently dynamic. Pods continuously launch and terminate, workloads migrate across nodes, and cluster capacity fluctuates with demand. This dynamism is precisely what makes Kubernetes powerful—and why security policies designed for static systems fail to keep pace.
Teams typically grasp Code and Cloud security reasonably well, having inherited disciplined practices from traditional development. The critical gaps emerge at the Container and Cluster layers, which operate under fundamentally different rules.
Container layer challenges: Images serve as the deployment unit in Kubernetes, bundling dependencies and configurations that require repeated verification against drift and misconfigurations across the entire supply chain.
Cluster layer challenges: Kubernetes's flexibility creates a large configuration surface prone to oversights. More critically, the networking model diverges sharply from traditional architectures. While legacy systems focus on North-South traffic (inbound and outbound), Kubernetes demands equal attention to East-West traffic flowing between applications within the cluster. Without explicit network policies, any pod can communicate with any other pod—meaning a single compromise spreads immediately across the entire workload.

