OpenBao additional repository fork requirements

repos.md

Code dependencies

repository	should fork	description
github.com/hashicorp/go-kms-wrapping	Yes	Low level cryptography for barrier. Also has support for auto-unseal with some external KMS providers. Connects to transit plugin, hence hashicorp/vault/api dependency needs to be updated in go-kms-wrapping/wrappers/transit.
github.com/hashicorp/consul-template	Yes	Template renderer similar to e.g., k8s templating used in agent; connects back to Vault API so requires hashicorp/vault/api which needs to be replaced.
github.com/hashicorp/vault-testing-stepwise	Either fork or move in repo	Testing helpers for stepwise/CRUD tests of plugins. Was split into external repo for unknown reasons, maybe to help now-removed testing of out-of-repo builtin plugins?
github.com/hashicorp/go-secure-stdlib	Yes	This library is used in many places for parsing (at the CLI and plugin level) and contains many useful utility functions. They were originally forked out of Vault so Boundary could use them.

Plugins

Plugins are largely self explanatory. My view is we should likely remove these if no maintainer steps up, but if we get a willing maintainer, we should consider building them as external, stand-alone plugins if possible (perhaps not possible with database plugins), but if not, built it into our binary.

The only place where this might cause issue is the jwt auth plugin is used for some tests (TestAgent_ExitAfterAuth), so might be better off being forked rather than removed entirely. Or, the obvious case where someone is using these plugins directly, which we wouldn't be able to tell from looking at our code base. :-)

Additionally, we should consider removing any builtin, deprecated plugins if they exist.

Auth

Auth plugins allow the specified external service (e.g., ALI cloud, Azure, ...) to control the exchange credentials valid on its service for tokens valid on the Bao instance. E.g., the vault-plugin-auth-kerberos plugin uses the Kerberos protocol to authenticate the client and then issue a Bao token which the client uses on subsequent requests.

repository
github.com/hashicorp/vault-plugin-auth-alicloud
github.com/hashicorp/vault-plugin-auth-azure
github.com/hashicorp/vault-plugin-auth-centrify
github.com/hashicorp/vault-plugin-auth-cf
github.com/hashicorp/vault-plugin-auth-gcp
github.com/hashicorp/vault-plugin-auth-jwt
github.com/hashicorp/vault-plugin-auth-kerberos
github.com/hashicorp/vault-plugin-auth-kubernetes
github.com/hashicorp/vault-plugin-auth-oci

Database

Database plugins allow Bao to issue credentials valid on the database server of the specified type (e.g., redis, couchdb, ...). This allows anyone with a Vault token (from authentication) to authenticate to the specified database instance (usually, one plugin per database instance I believe). Handles creation and expiration/revocation of temporary, dynamically generated credentials.

The core database plugin itself is a secrets plugin, but it has various backend providers behind the scenes which help support creating credentials particular databases.

repository
github.com/hashicorp/vault-plugin-database-couchbase
github.com/hashicorp/vault-plugin-database-elasticsearch
github.com/hashicorp/vault-plugin-database-mongodbatlas
github.com/hashicorp/vault-plugin-database-redis
github.com/hashicorp/vault-plugin-database-redis-elasticache
github.com/hashicorp/vault-plugin-database-snowflake

Secrets

Various other types of secrets engines; these hand out secrets of various sorts. E.g., the vault-plugin-secrets-alicloud plugin allows anyone with a Vault token to get a short lived credential to operate in the cloud environment. Or the PKI plugin (builtin, not listed below), which mints fresh leaf certificates.

repository
github.com/hashicorp/vault-plugin-secrets-ad
github.com/hashicorp/vault-plugin-secrets-alicloud
github.com/hashicorp/vault-plugin-secrets-azure
github.com/hashicorp/vault-plugin-secrets-gcp
github.com/hashicorp/vault-plugin-secrets-gcpkms
github.com/hashicorp/vault-plugin-secrets-kubernetes
github.com/hashicorp/vault-plugin-secrets-mongodbatlas
github.com/hashicorp/vault-plugin-secrets-openldap
github.com/hashicorp/vault-plugin-secrets-terraform

Storage

Storage plugins are all presently under openbao/physical; none are external-repo. Some of these could be candidates for removal, e.g., aerospike, alicloudoss, azure, cassandra, cockroachdb, couchdb, dynamodb, etcd, or foundationdb

We also need to fork the Vault SSH helper if we plan on supporting the SSH secret Engine:
https://github.com/hashicorp/vault-ssh-helper

@JanMa Do we need to? It is an external binary not used as part of the bao binary build process. I believe, and I might be wrong, but as long as we (and upstream) do not modify the api.SSHelper struct definition and do not break API compatibility (on the server side), we can avoid this. And, upstream's should remain compatible with our server.

In general, where there's a compatibility reason to do so (e.g., used as part of the build binary and brings in upstream's post-fork versions of api/ or sdk/), I'd recommend forking. Things like language-specific OpenAPI client libraries are (or, really, aught to be) generated and versioned along side the bao binary/version, and so should also be forked. But broader ecosystem packages which are not built into the binary (and interoperate on an API level) may not need to be included in the first pass.

From a branding perspective as a fork, it could be useful to do, for all of those broader packages, but I think that's also better to worry about later, if/when we grow as a community to have the resources to do.

Thoughts?

I guess you're right. So far I was under the impression we would also fork everything that is mentioned in the docs, even if it is not necessarily needed to build OpenBao, for branding reasons. So from a purely technical perspective we don't need to fork it and our SSH engine would still work with the upstream helper script as long as we are API compatible.

I agree with you that we can link to the upstream version for now. But down the road I'd prefer to fork all relevant ecosystem packages as well so we can make a clean cut between OpenBao and Vault.