Which 800-53 rev5 Moderate controls form the assessable subset?

[backend-bunny]

Part of #1

Rewritten after the framework pivot. This ticket originally asked which of CCM v4's 207 controls form the assessable subset. v1 now targets NIST SP 800-53 rev5, Moderate baseline — CCM content cannot be shipped (see #11). The question is unchanged in shape; only the framework moved.

Question

Coverage is fixed as assessable subset only: Konstapel ingests and reports on controls with a genuine in-cluster signal, and the rest are outside the operator entirely.

That subset now has to be drawn against 800-53 rev5 Moderate, and the boundary is the most consequential judgement in the spec — it is what Konstapel claims to know.

• Walk the Moderate baseline's controls and enhancements and classify each: fully assessable, partially assessable, not assessable in-cluster.
• Settle what partially assessable means and whether it belongs in the subset at all. AC-6 (Least Privilege) has a real RBAC signal but no check proves least privilege; claiming it does is exactly the false-green failure this map exists to avoid.
• Decide the honesty rule: when Konstapel reports a control green, what precisely is being asserted, and where is that qualification recorded so a reader cannot miss it?
• Sanity-check the expected yield. If the honest subset is very small, that is a finding about the product, and better surfaced now than after the spec is written.

What the pivot changed

The subset should be larger and more natural than it would have been under CCM. 800-53's technical families — AC, AU, CM, SC, SI — describe configuration and access properties a cluster actually exhibits, where CCM's CSP-governance framing (IAM-01: "establish, document, approve… policies and procedures") largely does not. That is a hypothesis this ticket should confirm or refute with numbers, not assume.

The hard input — read this before classifying anything

#3 established, live, what Kyverno cannot substantiate, split into HARD (permanent architectural exclusions) and CONFIG (reachable with RBAC/packaging effort). That list is the primary input here. Notably out of reach: audit policy content, etcd encryption at rest, the effective value of any unset API server flag, managed control planes, node OS state, runtime behaviour, and all continuity claims. Reachable with effort: Nodes, RBAC objects, Secrets, StorageClasses, and kubelet config via the apiserver→/configz proxy.

Two further constraints from the map:

• Image-signing controls are not assessable until #15 proves a zero-egress verifyImages pass. Do not classify them optimistically ahead of that result — and if Spike: prove a zero-egress verifyImages pass end to end #15 finds the only green path requires rekor.ignoreTlog: true, the achievable claim is "signed by a key I trust", not "publicly logged", which weakens any control worded around verifiable provenance or transparency.
• Determinations are computed per canonical subject (the owning workload), not per reported resource — #10. A control assessable only at cluster scope and one assessable per workload are different kinds of thing; say which each is.

Resolution

The ratified control list with a per-control rationale, and the stated meaning of a passing verdict.