-
Notifications
You must be signed in to change notification settings - Fork 23
feat: add support for TLS
generation with OpenBao
#1622
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: stackhpc/2024.1
Are you sure you want to change the base?
Conversation
953aff4
to
1063a54
Compare
Co-authored-by: Will Szumski <[email protected]>
Should we deprecate hashicorp vault and refer people to the openbao page? I know there is some duplication between the playbooks, but I don't see a massive problem if we remove support for vault in the near future. Any migration path for your old data? |
I think for all new deployments we should use OpenBao. It terms of migrating from vault to openbao I think TLS could be discarded and you still deploy from scratch say in the run up to a certificate replacement. However the problem is Barbican that data is valuable and should be imported. My understanding though I haven't tested is OpenBao should be an inplace upgrade of the container image. Though we need to handle the different configuration file and docker volumes. Something that could be tested in a AIO. |
Sounds promising. I'd suggest adding a notice in the vault docs noting that it is deprecated and new deployments should use OpenBao (also worth mentioning it in the release note). We can add the migration procedure once we have worked it out :) |
I think we need some more write up why do we need to duplicate all playbooks - in theory we use the same client. Can't we just update the vault playbooks with some variables when openbao is enabled? |
I decided to clone the playbooks so there is clear distinction between Vault and OpenBao I think it would be confusing to some that the playbook for deploying OpenBao is called |
No description provided.