Summary
The serviceAccount.automount setting is ignored in both Graylog and MongoDB ServiceAccount templates due to a Helm templating idiom bug. Setting serviceAccount.automount: false in values does not prevent service account tokens from being automounted.
Details
The ServiceAccount templates in auth/sa.yaml (line 12) and auth/mongo-sa.yaml (line 12) use the pattern .Values.serviceAccount.automount | default true. This fails because
the default filter only applies when the value is missing entirely—it does not override explicit false values. In Helm templating, .Values.x | default true when x is
false will still pass through false, but the automountServiceAccountToken field is then never rendered at all, leaving the Kubernetes default (true) in effect.
Reference: B-01 (Production Readiness Review)
Impact
Users cannot disable service account token automounting even when it's explicitly set to false in their values. This is a security concern as it prevents teams from enforcing
the principle of least privilege by disabling unnecessary token mounts.
How to Reproduce?
Environment
- Helm chart version: v4.2.0 or later
- Kubernetes version: any (this is a template rendering issue)
Pre-flight checks
Steps to reproduce the issue:
- Create a
values.yaml file with:
serviceAccount:
automount: false
- Run helm template release ./graylog -f values.yaml and inspect the rendered ServiceAccount manifests:
helm template release ./graylog -f values.yaml | grep -A 5 "kind: ServiceAccount"
- Check the rendered auth/sa.yaml and auth/mongo-sa.yaml ServiceAccount resources in the output.
Expected behavior
Both ServiceAccount resources should contain automountServiceAccountToken: false. Instead, the field is omitted entirely, causing Kubernetes to use the default value of true.
Actual behavior
The automountServiceAccountToken field is absent from the rendered templates, resulting in service account tokens being automounted regardless of the values.yaml setting.
Notes for maintainers
This is part of the broader "default true" idiom failure documented in the Production Readiness Review. The fix is straightforward—replace the conditional pattern with explicit
boolean handling:
{{- if eq (.Values.serviceAccount.automount | toString) "false" }}
automountServiceAccountToken: false
{{- end }}
Summary
The
serviceAccount.automountsetting is ignored in both Graylog and MongoDB ServiceAccount templates due to a Helm templating idiom bug. SettingserviceAccount.automount: falsein values does not prevent service account tokens from being automounted.Details
The ServiceAccount templates in
auth/sa.yaml(line 12) andauth/mongo-sa.yaml(line 12) use the pattern.Values.serviceAccount.automount | default true. This fails becausethe
defaultfilter only applies when the value is missing entirely—it does not override explicitfalsevalues. In Helm templating,.Values.x | default truewhenxisfalsewill still pass throughfalse, but theautomountServiceAccountTokenfield is then never rendered at all, leaving the Kubernetes default (true) in effect.Reference: B-01 (Production Readiness Review)
Impact
Users cannot disable service account token automounting even when it's explicitly set to
falsein their values. This is a security concern as it prevents teams from enforcingthe principle of least privilege by disabling unnecessary token mounts.
How to Reproduce?
Environment
Pre-flight checks
helm lint ./graylogpassesSteps to reproduce the issue:
values.yamlfile with:helm template release ./graylog -f values.yaml | grep -A 5 "kind: ServiceAccount"
Expected behavior
Both ServiceAccount resources should contain automountServiceAccountToken: false. Instead, the field is omitted entirely, causing Kubernetes to use the default value of true.
Actual behavior
The automountServiceAccountToken field is absent from the rendered templates, resulting in service account tokens being automounted regardless of the values.yaml setting.
Notes for maintainers
This is part of the broader "default true" idiom failure documented in the Production Readiness Review. The fix is straightforward—replace the conditional pattern with explicit
boolean handling: