Unable to set securityContext for crd-installation Job via values; operatorSecurityContext appears unused/deprecated

Hey,

we’re running into an issue configuring the security context of the CRD pre‑install Job (crd-installation) created by the operator Helm chart (v25.3.1).

Goal

We want to satisfy a Kyverno policy that requires:

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  runAsUser: 65532
  capabilities:
    drop:
      - "ALL"

for all containers, including the crd-installation container in the pre‑install Job that installs CRDs. Our helm-values.yaml contains:

# Default values for the Redpanda Operator Helm chart.

# Additional labels …
commonLabels:
  amprion.net/sla: "Bronce"
  amprion.net/environment: "athena-addon"
  amprion.net/gitrepo: "gitops-athena-privileged-test"
  amprion.net/spoc: "leon.rauschenbach"
  amprion.net/team: "s-hs-b-kubernetes"

replicaCount: 1

image:
  repository: jpd-edge1.amp-cloud.lan/dockerhub-docker-sremote/redpandadata/redpanda-operator

crds:
  enabled: true

resources:
  limits:
    memory: 50Mi
  requests:
    cpu: 100m
    memory: 25Mi

podTemplate:
  spec:
    containers:
      - name: manager
        resources: {}
        securityContext:
          runAsUser: 65532
          allowPrivilegeEscalation: false
          runAsNonRoot: true
          capabilities:
            drop:
              - ALL
          readOnlyRootFilesystem: false

This successfully affects the manager container in the main Deployment as expected. However, the CRD pre‑install Job still renders with only:

securityContext:
  allowPrivilegeEscalation: false

for the crd-installation container. The runAsUser, runAsNonRoot, and capabilities.drop from podTemplate.spec are not applied to that Job’s container.

Documentation vs actual behavior

The chart’s values.yaml includes this commented section:

# -- Sets operator container security context
# For details,
# see the [Kubernetes documentation](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1).
# operatorSecurityContext:

However:

• values.schema.json doesn’t define operatorSecurityContext.
• operatorSecurityContext doesn’t appear to be referenced in the generated templates (including the CRD Job code in _post-install-crd-job.go.tpl).
• The CRD Job template (operator.crdJobContainers) hard‑codes only allowPrivilegeEscalation: false and doesn’t seem to merge any container-level security context from values.

So from what we can see, operatorSecurityContext looks effectively unused/deprecated. There is no value we can set to control the securityContext of the crd-installation Job container via Helm values.

Expected / desired behavior

Ideally, we’d like the following:

• A documented values key (e.g. crdJob.containerSecurityContext or similar) that is actually used when rendering the crd-installation Job, so we can configure runAsUser, runAsNonRoot, readOnlyRootFilesystem, and capabilities.drop without external patching.

Questions

• Is there currently any supported way, via values, to set the securityContext (including capabilities) on the crd-installation Job container?
• Is operatorSecurityContext intended to be used, or is it left over from an older version and effectively deprecated?
• Would you accept a change to expose a dedicated crdJob securityContext value and wire it into operator.crdJobContainers?

Thanks for the great work on the operator. Any guidance or clarification on the intended configuration for the CRD Job’s security context would be very helpful.

Start with _post-install-crd-job.go.tpl and the operator.crdJobContainers helper, then compare their securityContext handling with values.yaml and values.schema.json. Confirm whether any existing value reaches the CRD-installation Job, and consider the documented configuration and rendered Job complete when the requested container security fields are accepted and present.