<p>By default, any kubernetes pod on AWS EKS can assume the IAM role of the underlying node. That means all containers <a href="https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html" rel="noreferrer">immediately get access</a> to policies such as AmazonEKSWorkerNodePolicy and AmazonEC2ContainerRegistryReadOnly, which I want to avoid.</p>
<p>I don't want to block the AWS API entirely from all containers using <code>iptables</code> because, given the proper credentials, it should be possible to make calls to it.</p>
<p>With <a href="https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html" rel="noreferrer">IAM roles for service accounts</a>, it's possible to associate a certain IAM role with the service account of the pod. But does that prevent a pod from assuming the IAM role of the underlying node?</p>

<p>The two main things that could prevent it (if used together) and are described in the AWS documentation:</p>
<ul>
<li>IAM roles for service accounts as already pointed out by the OP.</li>
<li><a href="https://docs.aws.amazon.com/eks/latest/userguide/best-practices-security.html" rel="noreferrer">Blocking access to instance metadata service</a> - blocking IMDS may stop some of the running apps / services that you have, so should be properly tested beforehand.</li>
</ul>
<p>On top of that as pointed out in the documentation this depends on the CNI and in case you use Calico this is a nice <a href="https://blog.christophetd.fr/privilege-escalation-in-aws-elastic-kubernetes-service-eks-by-compromising-the-instance-role-of-worker-nodes/" rel="noreferrer">write-up</a> on the problem and mitigation with Calico network policies.</p>
<p>Another option is to use <a href="https://github.com/jtblin/kube2iam" rel="noreferrer">kube2iam</a>.</p>
