Lesson 0036 · 35 minutes · Tool drill · Cluster Setup

Triage kube-bench findings without obeying the scanner blindly

A scanner accelerates inspection; it does not replace component knowledge. Extract non-passing checks, verify them against configuration, identify uncovered components, and prioritize fixes by impact.

Environment note

The current Windows shell has no Docker, WSL, Kubernetes CLI, or Linux node access. Use the provided kube-bench JSON report for this training attempt. Hero remains unavailable until you rerun kube-bench on a Linux control-plane and worker node.

Task: 25 minutes

Analyze these files without modifying them:

Create lab/lesson-36-answer.md containing:

  1. The exact PowerShell command used to extract every non-PASS result from the JSON.
  2. A table for all seven FAIL results and the one WARN result: check ID, component, status, scanner evidence, configuration evidence, verdict, and precise remediation.
  3. Your first three remediations in operational priority order, with one sentence of justification each.
  4. At least four security findings from the CoreDNS Deployment that kube-bench did not report.
  5. One paragraph explaining why WARN does not mean FAIL, why PASS is not universal proof, and why CoreDNS requires manual review here.
  6. The exact Linux commands you would use to install pinned kube-bench v0.16.0, verify its checksum, run control-plane/etcd/node/policies targets as root, save JSON, and make CI return a nonzero code when checks fail.
Tool reflex: kube-bench has PASS, FAIL, WARN, and INFO states. A WARN commonly needs manual attention. A failed check can also reflect an execution or detection problem, so compare actual_value and reason with effective configuration before changing a node.

PowerShell starting shape

$report = Get-Content .\lab\lesson-36-kube-bench.json -Raw | ConvertFrom-Json
$report.Controls.tests.results |
  Where-Object status -ne 'PASS' |
  Select-Object test_number, status, test_desc, actual_value, reason

Linux Hero rerun shape

# Run on a Linux node with access to component processes and files.
sudo kube-bench run --targets master,etcd,node,policies \
  --json --outputfile kube-bench.json --exit-code 42

You must determine and record the complete pinned installation and checksum-verification commands yourself.

Retrieval check

Question

kube-bench reports WARN for a manual check. What should you do?

Documentation targets

Use the official kube-bench repository, its installation guide, and the applicable CIS benchmark guidance after your first analysis.

What to send me

Save the Markdown answer and say check. I will list every issue and correct one per round. This attempt can advance CS-02 training, but the Hero tool gate requires a later real-node run.