Migration Path #20
Comments
|
I think openbao is forked from the 1.14.x tag. So if you stick to that version of vault it should be a drop-in |
|
I think it'd be cool to get some feedback here: https://github.com/orgs/openbao/discussions/21 -- in particular, if we advocate for an API-only compatibility, would this be acceptable? I don't think the project has made any determination on anything, but one of the things mentioned is that we may not support every auth, secret, or storage plugin initially as this is quite a maintenance burden. But we've also not come up with things to remove, yet. |
|
@cipherboy could you clarify more the "api-only compatibility" would cover in your opinion? Dropping things will be a challenge, this would lock potential users from migrating, so not sure if there is a correct path here, since it's also not good to over extend the current capabilities of the project ... I think free software/open source solutions should have priority, for example for storage backends, between MSSQL and PostgreSQL supporting PostgreSQL should have a higher priority. In a more technical decision ha storage backends should have a higher priority over non-ha. Maybe it would also be interesting to build the list from the common deployments. |
|
@thuck With a caveat this is under discussion and no consensus has been reached... And intending to use this as part of said discussion and everyone's feedback is appreciated here. I mentioned this topic on last week's call to start bringing it up... :-) Likely API compatibility would entail API access to plugins we decide to support remaining the same. Existing workloads (using a supported subset of plugins) could be pointed interchangeably between upstream and OpenBao, but perhaps a migration needs to be done manually by the instance operator to switch, and may not even be a replace-the-binary type migration (i.e., in-place upgrade). I've expanded on the three migration paths on the matrix chat room. Some of the benefits of not guaranteeing storage-level compatibility with upstream would be that we're free to make major changes in implementation, in the interest of maintainability or feature development. Some potential ideas include simplifying or changing the barrier seal mechanism (which sits on top of storage) to rewrite and modernize it. Or, if we want to tackle some long-standing upstream issues (e.g., paginated list operations or transactional storage semantics), these are made substantially harder having to support N different storage backends. Some of these are already implemented for certain backends (e.g., Raft backend the only officially supported one) because Consul has these features but our upstream doesn't. In particular, (bidirectional) storage compatibility is rather hard to support: for every storage plugin, we'd have to guarantee upstream and OpenBao behave the same. Simplifying this to upstream->OpenBao migration does not meaningfully simplify it much (given you have the capability of testing one direction, testing the other should be easy, but we currently lack this capability -- someone would have to write rather extensive tests). Further, we'd have to then test every single auth and secrets plugin (that both upstream and us supports) to ensure for the forked plugins, we've not modified their behavior at all in an incompatible manner. All this to say, it could potentially require a rather exhaustive (though, beneficial!) test suite. One of the compounding issues in particular is that upstream hasn't really supported these various backends. Sure, PostgreSQL is a great database, but rather few run it in protection (in no large part because upstream didn't support it in its Enterprise offering). This makes understanding the state of these storage plugins hard. While they may work in some scenarios, they may not be production ready. I'd personally be hesitant to use e.g., the linked Google Cloud Storage... My 2c. |
|
@cipherboy It would be interesting to understand what an ideal deployment looks like for y'all, that's probably a good start point, or ideal scenario in the most common type of deployments. Do you have a link to the functionalities that are supported by Vault Enterprise? It would be good to link it here, I'm not sure what is considered public information or not on this that regard. Should another ticket be created with a task list of all storage/auth/secrets and a use it as a way to select what will/won't be kept? |
|
@thuck If you click through the sub-headers on this link you'll see a comment about support: https://developer.hashicorp.com/vault/docs/configuration/storage For instance, these are what I'd call non-production quality backends:
The only officially supported (IMO production quality) backends are:
The implication being that all the others, by virtue of not having clustering support and/or official HashiCorp support, would not have been used in an Enterprise setting, and thus likely see less production use outside of individuals running OSS. I've known some individuals to run, e.g., OSS+etcd for instance (based on GH issues filed), but they've had some issues around its interactions with storage persistence versus ours. A lot of HashiCorp written plugins assume Raft's model (since it also underpins Consul). IMO, the built-in Raft backend (https://github.com/hashicorp/raft) remains MPLv2 and thus would make an ideal candidate as the only supported backend, given the selection criteria I outlined (upstream supported, supports HA/clustering). This is, unless the community wishes to explicitly maintain specific other plugins to the level of quality of Raft. If we have volunteers, this likely will be an easier conversation to have. :-) |
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
|
Just a note for followers here, #53 was the accepted proposal for deprecation policy, #64 was the accepted proposal for supported plugins, and #55 was the proposed policy for migration path (not yet accepted, wanted to wait until #64 was -- likely we'll bring it up on the community call this Thursday to discuss). |
I think one key factor for the adoption of openBao is documentation/tools that would allow a migration from Vault.
I assume that y'all will try to use the same approach as openTofu and try to have a drop-in replacement, but that begs the question, which version of Vault should I target to be my final upgrade?
The text was updated successfully, but these errors were encountered: