5
votes

By default, any kubernetes pod on AWS EKS can assume the IAM role of the underlying node. That means all containers immediately get access to policies such as AmazonEKSWorkerNodePolicy and AmazonEC2ContainerRegistryReadOnly, which I want to avoid.

I don't want to block the AWS API entirely from all containers using iptables because, given the proper credentials, it should be possible to make calls to it.

With IAM roles for service accounts, 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?

1
How can a Pod assume the Node role? I think a Pod only can assume the role associated with the ServiceAccount?Jonas
@jonas by requesting the meta data API of the host node. Iptables is the standard way to prevent that.jordanm
The iptables rule doesn't block access to the AWS API, only the host nodes instance metadata (which contains instance profile credentials)jordanm
@jordanm Interesting! Sounds like you should post an answer?Jonas

1 Answers

4
votes

The two main things that could prevent it (if used together) and are described in the AWS documentation:

  • IAM roles for service accounts as already pointed out by the OP.
  • Blocking access to instance metadata service - blocking IMDS may stop some of the running apps / services that you have, so should be properly tested beforehand.

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 write-up on the problem and mitigation with Calico network policies.

Another option is to use kube2iam.