AWS EKS Privilege Escalation: Pod Metadata to Cluster-Admin
How a compromised EKS pod can escalate to cluster-admin via EC2 metadata and node tokens, plus a persistent aws-auth backdoor technique.
Security researchers documented an attack chain on AWS Elastic Kubernetes Service (EKS) that allows an attacker with a foothold in a single compromised pod to escalate all the way to cluster-admin. The root issue: any pod can query its underlying EC2 instance's metadata service for an IAM token, which can then be exchanged for an EKS token carrying the system:node role via 'aws eks get-token'.
While Kubernetes' NodeRestriction feature normally limits what a system:node token can do, the researchers found that using 'kubectl create token' with bound-object parameters lets them request service account tokens for other pods scheduled on the same node. This effectively allows impersonating any higher-privileged pod colocated on that node — for example, one bound to a cluster-admin service account — turning a low-privileged pod compromise into full cluster takeover.
The writeup also describes a persistence technique: inserting an external AWS account's role ARN into the aws-auth configmap mapped to the system:masters group. Because aws-iam-authenticator only validates the caller's identity via AWS STS rather than checking live permissions, this backdoor survives even if the original EC2 IAM role is later stripped of all permissions.
Mitigations discussed include enforcing IMDSv2 with a hop limit of 1 to block pods from reaching instance metadata, or applying iptables rules on nodes as an alternative — though both can break services like Terraform that legitimately need pod-to-instance metadata access.