The CIS Kubernetes Benchmark provides 200+ controls for hardening cluster infrastructure. Understanding which controls matter most, how to assess them with kube-bench, and which hardening flags have operational consequences is the difference between a compliant cluster and a usable one.
Know the top 5 CIS controls and why they matter. Be able to run kube-bench and interpret its output. Understand that --anonymous-auth=true is a critical misconfiguration.
Write audit policies targeted at compliance requirements (SOC2, PCI, HIPAA). Implement hardening without breaking monitoring agents and existing workloads. Plan etcd TLS retrofit as a maintenance operation.
Define organizational CIS compliance targets and acceptable risk register. Automate kube-bench in CI/CD with defined thresholds. Own the cluster hardening runbook. Evaluate L2 controls against specific threat model rather than applying all controls indiscriminately.
The CIS Kubernetes Benchmark provides 200+ controls for hardening cluster infrastructure. Understanding which controls matter most, how to assess them with kube-bench, and which hardening flags have operational consequences is the difference between a compliant cluster and a usable one.
Cluster deployed with default API server settings -- anonymous auth enabled
WARNINGDashboard deployed with no network restrictions -- accessible externally
WARNINGSecurity scanner reveals unauthenticated API server and indexed Dashboard
CRITICALkube-bench run: cluster scores 23% CIS compliance -- 47 FAIL controls
CRITICALFull incident response triggered -- secrets rotated, cluster rebuilt
WARNINGRebuilt cluster scores 78% CIS compliance -- anonymous auth disabled, audit logging enabled
The question this raises
Which CIS Benchmark controls prevent the highest-consequence exposures, and how do you enforce them without breaking cluster operations?
You run kube-bench on a new production cluster and get 47 FAIL results across L1 and L2 controls. Your security team asks you to fix everything immediately. What is the right approach?
Lesson outline
CIS Kubernetes Benchmark: 5 control families
The Center for Internet Security publishes a Kubernetes Benchmark with 200+ controls across 5 families: Control Plane Configuration (API server, etcd, scheduler, controller manager), Worker Node Configuration (kubelet, config files), Policies (RBAC, PSA, network policies), Managed Services (cloud-specific controls for EKS/GKE/AKS). Controls are graded L1 (minimum security, no operational impact) and L2 (defense-in-depth, may have operational trade-offs).
Highest-impact CIS controls (L1 -- apply immediately)
Kubernetes security hardening layers:
Internet/Internal Users
|
v
[Network boundary] --> Restrict API server to VPC/private subnet
| Kubernetes Dashboard: never expose publicly
v
[API Server] --> --anonymous-auth=false
| --audit-log-path=/var/log/kubernetes/audit.log
| --audit-policy-file=/etc/kubernetes/audit-policy.yaml
| --tls-min-version=VersionTLS12
v
[Authorization] --> --authorization-mode=Node,RBAC (never AlwaysAllow)
| Least-privilege RBAC for all ServiceAccounts
v
[Admission] --> OPA/Gatekeeper or Kyverno policies
| Pod Security Standards enforcement
v
[etcd] --> --cert-file + --key-file (TLS)
| --peer-cert-file (peer TLS)
| Access restricted to API server only (firewall)
v
[Worker Nodes] --> kubelet --anonymous-auth=false
| kubelet --authorization-mode=Webhook
| AppArmor/seccomp profiles on pods
v
[Runtime] --> Pod Security Standards (Restricted profile)
Falco runtime detectionHow this concept changes your thinking
Setting up a new cluster for a production workload
“Deploy with kubeadm defaults, enable Dashboard for visibility, configure RBAC later when teams are onboarded.”
“Run kube-bench immediately after cluster creation. Fix all L1 failures before any workload deployment. Dashboard: deploy with RBAC authentication and no external exposure from day one.”
Enabling audit logging on a production cluster
“Audit logging will flood disk space and slow the API server -- we will enable it before the next audit.”
“A targeted audit policy (log Secrets reads, privileged pod creations, RBAC changes) adds <5% API server overhead. Without audit logs, you have no breach detection. Enable at cluster creation with log rotation and ship to a SIEM.”
CIS hardening assessment and remediation workflow
01
Run kube-bench as a Job in the cluster to assess all control plane and worker node controls: kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
02
Review FAIL results by section. Prioritize L1 controls first -- these are minimum security with no operational trade-offs.
03
For API server controls: modify the kube-apiserver static pod manifest at /etc/kubernetes/manifests/kube-apiserver.yaml. kubelet will automatically restart the pod. Controls: --anonymous-auth=false, --audit-log-path, --profiling=false.
04
For kubelet controls: modify kubelet config at /var/lib/kubelet/config.yaml or /etc/kubernetes/kubelet.conf. Restart kubelet service. Controls: anonymous.enabled: false, authorization.mode: Webhook.
05
For etcd controls: etcd peer and client TLS is configured at cluster creation. Retrofitting TLS on a running cluster requires etcd restart -- plan a maintenance window.
06
Run kube-bench again after changes to confirm PASS. Target 80%+ L1 compliance before any production workload.
07
Integrate kube-bench into CI/CD as a gate: run on every node image build to catch regressions before they reach production.
Run kube-bench as a Job in the cluster to assess all control plane and worker node controls: kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
Review FAIL results by section. Prioritize L1 controls first -- these are minimum security with no operational trade-offs.
For API server controls: modify the kube-apiserver static pod manifest at /etc/kubernetes/manifests/kube-apiserver.yaml. kubelet will automatically restart the pod. Controls: --anonymous-auth=false, --audit-log-path, --profiling=false.
For kubelet controls: modify kubelet config at /var/lib/kubelet/config.yaml or /etc/kubernetes/kubelet.conf. Restart kubelet service. Controls: anonymous.enabled: false, authorization.mode: Webhook.
For etcd controls: etcd peer and client TLS is configured at cluster creation. Retrofitting TLS on a running cluster requires etcd restart -- plan a maintenance window.
Run kube-bench again after changes to confirm PASS. Target 80%+ L1 compliance before any production workload.
Integrate kube-bench into CI/CD as a gate: run on every node image build to catch regressions before they reach production.
1# Targeted audit policy -- log high-value events without flooding disk2apiVersion: audit.k8s.io/v13kind: Policy4rules:Metadata level logs who accessed what -- not the response body. Lower overhead than RequestResponse.5# Log all Secret reads (credential access detection)6- level: Metadata7resources:8- group: ""9resources: ["secrets"]10verbs: ["get", "list", "watch"]11# Log RBAC changes (privilege escalation detection)RBAC changes at RequestResponse level to catch privilege escalation attempts with full detail13- level: RequestResponse14resources:15- group: "rbac.authorization.k8s.io"16resources: ["roles", "clusterroles", "rolebindings", "clusterrolebindings"]17# Log privileged pod creations19- level: Request20resources:21- group: ""22resources: ["pods"]23verbs: ["create"]24# Skip noisy read-only API calls26- level: None27verbs: ["get", "list", "watch"]28resources:29- group: ""30resources: ["endpoints", "services", "configmaps"]31# Default: log metadata for everything else33- level: Metadata
Blast radius: what hardening controls can break
Test L2 controls in staging before production
L1 CIS controls are safe to apply without testing. L2 controls (encryption at rest for all data, read-only root filesystem requirement, restricting service account tokens globally) have operational side effects. Always test L2 controls in staging first, with a representative sample of your production workloads.
CIS Benchmark prioritization
| CIS Control | Risk if skipped | Operational cost to implement |
|---|---|---|
| --anonymous-auth=false | Full unauthenticated API enumeration | Low -- one flag, no operational impact |
| Audit logging | Zero breach detection, compliance failure | Medium -- audit policy design, log storage, SIEM integration |
| etcd TLS | All cluster state readable on internal network | High -- requires maintenance window for retrofit |
| Kubelet auth | Node-level pod exec/log access without auth | Medium -- breaks unauthenticated monitoring agents |
| Pod Security Restricted | Privilege escalation via root containers | High -- breaks root-running Helm charts, requires app changes |
| Secrets encryption at rest | etcd backup readable without key | Low for new clusters, medium for retrofit (key management) |
CIS Benchmark assessment
📖 What the exam expects
The CIS Kubernetes Benchmark provides prescriptive security recommendations. kube-bench is an open-source tool that checks cluster configuration against CIS controls and reports PASS/FAIL/WARN.
Toggle between what certifications teach and what production actually requires
Asked in security-focused platform interviews: "How would you harden a new Kubernetes cluster?" Also in post-mortem debrief style questions about cluster exposures.
Common questions:
Strong answer: Candidates who have written audit policies for specific compliance frameworks, who have retrofitted hardening controls on running clusters, who can articulate the operational impact of each control category.
Red flags: Candidates who have never run kube-bench. Anyone who thinks 100% CIS compliance is the goal without understanding operational trade-offs. Not knowing that anonymous auth defaults to true.
Related concepts
Explore topics that connect to this one.
Ready to see how this works in the cloud?
Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.
View role-based pathsSign in to track your progress and mark lessons complete.
Questions? Discuss in the community or start a thread below.
Join DiscordSign in to start or join a thread.