Kubernetes node impersonation is authenticating to the cluster API as a node the attacker does not own. On EKS this is done by wrapping stolen AWS caller identity into a k8s-aws-v1 bearer token via the AWS IAM authenticator, so the attacker is treated as that EC2 node. A node identity can read secrets projected to its pods and expand access from there. Defend with IMDS hardening, IAM least privilege, and node-authorization controls.
What Kubernetes node impersonation is
On managed Kubernetes like EKS, an AWS IAM identity is translated into a Kubernetes identity by the IAM authenticator, and a node authenticates as a node identity that has read access to the resources its own pods use. If an attacker can produce a valid node token, the cluster treats them as that node, with the access that comes with it.
How it works and example
The attacker first steals EC2 instance-role credentials, usually from the metadata service. They then build a presigned AWS caller-identity request and wrap it as a k8s-aws-v1 bearer token, which the cluster accepts as the node's identity. Authenticated as the node, they read the secrets and tokens projected into that node's pods and pivot deeper, as seen in a 2026 cluster intrusion.
How to defend against it
Cut off the credential source: require IMDSv2 with a low hop limit so pods cannot easily read instance-role credentials, and give node roles least-privilege IAM. Enforce the NodeRestriction admission plugin and node authorisation so a node can only touch its own resources, and monitor for node authentication coming from unexpected sources or identities.
References
- [1]MITRE ATT&CK Cloud Matrix(MITRE ATT&CK)
- [2]HuggingFace, Agent intrusion technical timeline(HuggingFace)
- [3]Amazon EKS cluster authentication(AWS)
Weak IMDS and broad node IAM turn one stolen credential into a node takeover. Talk to a security expert about testing your EKS identity paths.