Add configurable automountServiceAccountToken to operator Deployment#517
Add configurable automountServiceAccountToken to operator Deployment#517dgwhited wants to merge 1 commit intomattermost:masterfrom
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughBumps the mattermost-operator Helm chart version and adds a configurable Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Tip You can disable sequence diagrams in the walkthrough.Disable the |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
charts/mattermost-operator/templates/mattermost-operator/deployment.yaml (1)
30-30: Consider adding a default for robustness.The template directly accesses
.Values.mattermostOperator.serviceAccount.automountToken. If a user provides a custom values file that definesmattermostOperator.serviceAccountwithout theautomountTokenkey, Helm will render an empty value, producing invalid YAML.♻️ Proposed fix using Helm's default function
- automountServiceAccountToken: {{ .Values.mattermostOperator.serviceAccount.automountToken }} + automountServiceAccountToken: {{ .Values.mattermostOperator.serviceAccount.automountToken | default true }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@charts/mattermost-operator/templates/mattermost-operator/deployment.yaml` at line 30, The template directly renders automountServiceAccountToken from .Values.mattermostOperator.serviceAccount.automountToken which can be undefined and produce invalid YAML; update the deployment template (the automountServiceAccountToken field) to use Helm's default function to supply a safe boolean (e.g., default false) when .Values.mattermostOperator.serviceAccount.automountToken is missing so the rendered YAML is always valid.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@charts/mattermost-operator/templates/mattermost-operator/deployment.yaml`:
- Line 30: The template directly renders automountServiceAccountToken from
.Values.mattermostOperator.serviceAccount.automountToken which can be undefined
and produce invalid YAML; update the deployment template (the
automountServiceAccountToken field) to use Helm's default function to supply a
safe boolean (e.g., default false) when
.Values.mattermostOperator.serviceAccount.automountToken is missing so the
rendered YAML is always valid.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 18865d11-d1c5-4f89-9196-2d19189087e3
📒 Files selected for processing (3)
charts/mattermost-operator/Chart.yamlcharts/mattermost-operator/templates/mattermost-operator/deployment.yamlcharts/mattermost-operator/values.yaml
On platforms with policies that disable secret-based service account token automounting, the operator pod fails to start because it cannot find the token at /var/run/secrets/kubernetes.io/serviceaccount/token. Add an explicit automountServiceAccountToken field to the Deployment pod spec, driven by the new mattermostOperator.serviceAccount.automountToken value (default: true). This enables the projected volume token on hardened clusters while preserving existing behavior.
c68a630 to
c9b2a54
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
Summary
automountServiceAccountTokento the operator Deployment pod spec, configurable viamattermostOperator.serviceAccount.automountToken(defaults totrue)1.0.5Problem
On platforms with security policies that disable automatic mounting of service account tokens at the secret level, the operator pod fails to start with:
The current Deployment template relies on the Kubernetes default for
automountServiceAccountToken, which is overridden tofalsein hardened environments.Solution
Explicitly set
automountServiceAccountTokenin the Deployment pod spec, driven by a new Helm value:This causes the kubelet to mount a projected service account token volume, which works on hardened clusters that only disable the legacy secret-based token approach.
Changes
values.yamlautomountToken: trueunderserviceAccountdeployment.yamlautomountServiceAccountTokento pod specChart.yaml1.0.4→1.0.5Validation
This is a non-breaking change — existing deployments that rely on the Kubernetes default (
true) continue to work identically.Summary by CodeRabbit
Chores
New Features