Recommended Free Tools
Hardening an Amazon EKS cluster takes more than adding admission policies. Use Terraform to manage reviewed, version-pinned infrastructure changes; use Kubernetes controls such as Pod Security Admission or Kyverno to govern what workloads can run; and separately secure identities, network paths, secrets, and monitoring. AWS manages the EKS control plane infrastructure, but your team remains responsible for the configuration and workloads in your AWS environment.
Start with the EKS shared-responsibility boundary
AWS describes EKS security as a shared responsibility: AWS operates the Kubernetes control plane infrastructure, including its control-plane nodes and etcd database, while customers secure their cloud configuration and workloads. A managed control plane reduces operational work; it does not secure your application containers, AWS permissions, cluster access, network rules, or data for you.
AWS’s EKS security guidance spans identity and access management, pod and runtime security, networking, tenancy, detective controls, infrastructure, encryption and secrets, compliance, incident response, and image security. Treat these as connected control areas. Kyverno can help enforce workload rules, but cannot replace IAM review, secret protection, or monitoring.
Control human and workload access
Limit access for people and automation
Review both AWS IAM permissions and Kubernetes RBAC: a narrowly scoped AWS role does not guarantee narrow Kubernetes permissions, and vice versa. AWS notes that the principal that creates an EKS cluster receives system:masters access in the control plane. Record the creating principal, maintain explicit access mappings, and periodically review who can reach the Kubernetes API and what each identity can do.
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
Audit ClusterRoleBindings and the permissions granted to system components, including CSI drivers and DaemonSets. Remove permissions that are not needed, check effective access rather than relying only on role names, and monitor Kubernetes API audit activity. Separate ordinary development credentials from credentials permitted to change cluster infrastructure or enforce production policies.
Give AWS permissions to the workloads that need them
For pods that call AWS APIs, use a workload identity design rather than distributing long-lived credentials. EKS offers IAM Roles for Service Accounts (IRSA), which uses an OIDC-backed service-account token exchange, and EKS Pod Identity, which uses an agent on eligible worker nodes and requires supported AWS SDKs. The right choice depends on existing cluster setup, worker architecture, SDK compatibility, and migration requirements; neither is universally preferable.
In either design, scope the role trust to the intended cluster, namespace, and service account, then grant only the AWS actions that workload requires. For pods that do not need Kubernetes API access, disable automatic service-account token mounting where the application permits it. Tokens can be exposed by compromised node processes, and tokens associated with IAM roles can provide a path to AWS credentials; identity features do not eliminate that risk.
Choose pod admission controls deliberately
Kubernetes Pod Security Admission (PSA) is built in and applies the Pod Security Standards: Privileged, Baseline, and Restricted. It is a straightforward way to set a baseline for pod security. Kyverno is a separately installed policy engine: its Kubernetes-resource policies can validate, mutate, or generate resources and can cover rules beyond pod profiles. Kyverno also supports OCI image supply-chain checks, and its CLI can test policies in CI/CD.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Consideration | Pod Security Admission | Kyverno |
|---|---|---|
| Operations | Built into Kubernetes; no separate policy controller to install. | Requires installing, operating, upgrading, and monitoring an additional component. |
| Scope | Applies the Privileged, Baseline, and Restricted pod security profiles. | Can validate and mutate a wider range of Kubernetes resources, and generate resources. |
| Testing | Uses Kubernetes PSA configuration and enforcement behavior. | Policies can be tested with the Kyverno CLI in a CI/CD pipeline. |
| Best fit | A relatively simple pod-security baseline. | More tailored rules, mutation or generation, or policy checks beyond pod profiles. |
For either approach, harden workloads with settings compatible with their function: run as non-root, drop unnecessary Linux capabilities, disallow privilege escalation, avoid privileged containers, restrict host namespaces and hostPath volumes, and use a read-only root filesystem where supported. Do not assume every system or application pod can use identical restrictions: privileged access may be necessary for some system-wide components, while a restrictive profile can break application behavior.
Roll out policy without surprising production
- Inventory workloads. Identify pods that need host access, elevated privileges, writable filesystems, or service-account tokens, and establish which exceptions are legitimate.
- Test changes before enforcement. Run policy checks in CI or a non-production cluster against representative manifests and workloads. For Kyverno, use its CLI as part of the policy test workflow.
- Start with visibility. Where the selected control supports it, begin in audit or warning mode so teams can find violations before blocking API requests.
- Remediate and document exceptions. Fix workloads that can meet the baseline; give necessary exceptions an owner and a clear scope rather than weakening a cluster-wide policy.
- Enforce progressively. Move workloads or namespaces to enforcement after validation, then monitor admission failures so legitimate releases and system components are not unexpectedly blocked.
Segment pod traffic and validate the CNI configuration
Kubernetes pod-to-pod traffic is broadly allowed by default unless network controls restrict it. NetworkPolicy can set Layer 3 and Layer 4 boundaries, but EKS VPC CNI network-policy functionality is not enabled by default. It requires an eligible add-on version and configuration. Check the exact support and enablement steps for the cluster’s deployed VPC CNI and EKS version before relying on a policy; the existence of NetworkPolicy YAML alone does not prove that enforcement is active.
Rank #3
AWS recommends layering Kubernetes network policies with security groups for pods where AWS-level network controls are appropriate. A service mesh can add Layer 7 controls, mTLS, traffic management, or richer observability, but it brings operational overhead; native network policy may be enough for simpler segmentation. These layers can coexist, provided their responsibilities and interactions are understood.
- Write and review policies around required flows: ingress, egress, DNS, and communication with external services.
- Confirm the active network-policy engine and supported features in the actual cluster configuration.
- Avoid running multiple network-policy engines without a deliberate migration plan. Test converted policies in a separate cluster before a production switch because overlapping enforcement can behave unexpectedly.
Protect secrets and Terraform state
Kubernetes Secret values are Base64-encoded, not thereby made confidential. AWS Prescriptive Guidance warns that Base64 is insufficient to prevent unauthorized access to sensitive data. Choose a secret-management integration appropriate to the EKS compute model: AWS documents Secrets Manager with the Secrets Store CSI Driver and AWS Secrets and Configuration Provider (ASCP) for EC2-backed EKS, and External Secrets Operator patterns for Fargate. Confirm the integration’s current version and configuration before applying manifests or Terraform.
Terraform state is also sensitive: it can contain values used to configure infrastructure, including secrets. Restrict read access for both people and automation, use a secured remote backend with suitable encryption and locking controls, and avoid exposing secret values as outputs. The appropriate backend configuration depends on the backend in use; check its current official guidance rather than copying an unverified example.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Use Terraform as a controlled change workflow
Terraform can provision AWS infrastructure through an EKS module, while Kubernetes and Helm providers can manage resources inside the cluster. Treat the module and provider versions as security-relevant dependencies: pin reviewed versions rather than relying on an unbounded latest release, and review upgrades before adopting them. Compatibility depends on the EKS/Kubernetes version, module, and providers you select.
HashiCorp’s Kubernetes-provider EKS example describes separating EKS infrastructure and Kubernetes resources into different states or workspaces. This can limit the scope of a change and avoid provider initialization dependencies, but it is not a universal requirement. State boundaries should reflect team ownership, deployment sequencing, recovery needs, and how dependencies are handled.
| Terraform layout | Potential benefit | Trade-off to assess |
|---|---|---|
| One combined state | Infrastructure and in-cluster resources can be managed in one workflow. | A plan or apply may affect a wider set of resources; provider setup and dependencies need careful handling. |
| Separate infrastructure and Kubernetes states or workspaces | Can narrow change scope and separate infrastructure provisioning from in-cluster changes. | Requires deliberate sequencing, ownership, and dependency management across states. |
A practical change path is:
- Review source changes, module and provider pins, and the identities that can run the deployment pipeline.
- Run Terraform validation and inspect the plan before applying it; understand which resources and permissions will change.
- Test Kyverno policies or other admission manifests before deployment, including against exceptions and system workloads.
- Apply through an auditable pipeline using privileged deployment credentials only where required, then monitor infrastructure and Kubernetes API activity.
Terraform helps make infrastructure changes reviewable and repeatable; it does not guarantee that a plan is safe. Plans, state access, code review, deployment credentials, and post-change monitoring all remain part of the security boundary.
Build detection and response into the design
Preventive controls need a detection path. Enable and review Kubernetes API audit activity, watch for unexpected access or role changes, and monitor workload and infrastructure behavior. Maintain an incident process that lets responders identify affected identities, workloads, and network paths, then revoke or contain access without losing the evidence needed to understand the event. Image security, tenancy boundaries, encryption, compliance needs, and forensics belong in the same operating plan—not as substitutes for admission policy, but as complementary controls.
Version-check before implementation
EKS, Kubernetes, VPC CNI, Kyverno, Terraform modules, and provider capabilities change over time. AWS and HashiCorp documentation and Terraform Registry module releases are updated independently. Before deploying, verify that the selected Kubernetes and add-on versions support the controls you intend to use, that Pod Identity’s agent and SDK requirements fit your workloads, and that policy APIs match your Kyverno version. The guidance here reflects official documentation available on October 4, 2026; implementation details should be checked against the versions in your environment.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
