Is it possible to prevent a kubernetes pod on EKS from assuming the node's IAM role?

Question

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?

Shoplifter

How can a Pod assume the Node role? I think a Pod only can assume the role associated with the ServiceAccount? – Polycarp

@jonas by requesting the meta data API of the host node. Iptables is the standard way to prevent that. – Belenbelesprit

The iptables rule doesn't block access to the AWS API, only the host nodes instance metadata (which contains instance profile credentials) – Belenbelesprit

@Belenbelesprit Interesting! Sounds like you should post an answer? – Polycarp

Answer 1

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.

Reams

You still have to block access to the instance metadata service even if using IAM roles for service accounts. See here: docs.aws.amazon.com/eks/latest/userguide/…. – Belenbelesprit

That's correct, they should be used together. It's actually pointed in the documentation for on the service accounts page and on the one describing how you can block the metadata service. I'll update my answer. – Reams

Answer 2

I think this is best explained in the Official EKS Best Practices Guides > Security > Identity and Access Management (IAM) > Restrict access to the instance profile assigned to the worker node

Quoting from it

the pod can still inherit the rights of the instance profile assigned to the worker node

it is strongly recommended that you block access instance metadata to minimize the blast radius of a breach.

It doesn't matter if you are using IRSA (IAM Roles for Service Accounts) or not, it's good to block the access to the instance metadata from pods.

If a pod actually need IAM credentials then you should use IRSA (or other means get IAM credentials) that way you can be in line with least privilege principle.

To block the pod from getting the IAM credentials from the EKS node ec2 instance profile (iam role of the node) there are 3 alternatives mentioned in Restrict access to instance profile:

• Modify the launch template to require the instance to use IMDSv2 (emphasis on v2) with hop count set to 1
• iptables in the node.
  • this is way more cumbersome to configure
  • Amazon EC2 > Instances > Configure instances > Instance metadata and user data > Retrieve instance metadata > Limit instance metadata service access
• Kubernetes network policies NetworkPolicy
  • Create a NetworkPolicy that applies to all pods that blocks the access to 169.254.169.254/32 (the metadata discovery address)
  • Add a NetworkPolicy to the specific pods that need access to it. This still violates the least privilege principle, because those pods will get all permissions of the node iam role which are already broad.

The best option (IMHO) is to require IMDSv2 and hop count/hop limit 1 in the launch template HttpEndpoint=enable,HttpTokens=required,HttpPutResponseHopLimit=1, the pods will still be able to make the request to the metadata discovery endpoint but they will never get the response because the response packets will be dropped at the first router (virtual) between the node and the pod.

Aldas