security(kubescape): set fsGroup on flux-operator and longhorn-ui #4214

🤖 Generated by the Agentic Engineer

Evidence

After #4212 shipped, 14 of the 38 C-0211-scanned workloads still miss a pod-level fsGroup in their stored spec (#3522). Measured read-only against live prod on 2026-09-26.

Two of the 14 run as non-root and lack only fsGroup: the flux-operator Deployment (uid and gid 65532, from its image) and the longhorn-ui Deployment (uid 499, gid 486, already pinned in its HelmRelease). The other 12 run with elevated privileges by design and need scoped exceptions instead, not a field change.

Hypothesis

Setting fsGroup at source to each workload's own group moves both out of C-0211's fsGroup gap. Neither pod mounts a persistent volume, so the only effect is group ownership of their emptyDir volumes. The residual blocking the narrowing in #3522 drops from 14 to exactly the 12 elevated workloads.

Acceptance criteria

• flux-operator carries pod-level fsGroup: 65532 and longhorn-ui carries pod-level fsGroup: 486.
• The production authorization fingerprint is re-approved for exactly these two HelmReleases, with no RBAC, binding, service account or AWS identity change.
• After deploy, a read-only read of the prod stored specs shows the field on both, and both Deployments are available.