feat(chart): make pod and sidecar securityContext configurable

[yugstar]

What

Makes the csi-driver DaemonSet's pod- and container-level securityContext configurable through values.yaml, instead of hardcoding it in the template. Addresses #583.

New values (each defaults to the value that was previously hardcoded):

Value	Container / scope
podSecurityContext	pod-level
securityContext	cert-manager-csi-driver
nodeDriverRegistrarSecurityContext	node-driver-registrar
livenessProbeSecurityContext	liveness-probe

Why

Today templates/daemonset.yaml hardcodes privileged: true and runAsUser: 0 on the main container (and runAsUser: 0 on both sidecars), with no .Values.* overrides. Operators subject to Pod Security Standards (Baseline/Restricted) or security-scanning policies cannot adjust the posture without forking the chart — exactly the problem reported in #583.

This mirrors the convention already used in the main cert-manager chart, which exposes securityContext / containerSecurityContext as values with behavior-preserving defaults.

What changes by default

Nothing. Every new value defaults to the exact value that was previously hardcoded, so helm template output is semantically identical (verified by parsing the before/after manifests and asserting deep-equality, plus a helm-unittest golden suite). Mounting is unaffected: the pods-mount-dir / csi-data-dir mounts and their mountPropagation: "Bidirectional" are untouched, and the main container keeps privileged: true by default.

What becomes possible (opt-in)

Operators can now override any field, for example:

securityContext:
  runAsUser: 0
  privileged: false
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    add: [SYS_ADMIN]
    drop: [ALL]

A note on dropping privileged (re: the discussion in #583)

The issue discussion suggests privileged: true could simply be removed. I deliberately kept it as the default here: the cert-manager-csi-driver container mounts pods-mount-dir and csi-data-dir with mountPropagation: Bidirectional, and Kubernetes only permits Bidirectional mount propagation on privileged containers — so removing privileged outright would stop the driver pods from starting. Keeping the default unchanged makes this a pure, zero-risk configurability change, while still letting operators who have validated an alternative (e.g. CAP_SYS_ADMIN with adjusted propagation) opt into it. Flipping the default to non-privileged is a behavioral change that's best evaluated separately, with mount validation on a real cluster.

Testing

• helm template before/after manifests are semantically identical (default render unchanged).
• make verify-helm-unittest — new tests/securitycontext_test.yaml (defaults preserved + opt-in overrides + null-clears-block).
• make verify-helm-values, make verify-helm-lint, make verify-helm-kubeconform, make verify-pod-security-standards all pass.
• values.schema.json and README.md regenerated via make generate-helm-schema generate-helm-docs.

Open question

I named the per-container values securityContext / nodeDriverRegistrarSecurityContext / livenessProbeSecurityContext. If maintainers prefer a different layout (e.g. nesting them under a single map), that's a trivial rename and the default render stays identical — happy to adjust.

The csi-driver Helm chart now allows configuring the pod- and container-level `securityContext` via the `podSecurityContext`, `securityContext`, `nodeDriverRegistrarSecurityContext` and `livenessProbeSecurityContext` values. Defaults are unchanged.

[cert-manager-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign inteon for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[cert-manager-prow]

Hi @yugstar. Thanks for your PR.

I'm waiting for a cert-manager member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[wallrj-cyberark]

Hi @yugstar — same comment I just left on the companion PR cert-manager/csi-driver-spiffe#538, since this PR shares the same driver model.

Before reviewing the chart changes I empirically tested whether the driver actually functions with privileged: false. Results here: #583 (comment)

The short version: every variant of privileged: false either fails Kubernetes admission, fails to start, or silently delivers an empty volume to the workload pod. The driver structurally requires mountPropagation: Bidirectional, and Kubernetes only permits that on privileged containers, so a Helm values knob exposing privileged cannot deliver what the originating issue (#583) is asking for.

I also could not find a legitimate operator use case for the other knobs (podSecurityContext, sidecar fields, per-container runAsUser) on this daemonset specifically:

• Pod-level: main container must run as root and privileged, so pod-level fields are either ignored or break it. Sidecars override at container level.
• Sidecar securityContext (nodeDriverRegistrarSecurityContext, livenessProbeSecurityContext): defaults are already maximally restrictive. Configurability can only weaken them.
• Main container securityContext: only privileged: false is the field operators would want to change to satisfy scanners — which is the silent-failure case in the issue write-up.

I think the right outcome is to close this PR and address #583 with either (1) documentation in the chart README of why privileged: true is structural, so operators can write scanner exemptions, or (2) an architectural change to csi-lib that removes the Bidirectional requirement. The latter is non-trivial and is not a Helm change.

Happy to be shown wrong if you have an operator scenario the table in the issue comment does not cover.

---

Edit — walking back the secondary point above

I overstated the case when I said I "could not find a legitimate operator use case" for podSecurityContext, the sidecar fields, or per-container runAsUser. After more thought there are real reasons an operator might need them, even while the main container's privileged: true requirement stays put:

• AppArmor profiles apply to privileged containers. AppArmor is an LSM independent of capabilities — the kernel enforces a profile if one is set; the operator just has to write it permissively enough for the privileged operations to work. Hardened distros like Bottlerocket and Talos ship AppArmor policies; until Kubernetes 1.30 promoted appArmorProfile to a first-class SecurityContext field there was no way to apply them via Helm, and trust-manager's #836 merged the same shape for that chart.
• SELinux labels apply to privileged containers too. Multi-tenant clusters mandating specific seLinuxOptions.level values for tenancy isolation cannot apply them via the hardcoded chart.
• The sidecars (node-driver-registrar, liveness-probe) are not privileged. Operators on platforms with a custom Localhost seccomp profile have no way to apply it today — the chart hardcodes RuntimeDefault on the sidecars. The per-sidecar fields in this PR are how they would.
• runAsUser pinning on the sidecars is a real requirement on OpenShift SCC ranges and in environments with audit-log UID alignment policies.
• fsGroup at pod level for the hostPath ownership of csi-data-dir / plugin-dir in clusters with strict ownership policies. Niche but valid.

So the narrower recommendation: keep podSecurityContext, keep the sidecar fields, keep per-container runAsUser. Drop only the main container's securityContext exposure — the silent-failure footgun documented in the issue write-up is specific to that one knob and does not generalise to the rest of the PR.

Apologies for the overshoot in the previous comment.

[yugstar]

Same trim applied here as on the companion cert-manager/csi-driver-spiffe#538, per your review on #583. Dropped the main-container securityContext (back to hardcoded privileged: true with an explanatory comment), kept the pod-level and the two sidecar knobs. Schema, README and the helm unittests were regenerated.