CIS benchmarks are somebody else's checklist, and that is the point
Run a CIS benchmark against a Kubernetes cluster for the first time and you get a few hundred results, a percentage, and an uncomfortable feeling.
The percentage is the least useful number in the report, and chasing it is the most common way teams end up abandoning benchmarks entirely.
What a benchmark is#
A benchmark is a checklist written by a committee, for a category of system, in the absence of any knowledge about yours. That is not a criticism but the only way a shared standard can work. The value comes precisely from it being external: a list you wrote yourself would omit the things you have not thought of, which is the entire reason to use somebody else's.
But it means a failed check has two possible meanings, and they look identical in the report:
- You did not know. The benchmark just told you something useful.
- You knew, and chose otherwise, for a reason that is still valid.
A managed cluster where the provider owns the control plane will fail control-plane checks forever. A cluster running a workload that needs a hostPath mount will fail that check every time. Neither is a defect. Both are permanent, and both will be in every report you ever run.
Why the percentage corrodes#
Because the two categories are mixed, the score is meaningless the moment you have any deliberate exceptions, which is immediately.
What happens next is predictable. The number never reaches 100. Somebody asks why it is 78%. Somebody else explains that 15% is architectural and cannot change. The number is quietly stopped being reported, and with it goes the part that was useful: the checks that failed for the first time this month.
A benchmark is not an exam. Reading it as one guarantees you stop reading it.
The report worth having#
There are only two lines in a benchmark run that anyone should act on:
- What changed since last time. A check that passed last month and fails now is a regression, and it is the single highest-value output of running a benchmark repeatedly. It is also invisible if you only ever look at the current score.
- What is failing that nobody has decided about. Not the known exceptions, the residue after you subtract them.
Everything else is either passing or already decided, and neither needs anyone's attention.
Deciding is the work#
Getting to that report means doing the thing benchmarks are usually deployed to avoid: going through the failures once, properly, and recording a decision for each one you are not going to fix.
That record needs to survive the person who made it. A benchmark exception that says "N/A" is worthless in eighteen months; one that says which architectural fact makes it not apply, and who concluded that, is still useful when a new platform engineer asks. This is risk acceptance applied to a checklist, and it is the same discipline: an accepted item stays visible, marked, with a reason and an owner.
Do that once and the benchmark becomes a monitor rather than an audit. Skip it and you have a percentage nobody trusts.
What is worth knowing about the tooling#
Benchmark checks split into two kinds, and they have very different costs.
Some are answerable by reading the cluster's API. Is this admission controller enabled, do these pods run privileged, are there network policies. Cheap, safe, and possible from anywhere with credentials.
Others require looking at the control-plane node itself, file permissions on manifests, process arguments on the API server. Those need to run on the node, which on managed Kubernetes you often cannot do at all, and which is why so many benchmark reports have a large "could not assess" section that people read as failures.
Knowing which kind a check is tells you whether a failure is something you can fix, something your provider owns, or something the tool could not see. That distinction matters more than the score does.
Draugr's infrastructure control reads the cluster API natively by default, and can run kube-bench
for the node-level checks when you want them. Reporting a check it could not assess as an error
rather than as a pass, because "we did not look" and "it is fine" are not the same answer.
The CIS benchmarks guide covers what the benchmarks contain and how they are structured.