Break-Glass Access for Amazon EKS When Federated Identity Fails

Production Amazon EKS clusters typically authenticate users via federated identity providers, but outages or misconfigurations can lock administrators out. This creates a circular dependency where cluster access is needed to fix the identity provider, but the provider is required for access.

While AWS provides guidance on emergency users and EKS misconfiguration recovery, a worked pattern for the Kubernetes authorization layer was missing. Existing recommendations often rely on the cluster creator role, which may lack MFA or become invalid during organizational changes.

The presented pattern ensures the emergency path shares no dependencies with the primary path, using AWS IAM and STS for authentication. It employs a dedicated cross-account role with MFA and manages authorization via the Amazon EKS Cluster Access Management (CAM) API, moving control out of the cluster.

The pattern involves pre-provisioning the emergency role, access entry, and policy association, leaving them dormant until needed. The authentication chain, from AWS IAM to AWS STS to the EKS authentication webhook, is independent of any external identity provider, ensuring resilience during outages.

Before deployment, the EKS cluster authentication mode must be 'API' or 'API_AND_CONFIG_MAP', and a separate operations AWS account with MFA-registered IAM principals must exist. Crucially, network reachability to the EKS API endpoint must also be separately ensured, as this pattern only restores authentication and authorization.