<p>The EKS docs in the page <a href="https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html" rel="nofollow noreferrer">Amazon EKS node IAM role</a> state that before you create worker nodes, you must create a role with the following policies:</p>
<ul>
<li>AmazonEKSWorkerNodePolicy</li>
<li>AmazonEC2ContainerRegistryReadOnly</li>
<li>AmazonEKS_CNI_Policy</li>
</ul>
<p>Regarding the last one, the docs state that:</p>
<blockquote>
<p>Rather than attaching the policy to this role however, we recommend that you attach the policy to a separate role used specifically for the Amazon VPC CNI add-on</p>
</blockquote>
<p>Can someone explain why is this recommended?</p>

<p>The reason why it is recommended to attach the AmazonEKS_CNI_Policy to a separate role used specifically for the Amazon VPC CNI add-on is to follow the principle of least privilege.</p>
<p>The Amazon VPC CNI (Container Network Interface) is a plugin for Kubernetes that enables networking between pods and the rest of the cluster in a VPC (Virtual Private Cloud) environment. This plugin needs certain permissions to function properly, such as creating and managing network interfaces and route tables.</p>
<p>By creating a separate role for the Amazon VPC CNI add-on, you can ensure that this plugin has only the necessary permissions to perform its specific tasks, and not other permissions that may be included in the AmazonEKSWorkerNodePolicy. This helps to reduce the risk of accidental or intentional misuse of privileges, and makes it easier to audit and manage permissions for different components of your cluster.</p>
<p>Additionally, separating the Amazon VPC CNI permissions from the worker node IAM role can also help with troubleshooting, as it allows you to isolate issues related to the network plugin from other potential problems that may affect the worker nodes or other components of your cluster.</p>
