feature: Helm chart for Kubernetes deployment

[babykart]

✨ Describe the feature you'd like

It would be cool to deploy vault-unseal via a helm chart in a Kubernetes cluster.

🌧 Is your feature request related to a problem?

No response

🔎 Describe alternatives you've considered

I've considered to write 3 deployments with their respective secret.
With a Helm chart, I will be able to deploy vault-unseal for example in 3 distinct namespaces with a GitOps tool (ArgoCD, Flux...).
In fact, Helm chart is clearly a standard in the Kubernetes ecosystem and it would be a nice-to-have deployment for this very usefull project.

⚠ If implemented, do you think this feature will be a breaking change to users?

No

⚙ Additional context

No response

🤝 Requirements

• I have confirmed that someone else has not submitted a similar feature request.
• If implemented, I believe this feature will help others, in addition to solving my problems.
• I have looked into alternative solutions to the best of my ability.
• (optional) I would be willing to contribute to testing this feature if implemented, or making a PR to implement this functionality.

[lrstanley]

Have been planning to do this for a while, and can likely tackle it soon, as I now have more experience with making and maintaining helm charts.

[babykart]

While waiting for the official helm chart, I use this one for my needs.

[lrstanley]

Some notes for myself before I actually start the work on this:

1. Determine concerns with running inside or outside of a Vault namespace (or if Vault is running outside of the cluster). If users do want to run both within the cluster, they should probably be in separate namespaces and we should probably recommend this.
2. Need to finally transition to supporting more than the config file -- flags and environment variables should support everything inside of the config. Don't want to force requiring a secret that has the entire config.
   • Tokens (and potentially other configs) should be modular. I.e. you can just have those be a part of a separate secret/config. Would make it easier to automate as well.
3. Default topology to be by hostname (i.e. default to requiring at least as many nodes as vault-unseal instances). Would both ensure one node doesn't kill the ability to recover, as well as reduce the chance that some level of node compromise will compromise all instances.
   • Leave other AZ constraints to the user, as not all users may have the option.
4. PSPs, AppArmor/Seccomp can reduce outward attack vectors, but what about the inverse? Is there anything we can do?

Planning on having the chart externalized into a dedicated repo for other helm charts I maintain, as I have 3-5 others already planned, and have some automation in place to automatically submit PRs when new versions of the base software (e.g. vault-unseal) release new versions. Still WIP though: https://github.com/lrstanley/helm-charts

[soakes]

While waiting for the official helm chart, I use this one for my needs.

Thanks @babykart for providing this solution.