A hacked container can hand an attacker your AWS account
Containers in ECS and EKS read their AWS credentials from a local endpoint. Pop one container and the attacker calls AWS as its role, with no key to steal. Here is how it works and how to bound the blast radius.
A single compromised container should not become broad cloud access. Too often it does.
What it is
ECS tasks read their task role from the container credential endpoint, and EKS pods get a role through pod identity or, if it is not blocked, the node instance profile from the metadata service. An attacker who gets code execution in a container, through a vulnerable app, an SSRF, or a poisoned image, reads those credentials and calls AWS as the task or node role. There is no key stored or stolen. In ATT&CK terms this is T1552 (unsecured credentials) leading to T1078 (valid accounts).
Why it works
The role is legitimate, so the calls blend in with normal traffic. If the role is over-privileged, or if pods can reach the node instance role, one container reaches far more than it should. The blast radius is the role’s permissions, not the single container.
How to detect it
Watch for the task or node role making API calls outside its normal pattern, or its credentials being used from an IP outside the cluster. CloudTrail records every call the role makes; GuardDuty flags off-cluster credential use and pods reaching the node metadata service.
The fix that holds
Give each task or pod a dedicated least-privilege role: task roles in ECS, pod identity in EKS. Block pods from the node metadata service with a metadata hop limit and network policy. Keep images patched, add runtime security, and alert on role credentials used off-cluster.
Practice it
We built an ECS and EKS task-role theft scenario in GraphLattice Range so teams work detection, containment, and the least-privilege fix end to end.