Why Kubernetes Is the Next Frontier for Cloud Red Teams
Kubernetes has become a primary pivot point in cloud breaches: an attacker with code execution in a single pod can escalate to cluster-admin privileges and cloud account access within minutes due to pod identity integrations with EKS IAM roles, AKS Workload Identity, and GKE Workload Identity.
Every major cloud provider now offers a managed Kubernetes service: EKS on AWS, AKS on Azure, and GKE on Google Cloud. Organizations are migrating production workloads into these clusters at pace, and the attack surface is expanding faster than most security teams can map it. Yet most cloud pentesting engagements still treat Kubernetes as an afterthought, focusing on IAM misconfigurations and storage exposure while ignoring the container orchestration layer entirely.
This is a mistake. In real-world intrusions, Kubernetes has become a primary pivot point. An attacker who gains code execution inside a single pod can often escalate to cluster-admin privileges, exfiltrate secrets from every namespace, and pivot into the underlying cloud account, all within minutes.
The Attack Chain: From Pod to Cloud Account
Kubernetes attacks follow a predictable three-phase escalation: initial pod compromise, container escape to node-level access, then federation into cloud IAM through pod identity mechanisms, with each phase exploiting the intersection of Kubernetes RBAC and cloud service account bindings.
The typical Kubernetes exploitation chain in a cloud environment follows a predictable pattern that defenders need to understand intimately. It starts with initial access, usually through a vulnerable application running inside a pod, an exposed Kubernetes dashboard, or a misconfigured kubelet API. From there, the attacker moves through distinct phases that exploit the intersection of Kubernetes RBAC and cloud IAM.
Container escape is where things get interesting from a red team perspective. Privileged containers, hostPath mounts, and capabilities like SYS_PTRACE or SYS_ADMIN create escape vectors that are surprisingly common in production clusters. Once on the node, the attacker has access to the kubelet credentials, the instance metadata service, and potentially every secret mounted by pods on that node.
EKS-Specific Attack Paths
IRSA (IAM Roles for Service Accounts) misconfigurations are the highest-impact finding in EKS assessments: overprivileged service account annotations allow pods to assume IAM roles far beyond workload requirements, directly chaining Kubernetes compromise into S3, Secrets Manager, and EC2 API access.
Amazon EKS introduces unique attack vectors through its integration with AWS IAM. The aws-auth ConfigMap maps IAM roles to Kubernetes RBAC groups, and misconfigurations here are rampant. IRSA (IAM Roles for Service Accounts) was designed to limit blast radius, but in practice, overprivileged service account annotations allow pods to assume IAM roles far beyond what their workload requires.
The EKS Pod Identity Agent, introduced more recently, doesn't eliminate these risks. It shifts them. Attackers who can modify pod specifications or service account annotations can chain Kubernetes access into full AWS account compromise. We've observed this exact pattern in breach simulations where a single misconfigured service account annotation led to S3 bucket access across the entire organization.
AKS and the Entra ID Integration
Workload Identity Federation in AKS mirrors IRSA design but inherits Azure's cross-tenant trust model: attackers who modify service account annotations can federate into Azure resources protected by Conditional Access policies, making it the highest-impact finding in our Azure bootcamp exercises.
Azure Kubernetes Service's integration with Entra ID creates attack paths that blend traditional Active Directory tradecraft with Kubernetes exploitation. AKS clusters using Azure AD authentication for RBAC are susceptible to token replay attacks if cluster role bindings are overly permissive. The managed identity assigned to the AKS cluster itself often has permissions to the broader Azure subscription that go unaudited.
Workload Identity Federation in AKS mirrors IRSA's design but inherits Azure's trust model. An attacker who can create or modify a Kubernetes ServiceAccount with the correct annotations can federate into any Azure resource the workload identity trusts. This cross-boundary movement from Kubernetes to Azure control plane is consistently the highest-impact finding in our Azure cloud bootcamp exercises.
GKE and Workload Identity
GKE Workload Identity's security depends entirely on Kubernetes RBAC isolation: if an attacker creates pods in a namespace with a privileged Workload Identity binding, they inherit GCP service account permissions without touching node-level credentials, making namespace isolation the critical control point.
Google Kubernetes Engine's Workload Identity binds Kubernetes service accounts to Google Cloud service accounts. The security improvement over node-level service accounts is significant, but the implementation creates its own risks. Namespace-level trust boundaries depend entirely on correct Kubernetes RBAC. If an attacker can create pods in a namespace with a privileged Workload Identity binding, they inherit those GCP permissions.
GKE Autopilot clusters restrict some escape vectors by enforcing security constraints, but they also limit the security team's ability to deploy detection tooling. This tradeoff between operational security and visibility is something practitioners need to evaluate case by case.
Detection Engineering for Kubernetes Attacks
Container escape and cloud credential theft appear across two separate audit streams: Kubernetes audit logs capture exec calls and API anomalies, while CloudTrail records the resulting cloud API calls, requiring correlation rules that link both sources to detect the full attack chain.
Detecting Kubernetes attacks in cloud environments requires correlation across two distinct telemetry sources: Kubernetes audit logs and cloud provider audit trails. A container escape won't appear in CloudTrail. It shows up in the Kubernetes audit log as an API call to exec into a pod. The subsequent IAM credential theft appears in CloudTrail but lacks the Kubernetes context explaining how the attacker got there.
Effective detection requires mapping the full attack chain: suspicious exec calls, anomalous API server requests, unexpected service account token usage, and the resulting cloud API calls. Building these detection rules is a core skill we develop in our hands-on bootcamp labs, where participants trace complete attack chains from pod compromise to cloud account takeover.
Building the Skills That Matter
Kubernetes security requires fluency across container orchestration, cloud IAM, and penetration testing, three distinct skill domains that practitioners must integrate to identify critical attack paths. Organizations that invest in building these hybrid skills find the attack vectors that adversaries exploit in production environments.
Kubernetes security in cloud environments sits at the intersection of container orchestration knowledge, cloud IAM expertise, and traditional penetration testing skills. Practitioners who can bridge all three domains are exceptionally rare, and exceptionally valuable. The organizations that invest in building these hybrid skills are the ones that find the critical attack paths before adversaries do.
Bottom Line
Kubernetes has emerged as the primary pivot point in cloud attacks, with pod identity mechanisms (IRSA, Workload Identity, Workload Identity Federation) enabling direct federation from container compromise to cloud account access. The attack chain of pod compromise, container escape, and cloud credential theft is repeatable across EKS, AKS, and GKE, making Kubernetes RBAC and cloud IAM integration the highest-value attack surface in managed Kubernetes environments. Detection requires correlating signals across Kubernetes audit logs and cloud provider audit trails to identify lateral movement before cloud APIs are abused.
%201%20(1).png)