On Amazon EKS, harden in this order: understand what AWS secures and what you must, control who can reach the cluster and what Kubernetes permissions they get, give each workload its own narrow AWS identity, and replace the default allow all pod networking with network policy.
What is your side of the line?
The EKS Best Practices Guide opens with the shared responsibility model: for a managed service AWS is responsible for security of the cloud and you, the customer, for security in it. The control plane belongs to AWS. Your worker nodes, workloads, access mappings and policies belong to you.
One orientation note. The guide's pages now say that the guide has moved to the AWS documentation, so check the current AWS docs for newer features as you apply this.
Who can reach the cluster?
The guide explains that after the AWS IAM service authenticates a user, the Kubernetes API server reads the aws-auth ConfigMap in the kube-system namespace to map that identity to an RBAC group. It describes the mapping as static, linking IAM users and roles to Kubernetes groups, which RoleBindings and ClusterRoleBindings then reference.
Treat that mapping as a high value object. Whoever can edit it can grant themselves cluster access. Keep the list short, map IAM roles instead of individual users, and review it on a schedule. AWS has since added newer ways to manage cluster access, so check the current documentation for what your cluster version supports.
Constructed example: a contractor's IAM user was mapped to a group bound to cluster-admin for a one week project. Nobody removed it. A quarterly access review that lists every mapping and its RBAC binding would catch it.
How do pods get AWS permissions?
The guide has a section on identities and credentials for pods, with a comparison of EKS Pod Identity and IAM roles for service accounts (IRSA). The point of both is the same: a pod should get its own scoped role, not the node's. If pods inherit the node role, every workload on that node can use every permission the node holds.
Pick one mechanism, give each service account a role that allows only what that service calls, and block pod access to the instance metadata service where your configuration allows it.
What does the network allow by default?
The guide states that within a Kubernetes cluster all pod to pod communication is allowed by default and that this is "not considered secure". Network policies restrict traffic between pods and between pods and external services at layers 3 and 4. They need a network plugin that enforces them, so confirm yours does.
A sound starting point is a default deny policy in each namespace, then explicit allows: the web tier reaches the API, the API reaches the database, and nothing else. Add security groups for the cluster boundary and encryption in transit, for which the guide lists service meshes, CNI options and ingress controllers.
What else is on the list?
The guide's sections also cover pod security, multi tenancy, detective controls, data encryption and secrets management, runtime security, infrastructure security, image security, and incident response and forensics. Work through them after the four above.
How to check or apply this
- Write down which layers AWS runs and which you run for this cluster.
- Export the access mapping and every RBAC binding it grants, and remove anything unused.
- Move pods to Pod Identity or IRSA, and delete permissions from the node role that pods no longer need.
- Apply a default deny network policy per namespace and add allows from observed traffic.
- Scan images before they reach the cluster and keep an inventory of what is running.
- Turn on audit logging and decide who reads it.
- Rehearse removing a compromised node and rotating the credentials it could reach.
Quick check
Are pods isolated from each other on EKS by default?
No. The EKS guide says all pod to pod communication is allowed by default, so add network policies.
Why not let pods use the node role?
Every pod on the node would share its permissions. Per workload roles limit the damage of one compromised pod.
Sources
- EKS Best Practices Guide, Security
- EKS Best Practices Guide, Identity and access management
- EKS Best Practices Guide, Network security
Last reviewed: 18 October 2026.
