You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE] Make Helm chart configurable to satisfy Gatekeeper / Pod Security policies #442
Is your feature request related to a problem or existing issue? Please describe.
The charts/node-readiness-controller Helm chart has two configurability gaps that prevent it from passing common Gatekeeper (gatekeeper-library) constraints without manually editing templates:
automountServiceAccountToken is neither set nor exposed. Several Gatekeeper policies require this field to be explicitly set on the ServiceAccount and/or pod spec. The chart does not render it anywhere today, so those constraints reject the workload.
No extraVolumes / extraVolumeMounts values. These are needed to inject a projected ServiceAccount token when automountServiceAccountToken: false. The controller uses rest.InClusterConfig(), which requires token + ca.crt + namespace at /var/run/secrets/kubernetes.io/serviceaccount, so there is currently no way to run token-free without patching templates.
Describe the solution you'd like
Expose the missing knobs in the chart:
values.yaml: add serviceAccount.automountServiceAccountToken (default true), plus extraVolumes: [] and extraVolumeMounts: [] with a documented projected-token example.
Keeping the chart as-is and having operators fork/patch templates to satisfy their policy — rejected as poor UX and hard to maintain.
A token-only projected volume — does not work: missing ca.crt causes TLS verification failure against the API server, so the full three-source volume is required.
Implemented as you described, with automountServiceAccountToken rendered on both the ServiceAccount and the pod spec, plus extraVolumes and extraVolumeMounts. Default stays true.
Rendered your projected-token config end to end and it works. Put that example inline in values.yaml, since disabling the automount without restoring token, ca.crt and namespace leaves InClusterConfig with nothing to authenticate with, which is easy to trip over.
Activity
tejassinghbhati commentedon Sep 3, 2026
Picked this up, PR is #461.
Implemented as you described, with automountServiceAccountToken rendered on both the ServiceAccount and the pod spec, plus extraVolumes and extraVolumeMounts. Default stays true.
Rendered your projected-token config end to end and it works. Put that example inline in values.yaml, since disabling the automount without restoring token, ca.crt and namespace leaves InClusterConfig with nothing to authenticate with, which is easy to trip over.