security(kubescape): patch the two non-privilege C-0211 fields into workload templates, so the exception can narrow

[devantler]

🤖 Generated by the Agentic Engineer

Evidence

add-baseline-context-optin-* supplies fsGroupChangePolicy and an effective SELinux level to pods in opted-in namespaces, and it demonstrably works — velero's pods carry both fields and none failed to start. But Kyverno mutates the pod at admission, while Kubescape scores the stored workload spec. Settled with evidence on #3239 (2026-09-02): each scan object is keyed to the workload, not a pod (deployment-velero carries wlid://cluster-prod/namespace-velero/deployment-velero, kubescape.io/workload-kind: Deployment, relatedObjects: null), and the exception's own reason field has always said so — "Kubescape scans the stored spec, not the live pod."

velero is the natural experiment: opted in, its pods measurably carry both fields, its template carries neither, and the scan object is the Deployment's.

So no amount of widening the namespace opt-in can move a template-scored verdict. Re-measured live against prod stored specs on 2026-09-02:

field (pod level, stored spec)	absent on
fsGroupChangePolicy	35 / 35
effective SELinux level on every container	35 / 35
fsGroup	20 / 35
runAsGroup	26 / 35
runAsNonRoot	19 / 35

Population is 35 workloads across the four scanned excluded namespaces — 17 Deployments, 8 DaemonSets, 7 CronJobs, 3 StatefulSets (flux-system 6, longhorn-system 12, observability 15, velero 2).

Audience and problem

The pod-security-mutations-unscoped exception suppresses C-0211 across this population, so every workload reports passed w/exceptions regardless of its actual state. That exception is waiting to be narrowed, and it cannot narrow while the underlying templates still fail — which, on the scanned surface, all 35 do. The admission-time mutation improves runtime posture and can never discharge the exception.

Hypothesis

Patching the two non-privilege fields into the workload templates at source — chart values where the chart exposes them, kustomize patches where it does not — moves the scanned verdict for those two controls, after which C-0211's residual shrinks to the workloads that still fail on the genuinely privilege-adjacent fields (fsGroup, runAsGroup, runAsNonRoot) and narrowing the exception becomes sizable rather than all-or-nothing.

Deliberately not in scope: fsGroup, runAsGroup, runAsNonRoot. Those are the fields the namespace exclusions exist to protect, and supplying them is a privilege change, not a compliance one.

Success signal

• Baseline: 35 / 35 templates missing fsGroupChangePolicy; 35 / 35 missing an effective SELinux level.
• Target: 0 / 35 for both, read with the subStatus discriminator rather than the bare status — a suppressed control reads passed either way, so the naive read returns a clean result over an unfixed population (this is exactly the fail-open feat(security): document every suppressed control's fail-open, and fail CI when one is not #3517 generalised).
• Guardrail: no workload regressed on privilege, user or group fields, and no pod sandbox failing to start.

Smallest useful change

One namespace, smallest first: velero (2 workloads). It is already opted in, so the pod-scope and template-scope effects can be compared directly on the same workloads — which also proves the measurement method before it is applied to the other 33.

Acceptance criteria

• The two non-privilege fields are present in the stored spec of the targeted workloads, via chart values or kustomize patches, not via admission mutation.
• Verified by a single-object GET of the workload's workloadconfigurationscans object — a LIST returns .spec.controls null and would read as a clean sweep.
• subStatus is used to distinguish a genuine pass from a suppressed one.
• No regression on privilege, user or group fields; pods still start.
• The C-0211 residual recorded in pod-security-mutations-unscoped.yaml is updated to the new figure, re-measured rather than inherited.

Size

Medium, and naturally decomposable per namespace. The investigation is already done — #3239 carries it — so what remains is the mechanical work plus its measurement.

Follow-up to #3239, which established that admission-time mutation cannot move this surface. The two are complementary, not alternatives: the mutation stays for runtime posture, this is the narrowing path.

[devantler]

🤖 Generated by the Agentic Engineer

Post-merge verification: the fix is live, but C-0211 cannot be its success signal

Checked in prod after #3541 merged. Two findings, and the second one changes how this issue should be closed.

1. The fix is in the stored specs — confirmed

Both workloads now carry the two non-privilege fields directly in the template, which is the thing Kubescape actually scans:

Workload	fsGroupChangePolicy	container seLinuxOptions.level	runAsUser
Deployment/velero	OnRootMismatch	s0	65532 (unchanged)
DaemonSet/node-agent	OnRootMismatch	s0	0 (unchanged — keeps its host-path root)

2. C-0211 reads passed, and that reading is worthless here

It would be easy to read C-0211: passed on both workloads as success. It is not evidence of anything, for two independent reasons:

It passes by exception, not by compliance. The two rules this issue targeted both list the suppression explicitly:

rule=set-seLinuxOptions             status=passed  ignore=["pod-security-mutations-unscoped/C-0211"]
rule=set-fsgroupchangepolicy-value  status=passed  ignore=["pod-security-mutations-unscoped/C-0211"]

pod-security-mutations-unscoped ignores C-0211 cluster-wide, so these rules report passed whether or not the fields are present. The control is insensitive to this change by construction. (For contrast, set-fsgroup-value passes with no ignore and no fix path — that one is a genuine pass.)

The scan is also stale. Both rules still emit a fixPath for the very fields that are now present:

fixPath: spec.template.spec.containers[0].securityContext.seLinuxOptions
fixPath: spec.template.spec.securityContext.fsGroupChangePolicy

A fix path is only emitted when the rule found the field missing. So the scan evaluated a pre-#3541 spec. That is corroborated independently: the newest workloadconfigurationscan anywhere in the cluster was created 2026-09-02T10:21Z, while the velero rollout completed 2026-09-03T00:19Z. Nothing has re-scanned these workloads since the change.

What this means for closing this issue

This issue's own title is the right frame — the goal is "so the exception can narrow", not "so C-0211 turns green". C-0211 was always going to read passed here. So:

• Do not close this on a C-0211 reading, in either direction.
• The success signal is the stored spec (verified above) plus the residual population behind the exception shrinking — the count of 35 that the exception's own reason cites.
• The exception's stated premise, "The Deployment spec does not contain them", is now false for velero specifically. That is exactly the narrowing this issue was opened to enable.

The remaining work is therefore to re-measure the residual population once a scan cycle has actually run against the new specs, and narrow pod-security-mutations-unscoped by whatever that measurement licenses. I have not attempted the narrowing in this run, because doing it against a stale scan would size it wrong.

Worth noting for anyone auditing posture more broadly: 11 rules across this one workload pass only via an applied ignore rule. An exception-suppressed passed and a complied passed are indistinguishable in a summary count, so posture percentages built from control status alone will read better than the cluster is.