Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kv2.patch() function requires get capability #925

Open
rakshitzen opened this issue Dec 13, 2022 · 2 comments
Open

kv2.patch() function requires get capability #925

rakshitzen opened this issue Dec 13, 2022 · 2 comments
Assignees
Labels
enhancement a new feature or addition help wanted Contributions welcome! kv Key/Value (KV) secrets engine secrets engines generally related to a Vault secrets engine

Comments

@rakshitzen
Copy link

rakshitzen commented Dec 13, 2022

The patch function in hvac requires the get role capability in associated policy to run successfully, which shouldn't be the case. The patch capability should be enough to run the patch function(vault kv patch works as expected with the patch capability role).

Screenshot of the error:
Screenshot 2022-12-13 at 5 24 54 AM

@rakshitzen rakshitzen changed the title kv2.patch() function doesn't work as expected kv2.patch() function requires get capability Dec 13, 2022
@briantist briantist added the enhancement a new feature or addition label Mar 4, 2023
@briantist briantist self-assigned this Mar 4, 2023
@briantist briantist added the kv Key/Value (KV) secrets engine label Mar 4, 2023
@briantist
Copy link
Contributor

Hi @rakshitzen ! This has been on my radar recently too:

Vault did not originally support server-side patch, and the CLI always did the same thing that hvac does now (read secret, write modified secret) on a "patch" operation.

Vault server and the CLI have been updated, and now both methods are supported:
https://developer.hashicorp.com/vault/docs/secrets/kv/kv-v2

Partial updates can be accomplished using the vault kv patch command. A command will initially attempt an HTTP PATCH request which requires the patch ACL capability. The PATCH request will fail if the token used is associated with a policy that does not contain the patch capability. In this case the command will perform a read, local update, and subsequent write which require both the read and update ACL capabilities.

and

The vault kv patch command also supports a -method flag which can be used to specify HTTP PATCH or read-then-write. The supported values are patch and rw for HTTP PATCH and read-then-write, respectively.

So the situation right now is that we need to update hvac's capabilities to support the server-side PATCH method, but we also have to keep support for the two-step process because the ACL capabilities required for each are different.

We should probably provide similar flexibility to the CLI, in that we should support explicitly specifying which patch method to use, and optionally we may want to support a similar graceful degradation (try PATCH, if permission denied, try two-step), though I think we will want to provide a way to set a wider default for this option too.


I will consider this issue to be the feature request for the above, since I was intending to write this up anyway!

If you are interested in contributing this functionality, see CONTRIBUTING (this file could probably use updating but it's a start) and let us know!

@briantist
Copy link
Contributor

It seems that one additional thing that server-side patch supports is nested dictionary patching. That isn't replicated by the current method.

I am wondering if the Vault CLI's client-side patch also patches nested dictionary keys or not. If it does, the existing functionality in hvac is not equivalent to that, and we might consider that a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement a new feature or addition help wanted Contributions welcome! kv Key/Value (KV) secrets engine secrets engines generally related to a Vault secrets engine
Projects
None yet
Development

No branches or pull requests

2 participants