pub fn validate_mover(mover: &MoverSpec, context: &str) -> ValidationResultExpand description
Validate a MoverSpec. context names the owning resource for the message (e.g.
"Restore mover").
inheritSecurityContextFrom and the explicit securityContext/podSecurityContext are
compatible, not mutually exclusive: they are adjacent layers of the merge ladder
(hardened ⊂ moverDefaults ⊂ inherited ⊂ explicit), so the explicit context overrides the
inherited one field-wise and fills whatever the workload does not pin — and stands in alone
when inheritance cannot resolve a pod.
This pair used to be rejected here, on the rationale that “the mover’s effective contexts
must have a single, unambiguous source so the privileged-mover gate runs on exactly one”.
That rationale was never true: the gate has always evaluated the merged product of
hardened + moverDefaults + recipe (see the callers of
crate::common::requires_privilege_resolved), which
crate::invariants::enforce_security_context_invariants normalizes first — INV-1 exists
precisely to reconcile an inherited runAsUser: 0 against the hardened runAsNonRoot: true. Merging one more layer in cannot smuggle an elevated mover past it.