kube-bench runs the CIS Kubernetes Benchmark against a cluster and produces a pass/fail report per control, which is strong, recognized evidence for an auditor. On Syself Autopilot most of the control-plane and node checks are already hardened for you, so the useful skill is reading the report against what the platform sets, rather than treating every finding as an action item.

## Run it as a Job

kube-bench runs on the nodes, checking the API server, controller-manager, scheduler, etcd, and kubelet configuration. Run it as a Job on both control-plane and worker nodes:

```yaml title="kube-bench-job.yaml"
apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench
  namespace: kube-system
spec:
  template:
    spec:
      hostPID: true
      nodeSelector:
        node-role.kubernetes.io/control-plane: ""
      tolerations:
        - operator: Exists
      containers:
        - name: kube-bench
          image: aquasec/kube-bench:latest
          command: ["kube-bench"]
      restartPolicy: Never
```

```console
$ kubectl logs job/kube-bench -n kube-system
```

Run a second Job without the control-plane `nodeSelector` to cover the worker (kubelet) checks.

## What the platform already hardens

Many control-plane and kubelet checks are satisfied by the platform's configuration, so they pass out of the box:

- **API server flags** map to a set of CIS controls the platform sets: anonymous auth off, the `Node,RBAC` authorization mode, `NodeRestriction` admission, and audit logging (the API audit policy maps to CIS 1.2.19 through 1.2.23).
- **File-permission and ownership checks** on the control-plane component files map to the [sealed, read-only OS](/docs/hetzner/apalla/security/node-and-os-security): the files cannot be changed at runtime, which is a stronger guarantee than a permission bit.
- **kubelet flags** (seccomp default on, anonymous auth off, the authorization mode) are set by the platform, so the kubelet checks pass.

Annotate your report with which findings the platform owns, so your auditor sees the managed control plane is configured correctly, not misconfigured.

## Interpret the expected failures

Some checks cannot pass on a managed control plane, and that is expected, not a gap. A check that expects to read a file at a fixed host path may report a failure because the platform's control plane is structured differently (static pods, a sealed OS) than the benchmark's stock layout assumes. These are `WARN` or expected `FAIL` lines: note them as "managed control plane, satisfied by platform configuration" rather than remediating a file that is not yours to change. What remains after those are set aside is what is genuinely yours: your RBAC, your Pod Security levels, your network policies.

## Export the report

Save the kube-bench output (it supports JSON with `--json`) and keep it with your other [security evidence](/docs/hetzner/apalla/security/security-evidence-per-release) for the audit. Rerun it after each cluster upgrade so the evidence stays current, and pair it with the framework mappings in [Meet compliance requirements](/docs/hetzner/apalla/security/meet-compliance-requirements).