Allow using existing ServiceAccount without creating a new one
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 191
- Forks
- 98
- Avg merge
- 2d 4h
- Merged PRs (30d)
- 6
Description
The qdrant Helm chart currently does not provide a way to use an existing ServiceAccount without creating a new one. The chart's _helpers.tpl template serviceAccountName already supports this pattern through values, but:
- The templates/serviceaccount.yaml template lacks a conditional guard and always creates a new ServiceAccount, regardless of serviceAccount.create setting.
- The templates/statefulset.yaml hardcodes serviceAccountName: {{ include "qdrant.fullname" . }} instead of calling the qdrant.serviceAccountName helper, making it impossible to use a pre-existing ServiceAccount.
Current Behavior
- serviceAccount.create: false + serviceAccount.name: existing-service acoount → Pod still tries to use auto-created SA; SCC/RBAC bindings for the existing SA are ignored
- Users deploying in restricted environments cannot reuse centrally-managed ServiceAccounts
- Duplicate ServiceAccount objects are created unnecessarily
Expected Behavior
When serviceAccount.create: false and serviceAccount.name is set:
- No ServiceAccount resource should be created
- Pod's serviceAccountName should use the specified existing SA
- Existing RBAC/SCC bindings for that SA should apply to the pod
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Inspect templates/serviceaccount.yaml and templates/statefulset.yaml, then compare their behavior with the qdrant.serviceAccountName helper in templates/_helpers.tpl. Render the chart with serviceAccount.create set to false and an existing name, and verify that no ServiceAccount is created and the workload uses the specified name.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- helm, kubernetes
- Domain
- devops
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 78/100