A workload that presents no credentials of its own usually doesn't fail — it silently authenticates as its **host**. On EKS, a pod with no identity configured calls AWS as the node's EC2 instance role; CloudTrail attributes the request to the node, not the pod. The source article demonstrates it: `aws s3 ls` from an unconfigured pod is denied *as the node role* — proof that every pod on the node shares one identity. Two distinct failures: - **Over-permission** — colocated workloads inherit the union of permissions any of them needed; least privilege breaks at the host boundary instead of the workload boundary. - **Attribution loss** — audit logs show the host identity, so per-workload anomaly detection and forensics are blind. The shape recurs wherever identity defaults to the runtime: CI jobs inheriting the runner's role, cron scripts running as a shared machine account, containers reading the Docker host's credential file. Fix shape: give each workload an identity that **outranks** the host fallback — IRSA via [[Workload Identity Federation]], or per-client keys per [[Server-to-Server API Key Authentication]] so calls stay attributable. ## Source [Diving into IAM Roles for Service Accounts](https://aws.amazon.com/blogs/containers/diving-into-iam-roles-for-service-accounts/) — Gaurav Pilay, AWS Containers Blog, 2022-02-28. --- *Source: Diving into IAM Roles for Service Accounts (Gaurav Pilay, AWS Containers Blog 2022)*