Amazon EKS runs under a shared responsibility model that AWS spells out plainly in its own security documentation: AWS secures the control plane — the API server, controller manager, scheduler, and the etcd database behind them — while everything in the data plane is the customer's job. That includes worker node configuration, the security groups controlling traffic between the control plane and your VPC, node operating system patching, container and workload configuration, network firewall rules, and IAM access management. EKS itself carries a long list of compliance attestations — SOC, PCI, ISO, FedRAMP-Moderate, IRAP, C5, K-ISMS, ENS High, OSPAR, HITRUST CSF, and HIPAA eligibility — which covers AWS's half of the boundary but says nothing about whether your node group is still running kernel 5.4 from 2022 or whether a pod on it can reach the instance metadata service. The CIS Amazon EKS Benchmark, updated to v2.0.0 in June 2026 to align with Kubernetes 1.34 and 1.35, translates that data-plane responsibility into a broad set of concrete controls spread across control plane configuration, worker node security, RBAC and service accounts, pod security standards, and managed services. This post walks through hardening an EKS cluster using only native AWS controls — IAM, security groups, and EKS add-ons — in the order AWS's own security guide lays them out.
What does AWS actually secure, and what's left to you?
AWS's control-plane boundary covers the API server, the scheduler, controller-manager, and etcd, all patched and made highly available without customer action. Everything downstream of that line is explicitly the customer's responsibility per AWS's shared responsibility model: node OS patching, security group rules governing control-plane-to-node traffic, container runtime and workload configuration, network segmentation, and IAM policy scoping. This isn't a minor footnote — worker nodes are just EC2 instances (or Fargate microVMs) that you own the AMI, kernel version, and OS-level patch cadence for. AWS's EKS security documentation organizes this responsibility into distinct areas: cluster best practices, vulnerability analysis, compliance validation, EKS-specific considerations, Kubernetes-native considerations, EKS Auto Mode security, and IAM for EKS. That structure is a reasonable checklist order for a hardening pass, and it's the order this post follows: identity first, network second, workload configuration third.
How should IAM be scoped for an EKS cluster?
IAM is the first control plane most teams get wrong because Kubernetes RBAC and AWS IAM are two separate authorization systems that meet at the aws-auth ConfigMap or, in newer clusters, EKS's native access-entry API. A cluster admin's IAM role does not automatically translate into a Kubernetes cluster-admin binding — that mapping has to be deliberately scoped, and the common failure mode is granting broad eks:* permissions to CI/CD roles that only ever need to run kubectl apply against a single namespace. The same least-privilege discipline applies to IAM Roles for Service Accounts (IRSA) or EKS Pod Identity, which let individual pods assume narrowly-scoped IAM roles instead of inheriting the node's instance role — a pod pulling from S3 should get read access to one bucket prefix, not the node role's full permission set. This mirrors the pattern AWS recommends for registry access generally: an ECR pull role, for instance, needs exactly ecr:GetAuthorizationToken, ecr:BatchGetImage, and a handful of read-only actions — nothing resembling ecr:*.
What do security groups need to enforce between the control plane and nodes?
Security groups are the network boundary AWS explicitly calls out as a customer responsibility, since the managed control plane and your worker nodes sit on opposite sides of an ENI-based connection that you configure. The cluster security group (created automatically or supplied by you) controls bidirectional traffic between the control plane and every node, and a common hardening step is separating that from node-to-node security groups so that a compromised pod on one node can't laterally reach the kubelet API on every other node in the cluster. Restricting the public API endpoint's CIDR allow-list — or disabling public access entirely in favor of a private endpoint reachable only from inside the VPC or over VPN — closes off the most direct path an external attacker has to the API server itself. None of this replaces Kubernetes NetworkPolicies for pod-to-pod traffic, but security groups are the layer that exists before any pod is even scheduled, and AWS's guidance treats it as a first-class part of the data-plane boundary.
Why does AWS discourage root containers and host namespace access?
AWS's security documentation makes the underlying reasoning explicit: Linux containers rely on cgroups and namespaces to limit what they can touch, but every container on an instance still shares that instance's single Linux kernel — unlike a hypervisor, there's no hard isolation boundary underneath. That's why letting a container run as UID 0 or opening up host-level network or process namespaces cuts against the isolation containers are supposed to provide in the first place. A root process inside a container that also has hostPID: true or hostNetwork: true can see and potentially interact with every other process and network interface on that node, including workloads from other tenants if the node is shared. Pod Security Standards, which the CIS EKS Benchmark devotes a substantial share of its controls to, enforce this at admission time via the built-in Pod Security Admission controller — the restricted profile blocks host namespace access, requires non-root UIDs, and drops all Linux capabilities by default. Enforcing restricted cluster-wide (with narrow, audited exceptions for genuinely privileged workloads like CNI plugins) turns AWS's advisory guidance into an admission-time gate rather than a code-review convention.
Which EKS add-ons reduce the manual hardening burden?
EKS add-ons matter here because AWS ships and patches several of them directly, which shrinks the surface area you're personally responsible for keeping current — but only for the components AWS manages, not for your own workloads or third-party add-ons. The Amazon VPC CNI, kube-proxy, CoreDNS, and the EBS/EFS CSI drivers are all available as EKS add-ons with AWS-managed version updates and CVE patching, versus self-installed manifests that silently drift out of date. EKS Auto Mode goes further, taking over node provisioning, AMI patching, and scaling entirely, and as of 2026 supports FIPS-validated cryptographic modules and GovCloud regions — relevant for teams with federal or regulated workloads who previously had to hand-roll that compliance posture on self-managed node groups. Using managed add-ons doesn't eliminate the shared responsibility line; it just moves more of the boundary onto AWS's side of it, which is a meaningful reduction in the patching backlog a platform team otherwise owns alone.
How Safeguard Helps
Safeguard doesn't manage your IAM policies or security groups — that native AWS configuration work is exactly what this post walked through, and there's no substitute for doing it directly in IAM and VPC. What Safeguard does is watch what actually runs on top of that hardened foundation: container images destined for your EKS node groups get scanned for known vulnerabilities before and after they ship, and a runtime detection engine watches the nodes themselves for the exact failure modes this post covered — privileged containers, container-escape behavior, and credential-dumping attempts on a host whose kernel every pod already shares. The same least-privilege discipline this post applied to IRSA roles and node policies extends to how Safeguard's own AWS integrations are scoped — connecting a registry or cloud account uses purpose-built, read-only credentials rather than a broad account-wide role. Native AWS controls set the perimeter; continuous scanning is what tells you whether what's actually running still matches it.