How do you know if your Kubernetes cluster is actually secure, or just feels secure because it's running? This chapter solves that exact problem by teaching you to use a standardised security checklist — the CIS Benchmarks — and then run a formal security audit to catch every misconfiguration before an attacker does.
Jump to a section
A simple way to picture System Hardening: CIS Benchmarks and Auditing
A building gets constructed with all the latest wiring and fire-resistant materials, but that alone doesn't make it safe. This initial construction is like setting up a Kubernetes cluster with default settings — it might work, but it hasn't been proven secure yet.
To prove the building is safe for occupancy, a fire safety inspector arrives with a detailed checklist. This checklist is the CIS Benchmark for buildings. It lists every required safety feature: smoke detectors in every corridor, fire extinguishers on each floor, clearly marked emergency exits, and sprinkler systems that activate within a certain time. The inspector doesn't guess or rely on opinions. They methodically walk through every room, open every cupboard, and test every alarm. They check that fire doors close properly and that emergency lighting works during a power cut. If a door is blocked by furniture, that's a failure. If a fire extinguisher is past its expiry date, that's a failure. The inspector produces a written report documenting every pass and every fail.
This entire process — the standardised checklist (CIS Benchmark) and the methodical inspection (auditing) — forces the building owner to fix problems before they cause harm. Without it, a blocked fire exit goes unnoticed until there is a real fire. In Kubernetes, the CIS Benchmark is the checklist of secure configurations for the control plane, worker nodes, and etcd. The audit is the process of scanning your cluster against that checklist to find misconfigurations before an attacker does.
Kubernetes is a powerful system for running containerised applications, but its default settings are often insecure for production use. The Center for Internet Security (CIS) publishes a set of best-practice guidelines called the CIS Benchmarks for Kubernetes. These are detailed, step-by-step instructions for hardening your cluster against common attacks. Think of the CIS Benchmark as the official recipe for a secure Kubernetes setup. It covers things like who can access the API server, how secrets are stored, and whether the kubelet (the agent that runs on each worker node) enforces strong authentication.
A security audit is the process of checking your actual cluster against that benchmark. It answers the question: 'Does my configuration match what the CIS Benchmark says it should be?' The audit can be performed manually by a human running commands, or automatically using tools like kube-bench, which is an open-source tool designed specifically for this purpose.
Why does this matter? Because a misconfigured Kubernetes cluster is a wide-open door for attackers. Common default vulnerabilities include the API server being accessible without authentication, the etcd database (which stores all cluster secrets) being unencrypted, and containers running with root privileges that can escape to the host machine. Applying CIS benchmarks closes these doors. Auditing ensures you haven't missed any.
Here are the key areas the CIS Benchmark for Kubernetes addresses:
API Server configuration: requires TLS encryption, disables anonymous authentication, enables authorisation modes like RBAC (Role-Based Access Control)
etcd (the cluster's key-value store): must use TLS certificates for all communication, and should have strict access controls
Kubelet configuration: must authenticate requests from the API server, must not allow anonymous requests, and must protect itself with TLS
Worker node configuration: ensures the container runtime is securely configured, that unnecessary services are disabled, and that the host operating system is patched
Control Plane components: such as the Controller Manager and Scheduler, must run with secure flags and not bind to insecure ports
The audit process works like this: you run kube-bench on your master node and each worker node. The tool compares your current configuration against the CIS Benchmark rules and produces a report. The report shows which checks passed, which failed, and which were marked as 'info' (indicating you should review them manually). Each failed check has a severity level and a recommended remediation. You then fix the failures by modifying configuration files, setting secure flags, or applying patches. After fixing, you run the audit again to confirm the fixes worked.
A common example of a failed check is 'Ensure that the --insecure-port argument is set to 0' on the API server. The default configuration often leaves this port open, which allows unencrypted, unauthenticated access to the entire cluster. The CIS Benchmark says this is a critical failure. The remediation is to edit the kube-apiserver.yaml file on the master node and set --insecure-port=0. After you save the change, the kubelet automatically restarts the API server with the new setting. Running kube-bench again will then show this check as passed.
Audits must be repeated regularly because configurations can drift over time. A developer might manually change a setting to debug something, then forget to revert it. A new node added to the cluster might not have the same hardening applied. Continuous automated auditing, often integrated into CI/CD pipelines, ensures the cluster remains compliant even as changes happen.
Install kube-bench
Download the kube-bench binary from the official GitHub release page, make it executable, and place it in a directory included in your PATH (e.g., /usr/local/bin). Alternatively, you can run it as a container. This tool automates the audit against the CIS Benchmark.
Run audit on master node
Execute 'kube-bench run --targets master' with appropriate privileges (usually root or sudo). This scans the API server, Controller Manager, Scheduler, and etcd configurations on the control plane node. Save the output to a file for later analysis.
Run audit on worker nodes
Execute 'kube-bench run --targets node' on each worker node. This checks the kubelet configuration, container runtime settings, and host-level security controls. Worker nodes have different checks from the master node.
Analyse the audit report
Open the output file and focus on items marked 'FAIL' with high severity. Each failed entry includes a description of the issue, its severity level, and a recommended remediation step. Ignore 'WARN' items initially — they need manual investigation but not immediate action.
Remediate critical failures
Apply the recommended fix for each failed check. Common actions include editing the kube-apiserver.yaml manifest file to add secure flags, changing file permissions with chmod, or altering ownership with chown. After each change, re-run the specific kube-bench test to confirm the fix.
Document and automate
Save the final clean audit report as evidence for compliance audits. Schedule automated kube-bench runs using a cron job or CI/CD pipeline to run nightly. Send results to a central logging system so failed checks are caught early.
You are a platform engineer at a fintech company called PayFlow. The company processes credit card transactions and must comply with PCI DSS and SOC 2 security standards. You have a production Kubernetes cluster running 50 microservices that handle transaction data. The CTO receives a notification from the compliance team: the external auditor is arriving in two weeks, and they will require proof that the Kubernetes cluster is hardened according to industry standards.
Your first step is to install kube-bench on a jump host that has kubectl access to the cluster. You download the latest version of the CIS Benchmark for Kubernetes, which is version 1.9.0 aligned with Kubernetes 1.31. You run the master node check with the command: kube-bench run --targets master. The tool scans the API server, Controller Manager, Scheduler, and etcd configurations. It produces a JSON report. You pipe this to a file and open it.
You see 47 failed checks. The most critical is 'Ensure that the etcd data directory is owned by etcd:etcd' — this is failed because a recent node reboot changed the ownership. Another critical failure is 'Ensure that the kubelet configuration file has permissions set to 600 or more restrictive' — it's currently 644, meaning any user on the node can read it. There are also five failed checks about the API server not using a strong cipher suite.
You create an action plan. You fix the etcd ownership with a chown command on the master node. You change the kubelet config file permissions with chmod 600. You update the API server's startup flags to specify tls-cipher-suites. For each change, you run the specific kube-bench test again to confirm it passes. You generate a final report and upload it to the company's compliance portal.
The auditor arrives. They ask for the report. You show them the clean report with zero critical failures. They also ask for evidence that the audit is run regularly. You show them a scheduled cron job that runs kube-bench every night at 2 AM and sends the results to a central logging dashboard. They are satisfied. The company passes the audit.
Without this process, the cluster would have had major security holes. The etcd misconfiguration would have allowed any process on the node to read the entire cluster's secrets, including database passwords and API keys. The insecure kubelet configuration would have allowed an attacker to pull container images with malicious code. The audit process turned invisible risks into visible, fixable items.
The CKS exam tests your ability to apply CIS Benchmarks and conduct security audits in a hands-on environment. You are placed in a terminal with a Kubernetes cluster that may be deliberately misconfigured. Your task is to identify the misconfigurations and fix them to match the CIS Benchmark.
Here are the specific exam topics related to this chapter:
Running kube-bench on master and worker nodes: you will be asked to run kube-bench and interpret its output. Expect a scenario where the tool is not installed, and you have to install it from a tar.gz file. Know the default binary location and how to run it with the '--targets' flag to specify master or node.
Fixing specific CIS check failures: the exam will present a failed check, such as 'File permissions for kubelet config are not 600' or 'etcd directory ownership is not etcd:etcd'. You must use chmod, chown, or edit the relevant YAML configuration files to fix them.
Understanding the difference between 'FAIL' and 'WARN' in kube-bench output: 'FAIL' means the check explicitly does not match the benchmark. 'WARN' means the tool cannot determine the status (often because the component is not running). You must know that 'WARN' is not necessarily a vulnerability but requires manual investigation.
API server insecure port: the exam loves to test this. You must know that the flag '--insecure-port=0' disables the insecure port. You will be asked to edit the kube-apiserver.yaml file in /etc/kubernetes/manifests/ to add this flag.
etcd encryption: the CIS Benchmark requires that etcd stores secrets encrypted at rest. You will need to check if encryption is enabled using the command 'kubectl get apiserver -n kube-system' or by inspecting the kube-apiserver.yaml for the '--encryption-provider-config' flag. If missing, you must create an encryption configuration file and modify the API server manifest.
Kubelet anonymous authentication: you must set '--anonymous-auth=false' in the kubelet config file to prevent unauthenticated requests.
Common traps: the exam may present a node where kube-bench is not installed and you must download it from a given URL. Another trap is asking you to perform an audit but providing a kubeconfig file with limited permissions — you must use the correct kubeconfig or direct node access (ssh) to run the tool.
Key definitions to memorise:
CIS Benchmark: a published set of security configuration guidelines for a specific technology.
kube-bench: the open-source tool that checks a Kubernetes cluster against the CIS Benchmark.
etcd: the key-value store that holds all cluster data, including secrets.
Kubelet: the agent on each worker node that communicates with the control plane.
Remediation: the specific change required to fix a failed check.
The CIS Benchmark for Kubernetes is a published checklist of secure configuration settings for the control plane, worker nodes, and etcd.
kube-bench is the standard open-source tool for automatically auditing a Kubernetes cluster against the CIS Benchmark.
Common CIS failures include insecure API server ports, missing etcd encryption, and lax kubelet permissions.
Audits must be repeated regularly because cluster configurations drift over time due to manual changes and node scaling.
A 'FAIL' in kube-bench means the check explicitly does not match the benchmark; a 'WARN' means the status could not be determined and requires manual investigation.
Fixing CIS failures typically involves editing configuration files in /etc/kubernetes/manifests/ or changing file permissions with chmod and chown.
Passing all CIS Benchmark checks is necessary for baseline security but does not protect against application-level or supply chain attacks.
The CKS exam tests hands-on ability to run kube-bench, interpret its output, and apply remediations directly in a terminal environment.
These come up on the exam all the time. Here's how to tell them apart.
CIS Benchmark
A written document of security rules and best practices.
Published by the Center for Internet Security (CIS).
Does not run automatically; humans read it to understand what to check.
kube-bench
An open-source tool that automatically checks a cluster against the CIS Benchmark.
Developed and maintained by Aqua Security.
Runs commands on nodes and produces a report of passed/failed checks.
FAIL (kube-bench)
The configuration is explicitly found to be insecure and does not match the CIS rule.
Requires immediate remediation to fix the security hole.
The tool can definitively confirm the misconfiguration.
WARN (kube-bench)
The tool could not determine the status of the check (e.g., component not running or config file missing).
Does not automatically mean a vulnerability; requires manual investigation.
Often occurs because the audit ran on a node where that component is not installed.
Master Node Audit
Checks the API server, Controller Manager, Scheduler, and etcd configurations.
Focuses on control plane components that manage cluster state.
Uses the '--targets master' flag in kube-bench.
Worker Node Audit
Checks the kubelet, container runtime (e.g., containerd), and host-level settings.
Focuses on components that run workloads.
Uses the '--targets node' flag in kube-bench.
Remediation
A specific action to fix a failed CIS check, such as editing a YAML file or changing file permissions.
Has a clear 'before and after' state that can be verified by re-running kube-bench.
Typically involves commands like chmod, chown, or editing kube-apiserver.yaml.
Manual Investigation
Required for 'WARN' items where the cause is unclear.
May involve checking logs, verifying file paths, or confirming that a component is supposed to be absent.
Does not always result in a configuration change; sometimes the 'WARN' is benign.
Mistake
Running kube-bench once is enough to secure the cluster permanently.
Correct
Configurations drift over time due to manual changes, node updates, and scaling events. Audits must be run regularly, ideally automated via cron jobs or CI/CD pipelines.
Beginners often think security is a one-off task because they don't yet understand operational complexity of a live cluster.
Mistake
If kube-bench passes all checks, the cluster is completely secure.
Correct
CIS Benchmarks cover only baseline security configurations. They do not protect against advanced threats like application-level attacks, supply chain vulnerabilities in container images, or insider threats. Passing CIS is necessary but not sufficient for full security.
The name 'CIS Benchmark' sounds comprehensive, but it is specifically a configuration baseline, not a full threat model.
Mistake
A 'WARN' result from kube-bench is the same as a 'FAIL' and must be fixed immediately.
Correct
'WARN' means the tool could not determine the status, often because the component wasn't running or the configuration file was in an unexpected location. It requires manual investigation, but it is not automatically a security vulnerability.
Learners panic when they see red warnings and treat them as failures, because typical logging tools condition them to treat warnings as critical.
Mistake
All CIS Benchmark checks can be applied without breaking the cluster.
Correct
Some checks, like setting '--anonymous-auth=false' on the API server, can break monitoring tools or components that rely on anonymous probes. You must test changes in a staging environment first.
The textbook nature of benchmarks makes them seem like safe, universal recommendations, but real-world environments have unique dependencies.
Mistake
kube-bench needs to be run from the master node only.
Correct
It must be run on both master and worker nodes separately using the '--targets' flag: '--targets=master' for control plane nodes and '--targets=node' for worker nodes. The checks differ per node type.
The architecture of Kubernetes is often misunderstood by beginners who think the master node controls everything, but the worker nodes have their own kubelet and container runtime configurations to audit.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
It is a detailed checklist of security best practices published by the Center for Internet Security (CIS) specifically for hardening Kubernetes clusters. It covers configurations for the API server, etcd, kubelet, and other components.
Yes, you must manually apply the recommended remediation for each 'FAIL' check. The tool only identifies problems; it does not automatically fix them. Typical fixes involve editing YAML manifests or changing file permissions on the node.
No, kube-bench must be run directly on the node being audited (master or worker) because it reads local configuration files and processes. You can SSH into each node to run it.
kubectl is used to interact with the Kubernetes API to manage resources (pods, deployments, etc.). kube-bench is a security auditing tool that runs on the node itself and checks configuration files, not live API objects.
Ideally nightly via a scheduled cron job, or at least after every configuration change, node addition, or Kubernetes version upgrade. Configurations can drift quickly in dynamic environments.
Some checks can break existing functionality, for example disabling anonymous authentication can affect monitoring tools that use anonymous probes. Always test in a staging environment before applying to production.
You've finished System Hardening: CIS Benchmarks and Auditing. Continue through the CKS study guide to build a complete picture of the exam.
Done with this chapter?