When a Kubernetes cluster gets breached, the root cause is rarely a zero-day. It's usually a misconfiguration that's been sitting in plain sight: an anonymous-auth flag left enabled on the API server, a kubelet port exposed without authentication, or an etcd datastore reachable without TLS. The CIS Kubernetes Benchmark exists to catch exactly these issues — it's a free, community-vetted checklist of over 100 configuration recommendations, maintained by the Center for Internet Security and now in its 1.9.0 revision covering Kubernetes 1.27 and 1.28. Aqua Security built the most widely used tool for running it, kube-bench, and open-sourced it back in 2017. This post breaks down what the benchmark actually checks, why certain controls fail more than others, how Aqua's approach compares to a modern supply-chain-aware alternative, and where Safeguard fits into a real hardening program.
What Is the Kubernetes CIS Benchmark?
The CIS Kubernetes Benchmark is a vendor-neutral configuration standard, published by the Center for Internet Security, that scores a cluster against roughly 100-120 individual controls (the exact count shifts slightly by version) spread across five sections: Control Plane Components, etcd, Control Plane Configuration, Worker Nodes, and Policies. Each control maps to a specific, checkable setting — for example, control 1.2.20 checks whether --profiling is disabled on the API server, and 4.2.6 checks that the kubelet's --protect-kernel-defaults flag is set. Controls are tagged Level 1 (essential, low operational impact) or Level 2 (stricter, may affect functionality), which lets teams triage what to fix first. The benchmark isn't Kubernetes-distribution-specific in its base form, but CIS also publishes tailored versions for EKS, GKE, and AKS because managed control planes hide certain settings from the customer entirely. It complements, rather than replaces, the NSA/CISA Kubernetes Hardening Guide (updated March 2022), which focuses more on architecture-level guidance like network segmentation and admission control.
Why Do Failures Cluster Around the API Server and etcd?
Because those two components hold the actual keys to the cluster, and a single missed flag on either one can grant cluster-wide access. The API server section alone contains more than 20 controls, covering things like disabling anonymous authentication (--anonymous-auth=false), enforcing Node,RBAC authorization modes, and disabling the deprecated AlwaysAllow authorization mode. etcd, meanwhile, stores every Secret, ConfigMap, and object definition in the cluster — often in plaintext unless encryption-at-rest is explicitly configured. In 2018, Tesla's cloud infrastructure was compromised via a Kubernetes dashboard left without authentication, giving attackers direct API server access and letting them run a cryptomining operation inside the cluster; that single exposed credential path is exactly what CIS controls 1.2.1 through 1.2.5 (API server authentication and authorization settings) are designed to prevent. Auditors and scanning vendors consistently report that API server and etcd controls make up a disproportionate share of failed checks in first-time scans, largely because these components are provisioned once at cluster-build time and rarely revisited.
How Is CIS Benchmark Scanning Different From Runtime Kubernetes Security?
CIS benchmarking is a point-in-time configuration audit, while runtime security is continuous behavioral monitoring — and confusing the two is one of the most common gaps in Kubernetes security programs. A CIS scan, run via a tool like kube-bench, reads static configuration (kubelet flags, file permissions on /etc/kubernetes/pki, API server arguments) and produces a pass/fail report against the benchmark's ~100+ checks. It tells you nothing about what's happening inside a running pod: a container making an unexpected outbound connection, a process escalating privileges, or a workload pulling an image with a known-malicious layer. A cluster can pass every Level 1 CIS control and still get compromised through a vulnerable application dependency or a poisoned container image — the benchmark simply wasn't designed to catch that class of risk. This is why CIS compliance is typically treated as a baseline hygiene gate (often required for SOC 2 or FedRAMP evidence) rather than a complete security program on its own.
How Does Aqua Security Approach CIS Kubernetes Benchmarking?
Aqua Security's approach centers on kube-bench, the open-source Go tool it released in 2017 that remains the de facto reference implementation for running the CIS benchmark against a live cluster. kube-bench ships with YAML test definitions mapped to each CIS control version (1.23, 1.24, up through 1.9.0), auto-detects the cluster's Kubernetes version, and outputs a pass/fail/warn report per control — it's genuinely useful and widely embedded in CI pipelines. Aqua then layers its commercial Cloud Native Application Protection Platform (CNAPP) on top, adding Kubernetes Security Posture Management (KSPM), image scanning, and runtime enforcement under one console. The tradeoff many teams report is that Aqua's platform-level pricing and packaging assumes you're consolidating most of your cloud-native security stack under Aqua, which can mean paying for a broad surface — CSPM, CWPP, image scanning, CIS benchmarking — even when a team specifically needs strong software supply chain coverage (SBOM generation, provenance verification, dependency risk) rather than another general infrastructure posture tool.
What Are the Most Commonly Failed CIS Kubernetes Controls?
The most commonly failed controls tend to involve default settings that vendors leave permissive for compatibility reasons rather than security. Across independent scan reports, the repeat offenders include: --anonymous-auth left at its default of true on kubelets (control 4.2.1), missing --audit-log-path configuration on the API server (control 1.2.22), service account tokens auto-mounted into pods that don't need API access (control 5.1.5), and etcd client connections without TLS mutual authentication (control 2.2). On managed services like EKS and GKE, several control-plane checks simply can't be remediated by the customer at all because the cloud provider owns that layer — which is why CIS publishes separate benchmark profiles for each managed offering rather than forcing a one-size-fits-all scorecard. Worker node and Policies sections also see high failure rates around Pod Security Standards enforcement, since many clusters migrated off the deprecated PodSecurityPolicy (removed in Kubernetes 1.25, released August 2022) without adopting a replacement admission controller.
How Often Should You Run a Kubernetes CIS Benchmark Scan?
CIS benchmark scans should run on every cluster change, not on a quarterly calendar, because a single kubeadm upgrade or Helm chart update can silently flip a hardened flag back to its insecure default. In practice this means wiring kube-bench or an equivalent scanner into the CI/CD pipeline that provisions or upgrades cluster infrastructure, plus a scheduled daily or weekly scan of production clusters to catch drift introduced by manual kubectl changes or third-party operators that modify control-plane settings. Organizations pursuing SOC 2 Type II or FedRAMP authorization typically need to show continuous evidence of this control, not a single snapshot — auditors increasingly ask for scan history and remediation timestamps, not just a clean report on the day of the audit. Treating CIS scanning as a one-time hardening exercise at cluster launch is the single most common reason clusters drift out of compliance within a few months.
How Safeguard Helps
Safeguard treats the CIS Kubernetes Benchmark as one input into a broader software supply chain risk picture, not a standalone checkbox. Instead of running an isolated configuration scan that hands you 100+ pass/fail rows with no sense of priority, Safeguard correlates CIS control failures against what's actually running in the cluster — which images have known-exploitable CVEs, which workloads have internet-exposed ingress, and which service accounts hold excessive RBAC permissions — so a failed control on a pod handling untrusted external traffic is flagged well above the same failure on an isolated internal batch job. Safeguard continuously re-scans clusters on every deployment rather than on a fixed schedule, closing the drift gap that quarterly or manual audits leave open, and generates the timestamped, control-by-control evidence that SOC 2 and FedRAMP auditors ask for without requiring a team to stitch together reports from multiple tools. For teams evaluating alternatives to Aqua's bundled CNAPP, Safeguard's differentiation is depth on the supply chain side: SBOM generation, dependency and image provenance verification, and CVE exploitability scoring sit natively alongside CIS and Kubernetes posture checks, rather than being sold as a separate module. The result is a single view where a misconfigured kubelet flag, a vulnerable base image, and an unsigned artifact in the deploy pipeline all show up as connected risk — not three disconnected dashboards a security team has to reconcile by hand.