Your Kubernetes RBAC can be perfectly configured, but your pods could still have too much AWS access

Sajana Kavinda — Fri, 06 Nov 2026 14:00:24 +0000

One thing I find particularly interesting about Amazon EKS security is that we're dealing with two different permission systems:

Kubernetes RBAC: Controls what a workload or user can do inside the Kubernetes API.
AWS IAM: Controls what a workload can access across AWS services.

The problem? Securing one doesn't automatically secure the other.

Scenario:

You have an application running on an EKS Cluster. Its Kubernetes ServiceAccount has very limited access. It can only access the resources it needs inside its namespace.

Looks good from the Kubernetes security perspective.

But what if that container gets compromised?

If the workload has access to excessive AWS permission through its IAM Identity, an attacker could potentially use those credentials to interact with resources outside the cluster.

This is where IAM Roles for Service Accounts (IRDA) and EKS Pod Identity becomes particularly important.

A few things O'd pay attention to when reviewing an EKS environment:

Avoid relying on the worker node IAM role for application-level permission.
Give each workload its own AWS Identity where appropriate.
Restrict access to EC2 Instance Metadata Service (IMDS) to prevent unintended access to node credentials.
Keep IAM trust policies tightly scoped to the intended cluster, namespace and ServiceAccount.
Review AWS permission independently of Kubernetes RBAC.

Something worth considering about:

When was the last time you reviewed the AWS permission available to your pods, rather than just reviewing their Kubernetes RBAC policies?

I'd be interested to hear how others approach this in production EKS environments.

DEV Community: Sajana Kavinda

Your Kubernetes RBAC can be perfectly configured, but your pods could still have too much AWS access