Break-Glass Access for EKS: Your Emergency Lifeline
In the world of cloud-native applications, reliance on federated identity can introduce risks. What happens when that system fails? Break-glass access for Amazon EKS offers a critical solution. It provides an emergency path that operates independently of any external identity system, allowing operators to regain access quickly and securely during incidents.
This method hinges on AWS Identity and Access Management (IAM) and AWS Security Token Service (AWS STS). You set up a dedicated role in a separate operations account, complete with a cross-account trust policy that mandates Multi-Factor Authentication (MFA). When an emergency arises, operators call sts:AssumeRole directly, bypassing federation and external directories. Authorization is managed through the Amazon EKS Cluster Access Management (CAM) API, which means access entries and policies are handled via the AWS API instead of Kubernetes objects. Pre-provisioning is key here: the role, access entry, and policy association are created in advance, allowing operators to act swiftly during an incident with short-lived credentials that maintain a complete audit trail.
However, there are critical considerations. Ensure your cluster authentication mode is set to API or API_AND_CONFIG_MAP. You also need a separate operations account with registered MFA devices for the principals who will use break-glass permissions. A common pitfall is overlooking network reachability; remember that this pattern restores authentication and authorization, not connectivity. When implemented correctly, break-glass access can be a lifesaver in production environments, but it requires careful planning and execution.
Key takeaways
- →Establish a dedicated role in a separate operations account for emergency access.
- →Use AWS STS to issue temporary credentials with a complete audit trail.
- →Pre-provision roles and policies to ensure rapid access during incidents.
- →Mandate MFA for operators to enhance security during break-glass scenarios.
- →Ensure network reachability is addressed separately from authentication and authorization.
Why it matters
In production, downtime can be costly. Break-glass access ensures that you can regain control of your EKS clusters quickly, minimizing the impact of identity failures.
Code examples
1AWSTemplateFormatVersion: '2010-09-09'
2Description: 'Break-glass role for emergency Amazon EKS cluster access'
3
4Parameters:
5 OperationsAccountId:
6 Type: String
7 Description: 'Account ID permitted to assume this role'
8 AllowedPattern: '^\d{12}$'
9 ClusterArns:
10 Type: CommaDelimitedList
11 Description: 'ARNs of the clusters this role may reach'
12 MaxSessionSeconds:
13 Type: Number
14 Default: 3600
15 MinValue: 3600
16 MaxValue: 43200
17
18Resources:
19 EksBreakGlassRole:
20 Type: 'AWS::IAM::Role'
21 Properties:
22 RoleName: 'eks-break-glass'
23 Description: 'Emergency Amazon EKS access, independent of federated identity'
24 MaxSessionDuration: !Ref MaxSessionSeconds
25 AssumeRolePolicyDocument:
26 Version: '2012-10-17'
27 Statement:
28 - Effect: Allow
29 Principal:
30 AWS: !Sub 'arn:aws:iam::${OperationsAccountId}:root'
31 Action:
32 - 'sts:AssumeRole'
33 - 'sts:SetSourceIdentity'
34 Condition:
35 Bool:
36 'aws:MultiFactorAuthPresent': 'true'
37 NumericLessThan:
38 'aws:MultiFactorAuthAge': '3600'When NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsIndustry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.
Get CKA certified →Navigating NIS2 and DORA Ownership in Kubernetes Teams
Understanding who owns NIS2 and DORA regulations on your Kubernetes platform team is crucial for compliance and security. The traceability chain involves specific roles across risk, legal, and security teams, alongside your platform and application teams. Get ready to clarify responsibilities and streamline your compliance efforts.
Guardrails, Not Gates: Rethinking Policy in Kubernetes
In a world where developer experience clashes with security, adopting a guardrail approach can transform your platform team's policies. Instead of blocking progress, guardrails guide developers while ensuring compliance. Learn how to implement validation effectively with Kyverno's enforcement settings.
Security Slam 2026: Elevate Your Kubernetes Security Posture
Get ready for Security Slam 2026, a 30-day virtual event designed to boost your project's security hygiene. Leverage OpenSSF projects and engage with advisors in a dedicated CNCF Slack channel to tackle security challenges tailored to your maturity level.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.