-
Notifications
You must be signed in to change notification settings - Fork 23
Description
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.