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 Data Sovereignty in Cloud Native Kubernetes Deployments
Data sovereignty is a critical concern for organizations operating in a global landscape. With the US CLOUD Act compelling data access, understanding data residency and sovereignty is essential for Kubernetes deployments.
Mastering EKS Certificate Authority Rotation: Keep Your Cluster Secure
Certificate authority (CA) rotation is crucial for maintaining the security of your Amazon EKS cluster. This process ensures that your cluster transitions smoothly to a new CA while maintaining connectivity. Learn how to manage this lifecycle effectively to avoid disruptions.
Securing ECS Workloads: Mastering VPC Encryption and Service Connect TLS
In a world where data breaches are rampant, encrypting traffic between your Amazon ECS workloads is non-negotiable. Leverage VPC encryption controls and Service Connect TLS to enforce application-layer encryption and maintain a robust security posture.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.