Researchers Demonstrate EKS Access Entry Escalation and Pod Identity Credential Theft Paths
Summary
The article analyzes how compromised IAM identities could gain EKS access and escalate privileges, and demonstrates intercepting Pod Identity tokens and temporary credentials from a host-network pod to access cloud resources.
Key points
- With permissions to enumerate EKS access entries and policies, an attacker using a compromised IAM identity can identify accessible clusters and assess assigned Kubernetes privileges.
- IAM principals with eks:CreateAccessEntry and eks:AssociateAccessPolicy may be able to grant themselves cluster-admin access; the article advises treating these permissions as highly privileged.
- EKS View and Edit policies can expose risks including secrets in pod settings or logs, secret access, and paths to higher privileges; the article recommends least privilege and namespace scoping.
- An attacker who compromises a host-network pod can capture traffic to the Pod Identity Agent at 169.254.170.23, including a JWT request and the returned temporary IAM credentials.
- The captured credentials could let an attacker act as the associated IAM role and access cloud resources; activity spanning Kubernetes and cloud logs may complicate investigations.
- The article contrasts Pod Identity with IRSA, stating that IRSA avoids sending tokens to the in-cluster endpoint and can prevent the described interception risk.
Article Details
- Attack Vectors
- A compromised IAM identity can enumerate EKS clusters and its associated access policies and Kubernetes groups using EKS Access Entries APIs.
- An IAM principal with eks:CreateAccessEntry and eks:AssociateAccessPolicy permissions can grant itself cluster-admin access through AmazonEKSClusterAdminPolicy; CreateAccessEntry may also allow mapping the identity to an existing privileged Kubernetes group.
- AmazonEKSEditPolicy access can enable privilege escalation by creating pods, executing into pods using privileged service accounts, or modifying sensitive ConfigMaps such as fluent-bit or node-problem-detector.
- A compromised pod with hostNetwork enabled can intercept traffic to the Pod Identity Agent endpoint and capture JWT tokens and temporary IAM credentials requested by other pods on the same worker node.
- An attacker with suitable Kubernetes permissions can abuse existing IRSA or Pod Identity permissions assigned to cluster pods to access cloud resources.
- Defensive Notes
- Apply least privilege to IAM and Kubernetes access; treat eks:CreateAccessEntry and eks:AssociateAccessPolicy as highly privileged permissions.
- Avoid assigning AmazonEKSViewPolicy to untrusted principals; use granular Kubernetes RBAC permissions and namespace scope where possible.
- Do not treat AmazonEKSEditPolicy as a security boundary because it grants secret access and may allow privilege escalation.
- Review pod environment variables, process command lines, logs, and sensitive ConfigMaps for exposed secrets or privileged execution paths.
- Consider IRSA to reduce the risk of token or credential sniffing described for Pod Identity, because it avoids exchanging the token through the internal Pod Identity Agent endpoint.
MITRE ATT&CK
T1552.001 · Credentials In FilesThe article describes obtaining temporary IAM credentials from the Pod Identity Agent response and using them for cloud access.T1552.005 · Cloud Instance Metadata APIThe intercepted HTTP request exposes a JWT token in plaintext, which can be captured from the authorization header.T1557 · Adversary-in-the-MiddleA compromised host-network pod can perform a MitM interception of traffic to and from the Pod Identity Agent endpoint.T1580 · Cloud Infrastructure DiscoveryThe article describes enumerating accessible EKS clusters and their access policies and Kubernetes groups using EKS APIs.T1611 · Escape to HostThe article describes abusing Kubernetes permissions to execute into pods or create pods to access privileged service-account identities.
Vendors
Products
EKSAWS recently enhanced its managed Kubernetes service, EKS, with the introduction of EKS Access Entries and Policies, along with EKS Pod Identity. These advancements optimize the workflow for cluster administrators byEKS Access EntriesAWS recently enhanced its managed Kubernetes service, EKS, with the introduction of EKS Access Entries and Policies, along with EKS Pod Identity. These advancements optimize the workflow for cluster administrators byEKS Pod IdentityKubernetes service, EKS, with the introduction of EKS Access Entries and Policies, along with EKS Pod Identity. These advancements optimize the workflow for cluster administrators by enhancing the authenticationIRSAOnce in the cluster, an attacker can abuse the existing IRSA or Pod Identity permissions assigned to cluster pods. To find all the pods assigned EKS pod identity, one can run the following command:
Tools
jq[cloudshell-user@ip-10-130-85-108 ~]$ kubectl get pods -o json | jq -r '.items[]|select(any(.spec.containers[].env[];.name=="AWS_CONTAINER_CREDENTIALS_FULL_URI"))|.metadata.name + " " + .metadata.namespace + " " +kubectl>kubectl auth can-i --list tcpdumpa pod in host network mode (i.e., the pod uses the network namespace of the host node). Let’s use tcpdump to intercept any networking traffic to/from the Pod Identity Agent (169.254.170.23) on any of the networkWiresharkLet’s analyze the pcap file using Wireshark: