security(longhorn): clear the C-0211 residual on the four CSI sidecar Deployments #3946

🤖 Generated by the Agentic Engineer

Evidence

Measured 2026-09-20T21:20Z against live PROD stored controller specs — the surface Kubescape reads. longhorn-system is opted in to pod-security.devantler.tech/baseline-context and the mutation works, but 8 of its 11 controllers still carry neither fsGroupChangePolicy nor per-container seLinuxOptions, because the rules match CREATE only and these controllers predate the opt-in (#3636, 2026-09-06).

Four of the eight are CSI sidecar Deployments:

Audience and problem

#3918 sequences this namespace's residual into three classes by disruption and requires the least disruptive to go first. These four are that class: they are stateless CSI controller sidecars that roll normally, and unlike the engine-image DaemonSets and the InstanceManager pods they need no volume-reference or attachment-state reasoning before being touched. Bundling them with the storage-plane work would put a safe change behind an availability decision.

Nothing recreates them on their own, so this does not close by itself and the namespace reads as done while 8 workloads still fail.

Hypothesis

Bringing the four stored Deployment specs under the existing baseline-context mutation closes 4 of the namespace's 8 residual workloads with no volume detached and no storage-plane pod recreated. Because the rules are CREATE-only, reaching an already-created controller needs a mutate-existing-shaped rule (the repo already uses that pattern in label-existing-baseline-workers.yaml) rather than a pod restart — restarting yields clean pods but leaves the stored spec dirty, which is the surface Kubescape scores.

Success signal

• Baseline: 4 of 4 missing fsGroupChangePolicy; 4 of 4 with every container missing seLinuxOptions.
• Target: 0 of 4 on both, measured from stored specs.
• Guardrail: no change to privilege, user or group fields on any of the four; the other 7 controllers in the namespace unchanged; no pod outside these four Deployments recreated; no Longhorn volume detached or degraded.

Smallest useful change

A rule scoped to these four Deployments' namespace and kind that supplies only fsGroupChangePolicy and container-level seLinuxOptions — the same two non-privilege fields #3239 established, and nothing else.

Acceptance criteria

• The four Deployments' stored specs carry fsGroupChangePolicy and container-level seLinuxOptions.
• Verified with the discriminating predicate: fsGroupChangePolicy present AND every container has securityContext.seLinuxOptions. Do not test seLinuxOptions.level (never set; every object is {}) and do not test at pod level (absent on all 11 controllers by design, The fleet-wide seLinuxOptions injection destroys a Pod-level SELinux struct it should inherit #3469) — either reports every workload failing and never registers progress.
• No privilege, user or group field changed on any of the four, checked before/after.
• The engine-image DaemonSets, longhorn-csi-plugin, longhorn-manager, longhorn-ui and longhorn-driver-deployer are untouched, and no Longhorn volume is left detached or degraded.
• Both overlays build (kubectl kustomize k8s/clusters/local/ and .../prod/).

Size

Small. The care is in scoping the rule so it reaches exactly these four and does not roll the storage-plane DaemonSets in the same change.

Not in scope

The engine-image DaemonSets, longhorn-csi-plugin and the InstanceManager pods — they stay on #3918, which carries the volume-reference and attachment-state sequencing. The kube-system opt-in stays on #3239.

Part of #3918