CIS EKS Benchmark Compliance Report: What It Covers and How We Produce It

Why a benchmark report is useful

Most EKS security problems are not clever exploits. They are default settings nobody reviewed: a public API endpoint open to the internet, control plane logs switched off, a cluster-admin binding given to a whole group, nodes allowing broad metadata access. A benchmark gives you a structured, neutral list of such issues.

This page describes the CIS-based assessment in our AWS EKS consulting service. It builds on the controls we implement elsewhere: pod security standards, network policies and secrets encryption.

What good looks like

• You know your configuration against a recognised baseline, with evidence.
• Failures are ranked by real risk in your environment.
• Exceptions are written down, owned and revisited.
• Fixes are made in code so they do not regress.
• The assessment can be repeated cheaply, ideally automatically.

What the benchmark covers

The CIS Amazon EKS Benchmark is organised into sections. The exact numbering and controls change between versions, so we confirm the version in scope, but the themes are stable:

Each recommendation is either scored (counts towards compliance) or not scored. Some can be checked automatically, others require judgement, which is why a tool-only scan is incomplete.

How we produce the report

Automated layer

kube-bench runs node checks as a Kubernetes job. On EKS the managed control plane is not accessible, so those items are validated through the AWS API and documentation instead. We typically complement it with Kubescape or Prowler for cluster and AWS account checks.

# run node-level CIS checks using the EKS-specific benchmark profile
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml
kubectl logs job/kube-bench > kube-bench-results.txt

# confirm control plane logging and endpoint exposure
aws eks describe-cluster --name platform-prod \
  --query 'cluster.{logging:logging,endpoint:resourcesVpcConfig.{public:endpointPublicAccess,private:endpointPrivateAccess,cidrs:publicAccessCidrs}}'

Check the manifest path and options against the kube-bench version you use, as they change.

Manual layer

Tools cannot judge intent. By hand we review:

• RBAC: cluster-admin bindings, wildcard verbs and resources, who can read secrets, and default service account use.
• IAM: node role breadth, pod-level roles and whether IRSA or Pod Identity is used.
• API access: endpoint exposure, authentication modes and who maps to which Kubernetes groups.
• Logging: control plane log types enabled and where they are retained.
• Images and registries: pull permissions, scanning and provenance.

Making findings useful

A long list of failures is demoralising. We rate each one by:

1. Exposure: is it reachable from the internet or only from inside?
2. Impact: what could an attacker do with it?
3. Effort: how hard is it to fix without disruption?
4. Context: does the control actually fit your workload?

A public API endpoint with an open CIDR range outranks a missing file permission on a node that no one can reach. The remediation plan groups fixes into a first set that removes the biggest exposure, then routine hardening, then low-value items you may choose to accept.

Mapping to frameworks

If you are pursuing SOC 2, ISO 27001, PCI DSS or a similar framework, we map findings to the technical controls your auditor asks about and provide evidence in a readable form. The mapping supports your audit but does not replace it, and we make no claim that this report alone proves compliance. For broader compliance support in operations, see managed DevOps security and compliance.

When a CIS report is not what you need

• If your risk is in the application layer, a penetration test or code review will tell you more.
• If you have a single hobby-scale cluster, a short hardening checklist may be enough.
• If you need formal certification, that requires an accredited auditor, which we are not.

We will say so during scoping.

Common failure modes

• Treating the score as the goal, applying fixes that break workloads.
• One-off scans that go stale within weeks. We put the checks in a scheduled job.
• Fixing in the console, so Terraform reverts the change on the next apply. We remediate in code, see Terraform modules and state.
• Ignoring exceptions, which then become permanent without review.

A worked example of ranking

Imagine a scan returns a long list of failures. Three of them illustrate how ranking changes the order of work. First, the API endpoint is public with no CIDR restriction. That is reachable from anywhere, so it goes to the top. Second, control plane audit logging is off. Nothing is exposed, but you would be blind during an incident, and the fix is a single setting, so it goes in the first batch. Third, a node file permission check fails on a managed node group that nobody can log in to. The effort to change it is high and the exposure is low, so it becomes a documented exception with a review date.

The same finding can rank differently across clusters. A public endpoint on a sandbox with no data is a lesser concern than the same setting on a production cluster that holds customer records. Context is the reason the report needs a human reviewer.

Keeping the baseline from drifting

A report is a snapshot, so we also leave behind a way to detect regression. The usual pattern is a scheduled kube-bench job whose output is shipped to your logging stack, plus AWS Config or Security Hub rules for the account-level settings. A policy engine such as Kyverno blocks new workloads that break the pod rules. When a check fails after a change, the owning team sees it in the same review flow as any other defect, instead of waiting for the next annual audit.

Delivery and handover

You receive an executive summary for leadership, detailed findings with evidence and benchmark references, a risk-ranked remediation plan, an exceptions register, and the scripts used so the scan can be repeated. We walk your engineers through it. If you want fixes made, we implement them and re-run the checks to show the improvement.

How to tell it is working

Re-run the same scan a quarter later: critical and high findings should stay at zero, exceptions should have owners, and new clusters should start compliant because the modules build in the controls. To scope an assessment, contact us.

References

• CIS Benchmarks, Center for Internet Security
• Best Practices for Security, Amazon EKS documentation