Securing Kubernetes Infrastructure: A Masterclass in Remediating CIS Benchmark Findings with Kube-bench for the CKS Certification

As organizations increasingly migrate critical workloads to containerized environments, securing the underlying orchestration platform has become an operational imperative. In the cloud-native ecosystem, misconfigurations represent one of the single greatest vectors for compromise. To mitigate these risks, security engineers and Kubernetes administrators turn to the Center for Internet Security (CIS) Benchmarks as the gold standard for hardening production clusters.

For candidates preparing for the rigorous Certified Kubernetes Security Specialist (CKS) examination, mastering the identification and remediation of compliance failures is non-negotiable. This comprehensive walkthrough explores a practical, live-cluster scenario demonstrating how to use kube-bench—an industry-standard open-source tool—to pinpoint vulnerabilities across control plane and worker nodes, interpret the underlying risks, and implement robust remediation strategies.

Main Facts: The Anatomy of a CIS Benchmark Audit

The CIS Kubernetes Benchmark provides prescriptive guidance for establishing a secure configuration posture for Kubernetes deployments. In production environments, running an automated auditor like kube-bench allows operators to assess their clusters against dozens of security controls in seconds.

Core Concepts of Kube-Bench

Target-Based Auditing: kube-bench evaluates node configurations based on specific execution contexts using the --targets flag (master for control plane components and node for kubelet and proxy configurations).
Actionable Remediations: Every failed check ([FAIL]) yields a precise technical remediation, often identifying the exact file path, parameter name, and expected value required to achieve compliance.
Granular Verification: Using the --check flag allows administrators to isolate specific benchmark item numbers (e.g., 1.4.1 or 4.2.1), streamlining the validation loop after applying modifications.

In our live two-node scenario utilizing the CIS v1.12 benchmark profile, initial audits reveal predictable out-of-the-box security gaps in standard distributions. The objective: isolate and fix three specific findings—scheduler profiling on the control plane, insecure kubelet configuration file permissions on the worker node, and enabled anonymous authentication on the kubelet API—while leaving unrelated components untouched to avoid unintended cluster instability.

Chronology: Step-by-Step Remediation Workflow

Securing a live Kubernetes cluster requires a disciplined, repeatable methodology: assess, read, remediate, restart, and re-verify.

Phase 1: Control Plane Audit and Scheduler Hardening

Beginning on the control plane node, the security engineer executes kube-bench targeting the master components to establish a baseline of security posture deficiencies.

$ ssh cks-scenario5-control-plane
$ kube-bench run --benchmark cis-1.12 --targets master | grep '^[FAIL]'
[FAIL] 1.1.12 Ensure that the etcd data directory ownership is set to etcd:etcd (Automated)
[FAIL] 1.2.5 Ensure that the --kubelet-certificate-authority argument is set as appropriate
[FAIL] 1.2.15 Ensure that the --profiling argument is set to false (Automated)
[FAIL] 1.2.16 Ensure that the --audit-log-path argument is set (Automated)
[FAIL] 1.2.17 Ensure that the --audit-log-maxage argument is set to 30 or as appropriate
[FAIL] 1.2.18 Ensure that the --audit-log-maxbackup argument is set to 10 or as appropriate
[FAIL] 1.2.19 Ensure that the --audit-log-maxsize argument is set to 100 or as appropriate
[FAIL] 1.2.30 Ensure that the --service-account-extend-token-expiration parameter is set to...
[FAIL] 1.3.2 Ensure that the --profiling argument is set to false (Automated)
[FAIL] 1.4.1 Ensure that the --profiling argument is set to false (Automated)

Rather than attempting to remediate every finding—which risks introducing syntax errors or breaking cluster dependencies—the administrator narrows focus to task requirement 1.4.1 (scheduler profiling).

$ kube-bench run --benchmark cis-1.12 --targets master --check 1.4.1
[FAIL] 1.4.1 Ensure that the --profiling argument is set to false (Automated)

== Remediations master ==
1.4.1 Edit the Scheduler pod specification file /etc/kubernetes/manifests/kube-scheduler.yaml file
on the control plane node and set the below parameter.
--profiling=false

To remediate, the administrator updates the static pod manifest located in /etc/kubernetes/manifests/kube-scheduler.yaml, adding the required flag to the command argument list.

    - kube-scheduler
    - --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
    - --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
    - --bind-address=127.0.0.1
    - --kubeconfig=/etc/kubernetes/scheduler.conf
    - --leader-elect=true
    - --profiling=false
    image: registry.k8s.io/kube-scheduler:v1.37.0

Because static pods are continuously monitored by the local kubelet, modifying the manifest file automatically triggers an graceful termination and restart of the kubescheduler component. Re-running the targeted check confirms the resolution:

$ kube-bench run --benchmark cis-1.12 --targets master --check 1.4.1 | grep '^\['
[PASS] 1.4.1 Ensure that the --profiling argument is set to false (Automated)

Phase 2: Worker Node Hardening and Kubelet Security

Shifting focus to the worker node, the administrator runs kube-bench with the node target to evaluate kubelet configurations and file system protections.

$ ssh cks-scenario5-worker
$ kube-bench run --benchmark cis-1.12 --targets node | grep '^[FAIL]'
[FAIL] 4.1.1 Ensure that the kubelet service file permissions are set to 600 or more restrict...
[FAIL] 4.1.9 If the kubelet config.yaml configuration file is being used validate permissi...
[FAIL] 4.2.1 Ensure that the --anonymous-auth argument is set to false (Automated)

Inspecting the configuration file permissions reveals a critical exposure: /var/lib/kubelet/config.yaml is set to mode 666 (world-readable and world-writable), allowing any unprivileged local user to inspect or modify core node parameters.

Furthermore, testing the kubelet API directly via curl demonstrates the chilling reality of enabled anonymous authentication:

$ stat -c '%a %U:%G %n' /var/lib/kubelet/config.yaml
666 root:root /var/lib/kubelet/config.yaml

$ curl -sk https://localhost:10250/pods; echo
Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource(s)=[pods proxy])

Even though requests are ultimately rejected due to RBAC authorization boundaries, unauthenticated requests are successfully accepted into the authentication layer as system:anonymous. A single misconfigured RBAC role binding could instantly expose sensitive workload data running on the node.

Phase 3: Implementing Worker Remediations

First, file permissions are restricted to 600 (read/write by root only), ensuring local processes cannot tamper with node configurations.

$ chmod 600 /var/lib/kubelet/config.yaml && stat -c '%a %U:%G %n' /var/lib/kubelet/config.yaml
600 root:root /var/lib/kubelet/config.yaml

Next, anonymous authentication is disabled within the same YAML configuration file. The administrator edits /var/lib/kubelet/config.yaml, modifying the anonymous.enabled flag from true to false while preserving webhook authentication.

apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
  anonymous:
    enabled: false
  webhook:
    cacheTTL: 0s
    enabled: true
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt

Unlike control plane static pods, the kubelet does not automatically reload configuration changes made to config.yaml. The administrator must explicitly restart the kubelet service via systemctl:

$ sudo systemctl restart kubelet

Verifying the changes demonstrates the success of defense-in-depth architecture: unauthenticated requests now fail immediately at the authentication gateway with an Unauthorized response, and kube-bench validates total compliance.

$ curl -sk https://localhost:10250/pods; echo
Unauthorized

$ kube-bench run --benchmark cis-1.12 --targets node --check 4.1.9,4.2.1 | grep '^['
[PASS] 4.1.9 If the kubelet config.yaml configuration file is being used validate permissi...
[PASS] 4.2.1 Ensure that the --anonymous-auth argument is set to false (Automated)

Supporting Data: Understanding the Underlying Security Risks

To successfully secure a Kubernetes cluster, security professionals must understand why these benchmark checks exist. Compliance is not merely a box-checking exercise; it is an active defense against sophisticated threat actors.

Scheduler Profiling (1.4.1): Profiling endpoints (exposed via Go’s net/http/pprof package) provide detailed runtime performance data, memory allocation metrics, and CPU profiles of control plane binaries. If left exposed, these endpoints give attackers deep insight into internal component mechanics, aiding memory-corruption exploitation or Denial of Service (DoS) attacks. Setting --profiling=false disables these debug handlers in production environments.
Kubelet Configuration File Permissions (4.1.9): The kubelet configuration file contains flags that dictate node security boundaries, authentication models, and network plugins. Allowing insecure permissions (666 or 644) lets unprivileged container escapees or compromised workloads modify kubelet behavior, potentially granting root-level node compromise.
Kubelet Anonymous Authentication (4.2.1): By default, older or default installations of Kubernetes may accept requests that do not present valid credentials, mapping them to the system:anonymous user. Disabling anonymous access forces all API callers to authenticate cryptographically, drastically reducing the attack surface of the kubelet API server.

Official Responses and Industry Standards

Cloud security frameworks and regulatory bodies increasingly mandate adherence to hardened baseline configurations. The Cloud Native Computing Foundation (CNCF), alongside agencies like the National Institute of Standards and Technology (NIST SP 800-190) and the Center for Internet Security, emphasize that container orchestration platforms must be audited continuously.

Security auditors and DevSecOps pipelines integrate tools like kube-bench into CI/CD workflows and periodic runtime compliance scans. Automated remediation operators and GitOps pipelines ensure that any drift from the CIS benchmark baseline is automatically detected and flagged or reverted to a known-good state.

Implications: Best Practices for Production Clusters

Adopting CIS benchmark hardening practices transforms an organization’s cloud-native security posture from reactive to proactive. However, administrators must navigate hardening initiatives with care to avoid service degradation.

Key Takeaways for CKS Candidates and Engineers

Targeted Execution: Always run audits against the specific node type (master or node) associated with the component under review.
Avoid Scope Creep: In high-stakes environments like the CKS exam, fix only the specific items requested. Over-remediation increases the risk of introducing syntax errors or breaking component dependencies.
Service Restarts vs. Static Pods: Remember that modifying static pod manifests (/etc/kubernetes/manifests/) results in automatic component restarts by the kubelet. Conversely, worker node configuration files (/var/lib/kubelet/config.yaml) require manual service restarts (systemctl restart kubelet).
Verification is Mandatory: Never assume a configuration change worked. Always re-run the specific check (--check) to confirm a [PASS] status.

By treating infrastructure hardening as an engineering discipline rooted in verification and continuous compliance, organizations can build resilient, highly secure Kubernetes environments capable of withstanding modern cyber threats.