AWS deprecated this EKS auth method. 81% of clusters still run it.

Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.

Originaltext der Quelle (nicht übersetzt) – die deutsche Zusammenfassung findest du im Tab „Kurzfassung".

The migration to Kubernetes and cloud native infrastructure has been one of the defining IT trends of the past decade. Adopting Kubernetes gives platform teams an immediate leap forward in agility and capability, but it also creates a dangerous security illusion. The declarative approach to infrastructure, sophistication, and dynamic flexibility make it seem like Kubernetes should also have built-in security, so that everything deployed will be magically secure. 

Kubernetes is not a magic solution. It is more operationally complex than a VM environment, introducing a multifaceted environment with multiple layers that each require attention and additional work to secure properly, not less. Cloud-native security therefore requires a robust infrastructure that spans every container and every node, and underestimating the complexity is costing enterprises in real time.

The approach to access control precisely captures how this illusion creates risk. Amazon EKS has deprecated the legacy aws-auth ConfigMap for mapping IAM identities to cluster permissions, a manually edited and hard-to-audit method, in favor of a newer, API-driven alternative. 

“According to a 2025 Kubernetes Security Report, 81% of EKS clusters are still running on the older method, contrary to AWS’s own security guidance.”

According to a 2025 Kubernetes Security Report, 81% of EKS clusters are still running on the older method, contrary to AWS’s own security guidance. The consequences of such oversights show up downstream, and roughly two-thirds of organizations have delayed or slowed deployments due to …

Vollständiger Originalartikel ↗

• Betroffenheit im eigenen Stack prüfen: Versionen/Komponenten abgleichen.
• Originalquelle / Hersteller-Advisory lesen: https://thenewstack.io/kubernetes-fleet-security-management/
• Verfügbaren Patch oder Workaround einspielen und dokumentieren.