Cluster checks

What they read

The registry covers workloads, RBAC, networking, storage and custom resources. Checks that match a published framework carry PSS baseline, PSS restricted or NSA/CISA labels.

• Security posture and risky workload configuration.
• Reliability, rollout and availability failures.
• Resource waste and missing capacity controls.
• APIs removed by a coming Kubernetes release and certificates nearing expiry.
• References to objects that no longer exist.

Working with findings

The view opens on the findings themselves. Scope, baselines, muted rules, imported findings and export sit together behind one Configure control, so the list is what you see first.

Findings rank by how far the problem reaches. Mute a rule, take a baseline to compare later or across clusters, and add checks of your own as CEL expressions.

A CEL rule sees the cluster the audit read through cluster.list(group, resource) and cluster.get(...), compares quantities with quantity(), reads a certificate's expiry with x509.notAfter(), and has CEL's string, list, set, math, regex and encoder libraries.

By framework control

The same findings can be read by control rather than by check, for the CIS Kubernetes Benchmark, PSS baseline, PSS restricted and NSA/CISA. Each control says what fails it and on how many objects.

A control no check answers says so. So does a control nothing reading a live cluster could answer, such as file permissions on a node or flags on a control-plane process, with the reason.

Exporting

Findings export as CSV, JSON or SARIF. The SARIF goes into tools that already read SARIF unchanged, and each finding carries a fingerprint, so a second run deduplicates against the first.

On a timer

--audit-interval re-runs the checks and keeps what each run found, so the view shows posture over time rather than only now. The interval has to be at least a minute.

--audit-webhook posts a JSON summary only when a run differs from the one before it: counts by severity, what appeared, what cleared, and which checks moved. It retries once, then says in the log that the notice did not land. Nothing about the webhook holds up the audit.

spinoza --audit-interval 1h --audit-webhook https://hooks.example.com/spinoza

Findings from elsewhere

Point Spinoza at the output of another scanner and its findings are shown beside the built-in ones, attached to the objects they name, so one list covers both.

Pod Security Standard verdicts come from the standard's own implementation rather than a second reading of the rules, so what you see here matches what an admission controller would decide.

What they run against

Checks read the caches Spinoza already keeps, so running them installs nothing in the cluster and costs no extra API traffic.