A pod that has not been given its own identity will often use the node’s, and the node role is usually far broader than any single workload needs. That turns a modest application flaw into cloud access, because code running in the container can request credentials from the instance metadata service and act as the whole node. NIST’s application container security guide, SP 800-190, describes this as one of the core risks of shared host infrastructure.
How the inheritance happens
Every EKS worker node runs with an instance profile so the kubelet can pull images, join the cluster and write logs. Any process on that node can reach the metadata endpoint and ask for those credentials, and unless you have stopped it, a container counts as a process on that node. Where the node role has been widened over time, perhaps to let one workload read a bucket, every pod on that node gained the same access. The fix is to give workloads their own identity through IAM roles for service accounts or EKS Pod Identity, then block the pod route to the node credentials.
Blocking the metadata path
You should set the metadata hop limit to one on your worker nodes, which stops a container reaching the endpoint while leaving the kubelet working. Require IMDSv2 so a simple request cannot retrieve a token, and confirm the setting on the launch template rather than on individual instances, since new nodes are created constantly by autoscaling. Network policy can add a second layer by denying egress to the metadata address from application namespaces. Test it from inside a running pod rather than trusting the configuration, because a single node group created outside the standard template will behave differently.
“The first thing I do on a Kubernetes engagement is exec into an ordinary application pod and curl the metadata service. If credentials come back, the cluster boundary is decoration, because every workload on that node is now as privileged as the noisiest one. It takes thirty seconds to check and it changes the whole shape of the report.”
William Fieldhouse, Director, Aardwolf Security Ltd
Cluster permissions are a separate question
IAM decides what a workload can do in AWS, and Kubernetes role-based access control decides what it can do in the cluster. Both need review, and they interact through the mapping that grants cluster access to AWS identities. Look for service accounts bound to cluster-admin, for wildcard rules in roles, and for the ability to create pods in a namespace that also allows host mounts, since that combination lets somebody schedule a privileged container and read the node filesystem. Pod Security Standards enforced through admission control are what stop that, and audit mode is not enforcement.
What to include in a review
Ask for the cluster to be assessed from three positions: outside, inside an ordinary pod, and with a low privilege cluster credential. Each answers a different question, and the middle one produces most of the findings. Cloud penetration testing for AWS covers the identity relationships that let a container reach the account, while container vulnerability scanning keeps the images themselves honest, which matters because an outdated base image is the most common route into the pod in the first place.
Frequently asked questions about EKS permissions
These questions come up whenever a platform team hardens a cluster.
Is Pod Identity better than IAM roles for service accounts?
It is simpler to operate, since it removes the trust policy per cluster and the OIDC provider setup. Both achieve the same goal of workload-scoped credentials, so use whichever your tooling supports properly.
Do managed node groups fix this by default?
No. They simplify provisioning and still run with an instance profile your pods can reach unless you set the hop limit. Check the launch template rather than assuming the default is safe.
