security(kubescape): supply fsGroupChangePolicy and seLinuxOptions to the namespaces the security-context mutation excludes

[devantler]

🤖 Generated by the Agentic Engineer

Remaining engineering work: staged source-owned baseline rollout, tracked by #3636 for the Longhorn UI canary. Interactive read-only production access does not block the normal GitOps deploy path. Full-population remeasurement and C-0211 sizing remain open; no maintainer action is currently requested. Verified 2026-09-06.

Evidence

Sizing C-0211's residual population (#3217, measured 2026-08-19 against live prod specs) found that of
the 33 workloads in the four scanned namespaces add-security-context excludes, two gaps are
universal:

Field	Missing on
spec.template.spec.securityContext.fsGroupChangePolicy	33 / 33
securityContext.seLinuxOptions (every container)	33 / 33

Those two account for the whole population. Every other C-0211 field gap is a strict subset
(fsGroup 20, runAsGroup 18, runAsNonRoot 12).

Audience and problem

The twelve namespaces are excluded from add-security-context because the workloads there require
elevated privileges by design — that rationale is about privilege, and it is sound. But
fsGroupChangePolicy and seLinuxOptions are not privilege fields:

• fsGroupChangePolicy: OnRootMismatch controls volume ownership changes; rollout safety depends on
  the workload's existing fsGroup, volume types and reconciling owner. It is not universally inert.
• The current baseline uses seLinuxOptions: {} only where explicit pod/container options are absent,
  preserving runtime SELinux/MCS defaults and existing explicit options. The historical fixed
  level: s0 proposal is superseded; it must not be restored or described as universally harmless.

So the blanket exclusion is suppressing two controls it never needed to, in order to protect privilege
fields that are a different concern.

Hypothesis

A narrow mutation supplying only fsGroupChangePolicy and seLinuxOptions to the excluded
namespaces would close both universal gaps for all 33 workloads without touching privilege, user, or
group — after which C-0211's residual population drops to the subset that still fails on the
privilege-adjacent fields, and narrowing C-0211 becomes sizable rather than all-or-nothing.

Success signal

• Baseline: 33 of 33 fail set-fsgroupchangepolicy-value and set-seLinuxOptions.
• Target: 0 of 33 fail either, with no workload regressed on privilege, user or group fields, and
  no pod sandbox failing to start.
• Guardrail: the add-security-context comment records a real failure mode here — injecting a
  pod-level runAsGroup with no runAsUser yields the OCI user string ":1000", which containerd
  rejects. Neither field in scope has that coupling, but the rollout must prove it per namespace
  rather than assume it.

Smallest useful change

One namespace first — velero is the smallest (2 workloads) and one of them, velero/node-agent, is
in the population. Verify the two fields land and the pods still start, then widen.

Acceptance criteria

• A mutation supplies fsGroupChangePolicy and seLinuxOptions to the excluded namespaces, using
  conditional anchors so any chart-set value is preserved.
• Rolled out behind the feature-flag-first convention and validated in both states.
• The two universal gaps measure 0 of 33 afterwards, re-measured rather than inherited.
• pod-security-mutations-unscoped.yaml's C-0211 sizing is updated to the new residual.

Size

Small-to-medium. Note the in-cluster posture surface is not currently producing (#2933, #3024), so
verification must read the live specs directly rather than the posture score.

Part of #3217

[coderabbitai]

🔗 Related PRs

#3142 - docs(kubescape): correct the controller-rbac migration guidance [merged]
#3225 - fix(security): scope the pod-security mutation exception to where the mutation runs [merged]
#3212 - docs(kubescape): record the keep decision for the three unfalsifiable controls [merged]
#3214 - security(kubescape): drop all capabilities on the operator's own workloads [merged]
#3203 - security(vault-backup): disposition the last two CKV_K8S_40 findings as one deferred exception [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[devantler]

🤖 Generated by the Agentic Engineer

First increment shipped as #3460 — default-off, so this issue stays open

Baseline re-measured against live prod specs today rather than inherited from #3217: across the
twelve excluded namespaces, 210 of 210 pods carry no fsGroupChangePolicy and 189 of 210 have
at least one container with no seLinuxOptions. The "universal gap" premise holds at pod granularity.

What #3460 does. Adds two mutation rules supplying only those two fields, gated on a namespace
opt-in label (the mechanism add-user-namespaces already uses). Merging it changes nothing until a
namespace is labelled, which satisfies the feature-flag-first criterion and makes the rollout
per-namespace as this issue asks.

One measurement worth recording, because it changes how the guardrail reads. 119 of the 210 pods
set no fsGroup at all, and fsGroupChangePolicy only takes effect when fsGroup is present — so for
those the field is inert at runtime and satisfies the control only. That is the safe direction and
it is deliberate: fsGroup is a group field, so injecting it is exactly the privilege change the
exclusion exists to prevent. The rule changes what a pod declares, not how it runs, which is also why
the guardrail this issue names cannot bite — neither field carries the
runAsGroup-without-runAsUser coupling.

Acceptance criteria status

• Mutation supplies both fields using conditional anchors (verified: a pod presetting
  Always/s9 keeps them).
• Behind the feature-flag-first convention and validated in both states (opt-in labelled vs not).
• The two universal gaps measure 0 of 33 afterwards — not startable yet: nothing is labelled,
  and the rules are CREATE-only so existing pods only pick this up when recreated.
• pod-security-mutations-unscoped.yaml's C-0211 sizing updated — deliberately untouched,
  because the residual has not moved while the rule is off.

Next increment

Label velero (2 workloads, one of them in the population), let its pods recreate, then re-measure and
widen. ⚠️ That flip cannot be validated right now: the merge queue's deploy gate is blocked by #3454,
so nothing reaches the cluster until that is unwedged.

[devantler]

🤖 Generated by the Agentic Engineer

The velero increment is delivered and now measured live — the mutation demonstrably works

Re-measured against live prod specs today (2026-08-31), not inherited. Two of this issue's four
acceptance criteria are already satisfied by merged work:

• AC 1 (the mutation) — add-baseline-context-optin-* exists in add-security-context.yaml and
  supplies exactly fsGroupChangePolicy and seLinuxOptions, with conditional anchors, and
  deliberately not fsGroup.
• AC 2 (feature-flag-first, default-off) — it is gated on the namespace label
  pod-security.devantler.tech/baseline-context: enabled, so merging it changed nothing until a
  namespace opted in. velero is the one namespace opted in so far.

What the live cluster shows. Every velero pod created since the opt-in landed carries both
fields, and none failed to start:

Cohort in velero	fsGroupChangePolicy	every container has seLinuxOptions.level
Pods created after the opt-in	all	all
Pods predating the opt-in	none	none

That split is the proof: the rule is CREATE-only by design, so the pre-existing pods are expected
to lag and the post-opt-in cohort is the treatment group. The guardrail held too — no pod sandbox
failed to build, which is what the issue asked to be shown per namespace rather than assumed.

What is actually left

1. The long-lived velero workloads still predate the opt-in. The controller Deployment and the
   node-agent DaemonSet were created before it, so they keep the old spec until they are next
   recreated — velero/node-agent is named in this issue's own population. They will pick it up on
   the next chart upgrade; forcing a restart earlier is a judgement call worth making explicitly
   rather than waiting silently.
2. Widening to the remaining excluded namespaces. Of the twelve, six currently run no pods at all,
   so the widening is smaller than the original sizing suggests: only a handful of namespaces have a
   population to move, and flux-system should go last because it reconciles everything else.
3. AC 4 — refresh the C-0211 residual sizing in pod-security-mutations-unscoped.yaml once the
   widening lands.

Note the sizing in the issue body (33 workloads) predates the policy comment's own later measurement
of the wider excluded population, so re-derive the residual from live specs rather than from either
number.