AWS EKS and the Least Privilege Principle

When hosting workload with AWS, one of the key security principles we follow is — Least Privilege Access. The idea is to give the minimum set of permissions required for the service to perform the business. But when you work with Kubernetes to host your containerised workload, this principle at times goes for a toss. How??? Let’s see —

Assume Example Corp. has 2 applications which needs different permission set to execute their business logic.

1. Both applications are hosted in a single AWS Elastic Kubernetes Service (EKS) managed cluster.
2. Application A needs access to AWS S3 and Application B needs access to AWS DynamoDB.
3. Cluster is launched by a common DevOps team.
4. To follow the best practices in terms of giving the access, DevOps team creates AWS IAM Role and assigns S3 and DynamoDB access permissions to it.
5. The IAM role is assumed by the EC2 worker nodes.

Now, as and when Kubernetes Pods for Application A and Application B are launched in the EKS cluster, they can access S3 and DynamoDB as the EC2 worker nodes on which they are running can assume the role. But is this not breaking the principle of least privilege??? Application A, if wants, can also talk to DynamoDB and Application B can do the same with S3. I know, you must be thinking, a proper code review can prevent this from happening. But what if one of the applications gets compromised at runtime because of some vulnerability…