Cloud-Plattformen · 26.08.2026, 16:32 UTC
Break-glass access for Amazon EKS when federated identity fails
| Schweregrad | info |
|---|---|
| Kategorie | Cloud-Plattformen |
| Quelle | AWS Containers ↗ |
| Veröffentlicht | 26.08.2026 UTC |
Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.
A federated identity provider outage locks you out of the clusters you need to reach to fix it. Implementing break-glass access for Amazon Elastic Kubernetes Service (Amazon EKS) clusters removes that circular dependency by creating an emergency path that depends on no external identity system. A leading worldwide provider of payment technology and software solutions, headquartered in the United States and referred to here as the customer, tested and verified this pattern across a fleet of more than 50 AWS accounts before moving its Amazon EKS estate between organizations in AWS Organizations. The migration completed without any cluster lockouts or production disruptions because the emergency path had been proven in every target account before the work began. AWS already documents a good deal of this territory, and it’s worth being precise about what’s covered. The Amazon EKS best practices guidance recommends removing standing cluster-admin permissions from the cluster creator identity, and notes that the permission can be added back for break-glass use cases. The access entries documentation lists misconfiguration recovery as a feature, meaning cluster access can be restored through the Amazon EKS API without reaching the Kubernetes API first. At the account level, AWS Identity and Access Management (IAM) documents an emergency user, while AWS IAM Identity Center documents a full emergency access procedure. What the guidance stops short of is a worked pattern for the Kubernetes authorization layer. The existing recommendation is to secure the cluster creator role and …