security(kubescape): set the non-root group fields on coroot-operator at source #4217

🤖 Generated by the Agentic Engineer

Evidence

On 2026-09-26, after #4214 deployed, I measured the C-0211 population read-only against the live stored specs. Twelve of the 38 workloads still have no pod-level fsGroup. The exception file pod-security-mutations-unscoped.yaml describes all twelve as running "with elevated privileges by design".

That is not true for observability/coroot-operator:

• The pod sets runAsNonRoot: true and seccompProfile: RuntimeDefault.
• Its only container drops ALL capabilities, disallows privilege escalation, and has a read-only root filesystem.
• It mounts no volumes.
• Its image, ghcr.io/coroot/coroot-operator:1.10.2, declares USER 65534:65534 in its image config (read from the registry on 2026-09-26).

What it lacks is fsGroup and runAsGroup. Neither needs elevated privilege.

Audience and problem

This affects anyone relying on the C-0211 exception to narrow (#3522). The exception can narrow only once every remaining workload is either fixed at source or given a scoped, name-level exception with a reason. Recording coroot-operator as "elevated" would give it an exception it does not need.

Hypothesis and success signal

Setting runAsUser, runAsGroup and fsGroup to 65534 on the operator pod does not change how it runs. That is the identity it already runs as, and it has no volumes. After deploy, the live stored spec carries all three fields and the operator stays Ready. The population missing fsGroup drops from 12 to 11, all of them genuinely elevated.

Acceptance criteria

• The coroot-operator HelmRelease sets pod-level runAsUser, runAsGroup and fsGroup to 65534, never runAsGroup alone.
• The exception's notes list the remaining eleven workloads accurately.
• After deploy, a read-back shows the three fields on the live Deployment and the pod Ready.

Size: S.