Hardening an AWS EKS cluster: IRSA, NetworkPolicies, restricted Pod Security and Secrets Manager via CSI

A freshly created EKS cluster is permissive by default. Every pod can reach every other pod, workloads can run as root, and giving an application AWS access is as simple as attaching permissions to the node role. This post outlines four controls to mitigate these risks using an orders-api deployment as an example.

First, implement IAM Roles for Service Accounts (IRSA). This lets a Kubernetes service account assume an IAM role, receiving a projected, short-lived token that the AWS SDK exchanges for temporary credentials. No access keys are required, and permissions are not granted on the node. Register the cluster's OIDC issuer with IAM and create a least-privilege policy for reading a specific secret from AWS Secrets Manager. Then create the role and service account together, associating the policy with the role.

Next, implement NetworkPolicies to enforce default-deny traffic within the orders namespace. Allow necessary traffic, such as DNS requests to the kube-dns service, and open specific paths for the orders-api to communicate with the database.

Third, enable Pod Security Admission with restricted settings to block privileged and root containers at admission time.

Lastly, use the Secrets Store CSI driver to mount AWS Secrets Manager secrets as files, eliminating the need to manually copy secrets into Kubernetes Secrets. This approach restricts the attack surface and enhances security within the EKS cluster.