<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=594357) </details> <!--IssueSummary end--> ## Problem to Solve When the GitLab chart deploys OpenBao, it uses `extraVolumes` and `extraVolumeMounts` to mount the secrets it manages — specifically the static unseal key secret and the HTTP audit token. These are set at the GitLab chart level in [`values.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/91f7086d1f1eeead76edbac403988b521438b05c/values.yaml#L1627-1646), overriding the OpenBao chart defaults. Because Helm performs a shallow merge on string and array values (only dictionaries are deep-merged), any user-defined `extraVolumes` or `extraVolumeMounts` completely replaces the entries set by the GitLab chart. This silently wipes out the unseal key and audit token mounts, causing OpenBao to crash-loop. As a result, users of the GitLab chart cannot safely use `extraVolumes` and `extraVolumeMounts` to add their own volumes without also manually re-declaring the GitLab-managed entries — which are internal implementation details they should not need to know about or maintain. **Workaround:** Users can re-declare the GitLab-managed entries alongside their own, as shown below, but this is fragile and couples users to internal chart implementation details: ```yaml openbao: extraVolumes: | - name: unseal secret: secretName: '{{ template "gitlab.openbao.unseal.secret" . }}' - name: audit secret: secretName: '{{ template "gitlab.openbao.authenticationTokenSecretFilePath.secret" . }}' - name: custom secret: secretName: my-custom-secret extraVolumeMounts: | - name: unseal mountPath: /srv/openbao/keys/gl-unseal-1 subPath: '{{ template "gitlab.openbao.unseal.key" . }}' readOnly: true - name: audit mountPath: /srv/openbao/audit/gitlab-auth subPath: '{{ template "gitlab.openbao.authenticationTokenSecretFilePath.key" . }}' readOnly: true - name: custom mountPath: /srv/openbao/custom/ ``` ## Proposal Extract the GitLab-managed unseal and audit entries out of `extraVolumes`/`extraVolumeMounts` and into dedicated Helm templates in the GitLab chart (e.g. `openbao.extraVolumes` and `openbao.extraVolumeMounts`), so that `extraVolumes` and `extraVolumeMounts` are free for user customization. Concretely, the approach suggested by [@clemensbeck](https://gitlab.com/clemensbeck) in [this comment](https://gitlab.com/gitlab-org/gitlab/-/work_items/592988#note_3162179727) would: 1. Define new templates `openbao.extraVolumes` and `openbao.extraVolumeMounts` in the GitLab chart's `templates/_openbao.tpl`, which include both the `gitlab.extraVolumes`/`gitlab.extraVolumeMounts` user-facing values **and** the hardcoded unseal/audit entries. 2. Remove the unseal and audit entries from `openbao.extraVolumes` and `openbao.extraVolumeMounts` in `values.yaml`, defaulting them to empty strings. 3. Update the OpenBao chart's `deployment.yaml` to call these new templates instead of the raw `extraVolumes`/`extraVolumeMounts` values. This cleanly separates GitLab-internal volume requirements from user-extensible ones, prevents accidental breakage, and aligns with the pattern already used elsewhere in the GitLab chart. **References:** - Discussion in [#592988](https://gitlab.com/gitlab-org/gitlab/-/work_items/592988#note_3150054221) - OpenBao chart deployment template: https://gitlab.com/gitlab-org/cloud-native/charts/openbao/-/blob/406a95f3e3f85668e986fbf7704085cd7434db6c/templates/deployment.yaml#L77 - GitLab chart values: https://gitlab.com/gitlab-org/charts/gitlab/-/blob/91f7086d1f1eeead76edbac403988b521438b05c/values.yaml#L1627-1646