Allow setting Security Context for Scan API and Scanner pods on MondooAuditConfig

[niklastreml]

Is your feature request related to a problem? Please describe.
We deploy mondoo-operator in a cluster with strict Gatekeeper (OPA) constraints on pod and container securityContext. The operator hardcodes the security contexts for the workloads it creates (controllers/nodes/resources.go, scan API deployment, admission, container/GC cronjobs), so the generated pods don't match our policies and are rejected at admission. Because the contexts aren't overridable, our users can't deploy MondooAuditConfig at all. Excluding the scanners from the policies is not an option in our environment, and per-workload Gatekeeper mutations are the wrong layer (see alternatives).

Describe the solution you'd like
Make the pod- and container-level security contexts configurable per component, since each workload has different requirements (node scanning must run privileged/root on OpenShift; the scan API and admission webhook do not). Proposed placement:

  spec:
    scanner:
      podSecurityContext: {}
      containerSecurityContext: {}
    nodes:
      podSecurityContext: {}
      containerSecurityContext: {}
    admission:
      podSecurityContext: {}
      containerSecurityContext: {}
    containers:            # container image scanning
      podSecurityContext: {}
      containerSecurityContext: {}

Example values for the node scanner:

    nodes:
      podSecurityContext:
        runAsGroup: 0
        fsGroup: 0
        fsGroupChangePolicy: OnRootMismatch
        supplementalGroups: [0, 4]
        seccompProfile:
          type: RuntimeDefault
      containerSecurityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        runAsNonRoot: false
        runAsUser: 0
        runAsGroup: 0
        privileged: false
        seccompProfile:
          type: RuntimeDefault
        capabilities:
          drop: [ALL]

Describe alternatives you've considered

• Gatekeeper mutations to rewrite what the operator sets: works for pod-level fields (the operator sets no pod securityContext today, so a mutator writes into empty space). But for the container-level fields the operator actively hardcodes, the mutator and the operator's reconcile loop overwrite each other on every sync, causing drift/thrash. This would quite unstable I presume
• Excluding the scanners from the Gatekeeper constraints: not permitted in our environment; the policies must apply cluster-wide.