Hardcoded paths in kv_v2.py: "/v1/{mount_point}/data/{path}", mount_point=mount_point, path=path

[WastedAccounts]

Hey team,
I was trying to build a python tool to communicate with vault and ran into an issue the path. After much back and forth with my vault team it turns out that some time in the past they removed /path/ from the configuration. This was causing me permissions failures as /data/ is not there and I don't have permissions if it was. My path is just secret/{myPath}

`hvac.exceptions.Forbidden: 1 error occurred:
* permission denied

, on get https://url.to.vault:8200/v1/secret/data/{myPath}`

I changed the module code to test and was able successfully read secrets. Only tested this on line 150 in kv_v2.py but it's not the only place I see it hardcoded.
api_path = utils.format_url( "/v1/{mount_point}/{path}", mount_point=mount_point, path=path # "/v1/{mount_point}/data/{path}", mount_point=mount_point, path=path )

Is there way to override this?

[briantist]

Hi @WastedAccounts , it sounds like your Vault secret store might be KV version 1 rather than version 2. There is no way to turn off the /data/ portion of the path in v2.

You can check in Vault which version of the KV store it is, or you can confirm with your Vault team if you don't have direct permissions to do so.

In the meantime you may want to try the KVv1 method: https://hvac.readthedocs.io/en/stable/usage/secrets_engines/kv_v1.html#read-a-secret

[WastedAccounts]

Hi @briantist, thanks for responding! I circled back with my Vault team, who, on Friday, assured me we were using v2. Turns out we are on v1 as the change to v2 will break exactly this. Thanks for the v1 link too. I got it working with that code this morning.

[briantist]

Hey @WastedAccounts glad to hear you got that cleared up!

the change to v2 will break exactly this

There is some limited support in hvac for a KV-"agnostic" usage; I haven't used it much and wasn't a maintainer when it was implemented so I'm not strictly sure about any caveats, but it looks like this (first example):
https://hvac.readthedocs.io/en/stable/usage/secrets_engines/kv.html#kv-secrets-engines

So in theory you could set your KV version in one place in your code, and set the default version property on the client, and it would pass through to the correct class.

This would only work for methods and signatures that exist on both though (as far as I can tell), so its use may be somewhat limited.

Here's the code:
https://github.com/hvac/hvac/blob/develop/hvac/api/secrets_engines/kv.py

I think if I were doing it in my own project, I'd implement something similar in the project itself, with a wrapper/intermediate class, that way I could control implementation better, only implement the method(s) I need, and then when the upgrade is done, probably remove it altogether and use KV2 directly... (just some random thoughts)