默认情况下，AWS EKS上的任何kubernetes pod都可以承担底层节点的IAM角色。这意味着所有容器都可以立即访问策略，如AmazonEKSWorkerNodePolicy和AmazonEC2ContainerRegistryReadOnly，这是我想要避免的。
我不想完全阻止使用iptables的所有容器使用AWS API，因为，给定适当的凭据，应该可以调用它。
使用服务帐户的IAM角色，可以将某个IAM角色与pod的服务帐户关联。但是，这是否阻止pod假设底层节点的IAM角色?
可以防止它的两件主要事情(如果一起使用)在AWS文档中有描述:
- 服务帐户的IAM角色，op已经指出。
- 阻止访问实例元数据服务-阻止IMDS可能会停止一些正在运行的应用程序/服务，所以应该事先进行适当的测试。
除此之外，正如文档中指出的，这取决于CNI，如果你使用Calico，这是一篇关于Calico网络策略的问题和缓解的很好的文章。
另一个选择是使用kube2iam。
我认为这是最好的解释在官方的最佳实践指南>安全比;身份和访问管理(IAM);限制对分配给工作节点的实例配置文件的访问
引用
pod仍然可以继承分配给工作节点的实例配置文件的权限
强烈建议您阻止访问实例元数据，以最小化漏洞的爆炸半径。
不管你是否使用IRSA (IAM Roles for Service Accounts)，最好阻止从pod访问实例元数据。
如果一个pod确实需要IAM凭据，那么你应该使用IRSA(或其他方式获得IAM凭据)，这样你就可以符合最小特权原则。
要阻止pod从EKS节点ec2实例配置文件(节点的IAM角色)获取IAM凭据，有3个替代方案在限制对实例配置文件的访问中提到:
- 修改启动模板要求实例使用IMDSv2(强调v2)) with跳数设为1
- 节点的
iptables。- 这个配置起来比较麻烦
- Amazon EC2;在实例;配置实例>实例元数据和用户数据>检索实例元数据>限制实例元数据服务访问
- Kubernetes网络策略
NetworkPolicy- 创建一个
NetworkPolicy，适用于所有阻止访问169.254.169.254/32(元数据发现地址)的pod - 将
NetworkPolicy添加到需要访问它的特定pod。这仍然违反了最小特权原则，因为这些pod将获得节点iam角色的所有权限，这些权限已经很广了。
- 创建一个
最佳选择(IMHO)是在启动模板HttpEndpoint=enable,HttpTokens=required,HttpPutResponseHopLimit=1中要求IMDSv2和跳数/跳数限制1,pod仍然能够向元数据发现端点发出请求，但它们永远不会得到响应，因为响应数据包将在节点和pod之间的第一个路由器(虚拟)上被丢弃。