CIS Kubernetes Benchmark
The CIS Kubernetes Benchmark is a hardening checklist (around 120 controls, varying by Kubernetes version) published and maintained by the Center for Internet Security. It is the widely adopted Kubernetes security standard and the default evidence most audit frameworks expect. Controls cover the control plane (kube-apiserver, etcd, controller manager, scheduler), worker nodes (kubelet, container runtime), policies (RBAC, Pod Security, Network), and workload defaults. Separate benchmarks exist for managed distributions: CIS EKS, CIS GKE, CIS AKS, CIS OpenShift.
What CIS Kubernetes covers
- Control plane components. API server flags (anonymous auth, audit logging, TLS ciphers), etcd (peer auth, client cert, encryption at rest), controller manager, scheduler.
- Worker node security. kubelet configuration, service account file permissions, runtime isolation.
- Policies. RBAC hygiene, default service accounts, Pod Security Standards, NetworkPolicies, Secrets management.
- Managed service variants. CIS EKS, GKE, and AKS drop control-plane controls that are not configurable on managed services and focus on what a customer can control.
Scoring: Level 1 and Level 2
Level 1: foundational controls with low operational friction. The sensible starting target.
Level 2: deeper hardening, sometimes at the cost of developer ergonomics or compatibility.
Most organizations target Level 1 compliance across the board and Level 2 for specific high-security environments. Failing a Level 1 control is the kind of finding auditors care about.
Managed cluster considerations
EKS, GKE, and AKS do not expose the control plane for inspection or modification. The cloud provider manages it. CIS Benchmark versions for managed services skip those controls and focus on what customers configure: worker nodes, workloads, RBAC, network.
Use CIS EKS on EKS, CIS GKE on GKE, CIS AKS on AKS. Running the plain CIS Kubernetes Benchmark against a managed cluster will report false failures for controls the customer cannot touch.
Getting to a passing state
- Enable Pod Security Standards admission. Label namespaces
pod-security.kubernetes.io/enforce=baseline. This handles a significant block of workload-level checks. - Default-deny NetworkPolicy in every namespace. Covers multiple network-related controls.
- Audit logging enabled and shipped. Required for most of the AU-category controls.
- Disable anonymous API access.
--anonymous-auth=false. - Encrypt secrets at rest. Configure EncryptionConfiguration on the API server.
- Remove default service account token automount from pods that do not need it.
Frequently asked about cis kubernetes benchmark
How often does CIS update the Kubernetes Benchmark?
Roughly every 6 to 12 months, tracking major Kubernetes releases. Check CIS directly for the version matching your cluster version. Controls can change between revisions.
Can I mark controls "not applicable"?
Yes, with rationale. Many teams mark control-plane controls N/A on managed clusters. Good KSPM tools support suppression with notes and expiry dates. Auditors expect this but want to see the reasoning.
Is full CIS compliance realistic?
Reaching the high 90s is realistic. A full 100% often conflicts with operational needs. Disabling service account automount everywhere can break workloads that legitimately need API access. Aim high, document exceptions, monitor drift.
Does CIS cover container image security?
Lightly. The focus is cluster configuration rather than image CVEs. For image-level security, pair CIS with SBOM-based vulnerability scanning and NIST SP 800-190.
Can CIS compliance be continuous rather than point-in-time?
With a KSPM tool, yes. Juliet re-evaluates CIS controls on every cluster state change. That is the difference between a passing audit today and a passing audit a month from now after six namespaces have been added.
See this in your clusters
Juliet maps your Kubernetes security posture as a graph and ranks findings by reachable attack paths, not just CVSS. Free tier, five-minute setup, no credit card.