You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
security(kubescape): close the Coroot C-0211 residual through a scoped, convergence-proven admission mutation #3990
Six of the 14 remaining C-0211 workloads are the Coroot stack in observability: the server, prometheus, cluster-agent, node-agent, clickhouse and keeper. All six are templates generated by the Coroot operator. The installed Coroot CRD has no pod-level security field for any component and no field at all for node-agent, so the fix can't be supplied through operator configuration the way it was for the Helm-rendered workloads. Measurement and CRD survey: #3239 (comment).
Audience and problem
Until these six stored templates carry fsGroupChangePolicy and seLinuxOptions, the cluster-wide C-0211 exception can't narrow for observability. docs/baseline-context-rollout.md keeps the namespace-wide baseline-context-controllers switch off because admitting fields the operator didn't set could make it rewrite its objects repeatedly.
Hypothesis
Scoping the existing controller mutation to Coroot-owned controllers (not the whole namespace), and gating it on a preflight / after-apply convergence proof, closes all six without an operator write loop. The operator's current write pattern is bounded: its last writes on these objects are days old despite continuous reconciliation.
Success signal
The observability residual goes from 6 to 0 under the object-presence predicate, measured on the live stored specs.
Guardrail: the operator's write count on the six objects doesn't grow across a 30-minute window after apply, and every Coroot pod stays Ready.
Acceptance criteria
The mutation reaches only Coroot-owned Deployments, StatefulSets and DaemonSets, not other observability workloads.
A test proves it applies with the scope label present and doesn't apply without it.
A before-publish and after-reconcile guard, like the Longhorn UI canary's, checks the stored fields and flags an owner that keeps rewriting.
Verified in prod: the observability residual is 0, with no write loop
I measured the six Coroot templates' live stored specs (read-only, 2026-09-22), using the same object-presence predicate as #3239.
Residual: 6 → 0. All six templates (the server, prometheus, cluster-agent, node-agent, clickhouse shard and keeper) carry the pod-level fsGroupChangePolicy and a container-level seLinuxOptions.
Guardrail held. Between 02:14:00Z and 02:44:44Z, all six kept the same generation and resourceVersion, so the operator did not rewrite them. All 16 long-running Coroot pods stayed Ready.
Activity
chore: agent-claim #3990 nonce=6c6eaeb117bba2c1748543de7942f1f2
chore: agent-claim #3990 nonce=986f48f44f06fd327177449e8f9dea45
devantler commentedon Sep 22, 2026
Verified in prod: the observability residual is 0, with no write loop
I measured the six Coroot templates' live stored specs (read-only, 2026-09-22), using the same object-presence predicate as #3239.
fsGroupChangePolicyand a container-levelseLinuxOptions.generationandresourceVersion, so the operator did not rewrite them. All 16 long-running Coroot pods stayed Ready.Every acceptance criterion is met, so I'm closing this. The residual is recorded on #3239 as well.