HashiCorp Vault / OpenBao integration for secret management

[Simonn21]

Description

Closes #2105

AI Usage

Choose the level of AI involvement for this PR.

• Fully vibe coded
• AI-designed, AI-coded, manually checked
• Human-designed, AI-coded
• Human-designed, human-coded (includes AI autocompletions and boilerplate gen)

_{This is not to block AI contributions but rather to speed up PR review (saves time on trying to deduce the logic behind AI hallucinations).}

[Eugeny]

Sorry for taking so long - I'm still overloaded with other tasks and will get to reviewing this ASAP - thanks for contributing!

[theredspoon]

Came across this while reviewing #2397, which also adds Vault integration to Warpgate. Different problem, yours relocates static secrets into Vault's KV store, #2397 replaces static SSH credentials with ephemeral certs, but the two collide mechanically in a few places worth knowing about: both add a crate to the workspace, both extend Services and ConnectionError, both touch SSHTargetAuth. If both land as-is, an operator using both features ends up configuring Vault access twice with incompatible key names for the same auth methods.

Worth knowing directly: your VaultTlsConfig (CA cert, skip-verify) already solves a real gap in #2397, its Vault client has no TLS option at all, so a private-CA Vault deployment can't work with it today. Your hot-reload path solves another, #2397 builds its Vault client once at startup with no reload. And your configurable AppRole/Kubernetes mount paths solve a third gap, for those two methods specifically. #2397 also has AWS/Azure/GCP auth this PR doesn't have, which would need porting over rather than being solved by consuming your layer as-is.

Given that, the cleaner sequencing looks like: this PR's connection/config layer lands first, and #2397 rebases on top of it rather than shipping a second, parallel Vault client, dropping its own transport/token-cache code, porting its AWS/Azure/GCP auth methods into your VaultAuthConfig as new variants, and implementing its certificate-signing call through your existing vaultrs-based pattern. That would make this PR strictly more capable too, since it'd pick up cloud workload identity it doesn't currently have.

Flagging this now mainly so the two efforts don't land independently and end up needing a follow-up migration to reconcile.

[Simonn21]

@Eugeny I've merged the latest main/upstream changes into my branch and resolved the conflicts introduced by the encryption-at-rest and multi-client-SSH-key features. Ready for another review whenever you have time.

[Simonn21]

@Eugeny Just wanted to check in on the status. This feature is actually a blocker for us adopting Warpgate at the moment, so I wanted to ask if there's anything still needed from my side, or if you have a rough idea of when you might get a chance to take a look. No pressure at all, just trying to plan around it. Thanks again for your time!

[Eugeny]

Sorry for keeping you waiting - the only reason is my lack of time - I'm working to release admin session approvals right now and unfortunately this causes incoming PRs to pile up.

The PR looks fine to me - also you storing secret refs as prefixed strings already matches nicely with how encrypted at rest creds are stored right now

If this is the only thing holding you off I would suggest going with a local build. Most likely I will be reviewing and merging this in the second-next release cycle, and will likely change the secret backend config to be stored in the DB instead of the config file, plus dropping // from the serialized secrets to match encrypted-at-rest password format.

You could go into production and later script automatic DB migration once this PR is merged here

(shameless plug: you can also get a support package and let me do it for you - but full disclosure, it won't get this PR merged faster since the 0.29 scope is already locked in)

[Simonn21]

Thank you for your quick and honest response.

I will consider your approach for a local build.