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…