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 reuse it during an incident.
That role sits in the same account as the cluster and carries no enforced multi-factor authentication (MFA). It’s also the identity most likely to have been broken by the restructuring itself: the cluster creator is typically a federated engineer role or a provisioning-pipeline role, and an organization migration can delete that role, recreate it under a different name or path, or invalidate the trust policy it depends on. The access entry recorded at cluster creation then points at a principal that no longer exists or that nobody can assume. This post covers the remaining distance.