Skip to content

Conversation

@digiserg
Copy link
Contributor

This PR introduces support for OpenBao as a secret provider.

Following the recent licensing changes to HashiCorp Vault (BSL), many users are transitioning to OpenBao, an open-source community fork under the LF Decentralized Trust. Since OpenBao maintains API compatibility with Vault's core functionality, this implementation leverages the existing Vault logic while allowing users to explicitly define bao as a source.

Changes

  • Added openbao to the list of supported secret providers.
  • Implemented the OpenBao provider (mirroring the Vault provider logic).
  • Updated documentation to include connection examples for OpenBao.
  • Added unit tests for the bao prefix to ensure URI parsing works correctly.

Why this is needed

As organizations move away from BSL-licensed software, vals needs to remain a neutral and flexible tool for secret injection. Providing first-class support for OpenBao allows users to migrate their infrastructure without losing the ability to manage secrets via Helmfile and other tools that depend on vals.

How to test

You can now use the openbao prefix in your configuration:

# Example usage
key: ref+openbao://secret/db#user
  1. Run an OpenBao instance (e.g., via Docker).
  2. Set the environment variable BAO_ADDR and BAO_TOKEN.
  3. Run vals eval on a file containing a ref+bao:// URI.

Following the recent licensing changes to HashiCorp Vault (BSL), many users are transitioning to OpenBao, an open-source community fork under the LF Decentralized Trust. Since OpenBao maintains API compatibility with Vault's core functionality, this implementation leverages the existing Vault logic while allowing users to explicitly define bao as a source.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant