Why does kube-bench have to run on the node with host PID and host file access?

### What the CIS Kubernetes checks actually assert Most of the control-plane and node controls in the Kubernetes benchmark are assertions about two things on a specific machine: 1. **The command line of a running process.** Whether `kube-apiserver` was started with `--anonymous-auth=false`, what `--authorization-mode` it was given, whether the kubelet runs with `--read-only-port=0`, what `--client-ca-file` points at. 2. **The ownership and mode of files on disk.** The static pod manifests under `/etc/kubernetes/manifests`, the kubelet's config file and its kubeconfig, the certificate and key files, the etcd data directory. Neither of those is a Kubernetes API object. You cannot ask the API server what flags it was started with, and there is no resource to `kubectl get` for the mode of `/etc/kubernetes/manifests/kube-apiserver.yaml`. The only way to answer is to be on the machine and look. ### Why it runs as a privileged pod kube-bench is a binary plus benchmark definitions in YAML. Run on the host it simply reads `/proc` and the filesystem. Run the usual way — as a Job in the cluster it is assessing — it needs the host's view of both, so its pod spec typically sets: - `hostPID: true`, so the container's `/proc` shows the node's processes and kube-bench can read the API server's, controller-manager's, scheduler's and kubelet's actual command lines; - read-only `hostPath` mounts for the paths the checks care about — `/etc/kubernetes`, the kubelet config, the etcd data directory, systemd unit directories; - a node selector or a DaemonSet, because the answer is per-node: every node has its own kubelet flags and its own file permissions, and a single pod on one node tells you about one node. Strip those away and the checks do not quietly skip — they look at the container's own `/proc` and an empty filesystem and produce results that describe nothing. ### Manifest intent versus running reality This is the line that defines the whole category of tool. A file in git is a statement of intent. The process running on node 47 is the fact. They diverge for entirely ordinary reasons: someone edited a static pod manifest by hand during an incident and never put it back; a node bootstrap tool or a systemd drop-in appended flags the repository never saw; a package update replaced a config file and reset its mode; a node was built from an older image than the rest of the fleet. A profile runner exists precisely to measure the second thing, on each machine, as it is now. That is also why its results are *detective*: kube-bench blocks nothing and mutates nothing. It runs after the fact and produces a report. ### Reading the output kube-bench emits `[PASS]`, `[FAIL]`, `[WARN]` and `[INFO]` per check, grouped by benchmark section, with remediation text attached to the failures. The result to be careful about is `[WARN]`: it generally marks a check the tool cannot decide on its own — one that needs a human to confirm a value, or one whose target it could not inspect. Counting WARN as PASS inflates a compliance number with checks nobody performed. `--json` output makes the results ingestible; the checks are grouped by target, and the targets are the machine roles the benchmark defines — control-plane components, etcd, the node, and policy-level checks. ### The managed-cluster case On a managed cluster you do not get a shell on the control plane and there is no API server process on any node you can see. The control-plane sections of the benchmark are therefore **not applicable to you** rather than failing — the provider operates that layer, and evidence for it comes from the provider, not from your runner. What remains yours is the node role (kubelet flags, kubelet config file permissions, certificate rotation settings) and the policy-level checks, and kube-bench ships benchmark definitions for the managed offerings that scope the checks accordingly. Forcing the control-plane checks and reporting a page of failures is a misread of the shared-responsibility line, and an interviewer will notice. ### The interview point The question behind the question is whether you understand *what surface a control can be evaluated against*. Some assertions are answerable from a document; some are answerable only from a machine. "The API server must not enable anonymous auth" is the second kind once the cluster exists, and that is why this class of tool needs privileges on the target, runs per node, and produces a report rather than a verdict on a change.