KV v2 credentials wrong path

[d-zalewski]

Hi,

I have kv v2 credential defined with a namespace in the path which jenkins can't seem to be able to access. Upon inspection I can see that it is trying to get the secret from wrong path. It's adding adding data in wrong place in the URL.

Secret path: my-namespace/kv/jenkins/common/github

I can see in vault logs that it tries to hit /v1/my-namespace/data/kv/jenkins/common/github where correct path should be /v1/my-namespace/kv/data/jenkins/common/github In order to get kv v2 secrets, data should be included in the path right after kv eg.: /v1//kv/data/

Accessing kv v1 secrets with namespace in the path works fine.

[jetersen]

See https://github.com/jenkinsci/hashicorp-vault-plugin/issues/112#issuecomment-679699388

[jr200]

Hi, I have the same issue, but I am trying to use the Jenkins JCasC YAML configuration. I have set CASC_VAULT_ENGINE_VERSION=2, and tried various values of the CASC_VAULT_PATHS variable.

My vault setup is as follows. The v2 KV engine is mounted at the path: uat/kv The secret value is under the key: someapp/abcd/THE_SECRET

So, I would like to extract the value at this path:

uat/kv/data/myapp/abcd/THE_SECRET

However, I see queries in my vault audit logs for:

uat/data/kv/myapp/abcd/THE_SECRET

[jetersen]

@jr200 you have to use CASC_VAULT_NAMESPACE

[jr200]

I had a look at this, but it doesn't extend to the more general use-case. I have a number of v2 KV engines mounted at different paths.

uat/kv shared/kv ...

And a number of nested keys I would like Jenkins to access under each of these KVs. I guess the current JCasC implementation will only work with one v2 KV engine (though it does work with multiple v1 KV engines).

[jetersen]

I can't help in case of advanced use cases. I myself have no need for namespaces or multiple kv stores, it seems like an anti pattern in vault as you would want to use generated temporary tokens. if anything this shows that this plugin needs to be completely rewritten if it were to support all the scary ways people setup vault.

[jr200]

Thanks for confirming @jetersen.

A complete rewrite might not be necessary, since access to /sys/mounts would provide sufficient information to infer the full secrets path. Indeed I spotted a hopeful comment in the readme hinting at an 'auto-detect' mode in the underlying bettercloud/vault-java-driver library: "You can rely on the Vault Driver to auto-detect your mounts and K/V versions upon instantiation..."

But a closer inspection of that code suggests this is not plumbed in fully yet.