BetterCloud / vault-java-driver

Zero-dependency Java client for HashiCorp's Vault
https://bettercloud.github.io/vault-java-driver/
335 stars 224 forks source link

Handling KVv2 and custom mount paths like official vault CLI tooling #202

Open rimitchell opened 4 years ago

rimitchell commented 4 years ago

In a lot of scenarios a user of this library may not have access to update permissions to be able to read the /v1/sys/mounts path and or it may be included in other libraries which do not expose either the engine version or the path prefix depth functionality that was recently added.

It would be ideal if the driver mimicked how the vault CLI's works by issuing a preflight query (see: https://github.com/hashicorp/vault/blob/master/command/kv_helpers.go#L44) to determine if a specific path is V1 or V2 and to get the mount path for the specific secret path. This would simplify the configuration of this library and allow the same paths that are provided to the vault command line tool to be used with this without the user needing to know any extra details.

Is this something that the maintainers are interested in incorporating?

My co-workers and I need the mount path support before it was added so I have a fork (https://github.com/rimitchell/vault-java-driver/tree/feature/query_vault_kv_version) containing this preflight work against the older 4.2.0 release. I am currently in the process of fixing things it against the latest release (5.1.0) (https://github.com/rimitchell/vault-java-driver/tree/feature/kvPreflight)

I've created this issue first instead of a PR as stated in the README.md because my fork changes the external contract of the library.

thenoid commented 4 years ago

👍 we too are running into this issue

rtib commented 4 years ago

On the other hand, consider the different usage patterns of this library and the CLI. While the CLI is called on the command line relatively rare, it is allowed to amplify the amount of ReST requests it makes to access a KV2 object. For a library used by some application, which probably does requests at a high rate (possibly deployed in many instances), it is highly unfavourable to double the amount of requests it makes to a KV2, just to find out the prefix length every time.