Handle v2 storage engine paths properly. #8
+285
−6
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Mimic vault CLI logic. Query vault API for mount version; if v2, rewrite
to include the internal data segment right after mount point.
Additionally, wrap type assertion on data field to only occur if v2.
Background
With the v2 storage engine, secret paths look different to Vault users (e.g. from the CLI) and the Vault API (e.g. the vault "logical client"). You might read a secret with
vault kv get mount/v2/secret
, but the actual API URL needs to behttps://vault.example.com/v1/mount/v2/data/secret
-- note the inserted 'data' segment.This plugin currently has no notion of that rewrite logic; as a result, plugin users have to be aware of vault internals and know how to rewrite the secret -- specifically, they'd have to refer to the above secret as
mount/v2/data/secret
for it to work.This PR fixes the logic by mimicking the CLI's logic and discovering the corresponding version of the mount, and deciding whether or not to rewrite it.
Why Vault did their V2 engine this way, I can't say.