- As part of VAULT-571 / #703 in 7109159, a new vault.serverEnabled
template was added (and included in vault.mode)
Various templates were updated accordingly, but those that were
already calling vault.mode had an additonal call to
vault.serverEnabled made which was unnecessary
Remove those
VAULT-571 Matching documented behavior and consul
Consul's helm template defaults most of the enabled to the special value
`"-"`, which means to inherit from global. This is what is implied
should happen in Vault as well according to the documentation for the
helm chart:
> [global.enabled] The master enabled/disabled configuration. If this is
> true, most components will be installed by default. If this is false,
> no components will be installed by default and manually opting-in is
> required, such as by setting server.enabled to true.
(https://www.vaultproject.io/docs/platform/k8s/helm/configuration#enabled)
We also simplified the chart logic using a few template helpers.
Co-authored-by: Theron Voran <tvoran@users.noreply.github.com>
* Make serviceAccount name a configuration option
Follow Helm Best Practices when defining serviceAccount names
https://helm.sh/docs/chart_best_practices/#using-rbac-resources
* Use enabled instead of create for consistency
* Add unit tests for user-defined service account name
* ServiceAccount under server
Co-authored-by: David Holsgrove <david@apnic.net>
* Update ServiceAccount in RoleBindings
to address https://github.com/hashicorp/vault-helm/pull/56#pullrequestreview-297856433
Co-authored-by: David Holsgrove <david@apnic.net>
* Update tests for helm template arg --show-only
Co-authored-by: David Holsgrove <david@apnic.net>
* Fix server-serviceaccount tests
* serviceAccount: rename enabled to create
* statefulSet: add tests for serviceAccount
Co-authored-by: Nick Satterly <nick@diabol.se>
Co-authored-by: David Holsgrove <david@apnic.net>