Infrastructure & CIS benchmarks

How Draugr fits. The infrastructure control ships today, backed by a native check that reads the cluster's API, with kube-bench available for the node-level checks it cannot reach. A cluster is a component like any other, one with no code of its own, so it sits in the same descriptor, gets the same P1–P4 ranking from its declared exposure and criticality, and lands in the same report as your dependency and code findings.

By default it runs the benchmark's policies section, covering RBAC, service accounts, Pod Security Standards, network policies and secrets usage. Those go through the Kubernetes API, so they mean the same thing from a laptop or from CI, and nothing is created in your cluster to get them.

That section is the benchmark's advisory one, and worth knowing before you read a clean result as a pass, because CIS marks every check in it manual, so it tells you what to review rather than what it measured. The scored checks are the ones about how the nodes and control plane were configured, and Draugr reaches those too.

The remaining checks, being API server manifests, kubelet configuration and etcd file permissions, are read from a node's own filesystem, and the only way to reach them is from a pod on that node. So enabling kubeBenchJob runs a short-lived Job, reads its output and deletes it, including when the scan fails or is canceled. That mutates your cluster and needs a privileged pod, so Draugr won't do it until you accept those two effects in the descriptor, and tells you exactly what it would do if you haven't. On a managed cluster (GKE, EKS, AKS) the control plane is not yours to inspect by any means, so scanning the nodes is the useful setting there. Either way, the report states which checks ran.

A cluster is often shared, and a component may own only part of it. The API-backed check takes a namespaces list and narrows to it, and the report names the scope it measured. A node's filesystem has no namespace, so the Job-based checks always describe the whole cluster, and Draugr does not run them against a component that claimed part of one, since a report that looked scoped while listing somebody else's namespaces would be worse than a missing one. It says which scanner went unanswered for which component, under Not measured. Declare the cluster twice, once narrowed and once whole, and each check runs where it can answer. See the integrations catalog.