security(kubescape): guard Coroot baseline-context convergence on every deploy #4014

🤖 Generated by the Agentic Engineer

Evidence

#3990's acceptance criterion 3 asks for a before-publish and after-reconcile guard, like the Longhorn UI canary's, that checks the stored fields on the six Coroot-operator templates and flags an owner that keeps rewriting them. The scoped admission rules shipped in #4007; the namespace label that activates them cannot land safely without this guard.

Audience and problem

The platform operator activating the Coroot C-0211 fix. Without a guard, an operator/admission write loop would only be noticed after it had been churning the monitoring stack.

Hypothesis

A read-only guard wired into every production deploy, disarmed while the label is absent, is enough to make activation a reversible, evidenced step.

Success signal

• The guard reports the live population correctly (six templates, operator-owned, ready) and fails after-reconcile today for the expected reason, since the fields are not yet stored.
• Guardrail: with the label absent the guard never contacts the cluster.

Acceptance criteria

• The guard disarms without a cluster read while the label is absent, and refuses an unexpected label value.
• While armed, it refuses a population other than the reviewed six, a template not controller-owned by Coroot, and an unready template; an API error is never an empty population.
• After reconcile it requires both fields on all six and fails on a changed generation/UID, a removed field, lost readiness, or repeated writes to one template.
• Fixture tests cover each case, with ablations proving each check is load-bearing, and CI runs them.

Size: S.