How does Amazon EKS Pod Identity differ from putting AWS keys in Kubernetes secrets or relying on the node IAM role?
Quick Answer
EKS Pod Identity maps an IAM role to a Kubernetes service account, so pods get short-lived AWS credentials through the EKS Pod Identity Agent instead of static keys or broad node-role credentials. It improves least privilege, auditability, and operational separation between IAM and cluster administration.
Detailed Answer
Putting AWS access keys in Kubernetes secrets creates a rotation and leakage problem. Relying on the node IAM role is also too broad because every pod on that node can potentially reach credentials unless IMDS access is tightly restricted. EKS Pod Identity gives the application a role through its Kubernetes service account, similar in spirit to an EC2 instance profile but scoped to the pod identity.
Operationally, each association maps one IAM role to one service account in one namespace in the cluster. When a pod uses that service account, EKS injects environment variables so supported AWS SDKs and the AWS CLI use the Pod Identity credential flow. The Pod Identity Agent runs as a DaemonSet on Linux EC2 nodes and serves credentials to pods on the same node.
A strong production answer includes the tradeoffs: restrict IMDS so pods cannot fall back to node credentials; remember that containers are not a security boundary; account for eventual consistency after creating associations; configure proxy NO_PROXY for the link-local agent address; and know that Fargate and Windows pods are not supported for EKS Pod Identity.
Code Example
aws eks create-pod-identity-association \ --cluster-name prod-eks \ --namespace payments \ --service-account checkout-api \ --role-arn arn:aws:iam::123456789012:role/payments-checkout-s3 kubectl -n payments set serviceaccount deployment/checkout-api checkout-api # The workload should use the default AWS SDK credential chain.
Interview Tip
Do not stop at 'it avoids secrets.' Mention service-account scoping, IMDS restriction, the DaemonSet agent, eventual consistency, supported node types, and CloudTrail audit value.