Vault policy write only + read parameters too

Hi,
(I am talking about kv2)

In trying to give the least possible access to our team to manage their secrets I wanted to let them only write/update secrets.

However, this brings us to the point that when they would like update a secret they will effectively need to know all the key/value pairs of that secret.

If you have r/w access to a secret then the GUI fills everything nicely in and you know which keys there are.

It would be nice if it would be possible to give access that it lists the keys but not the values.

I saw that you can patch a secret on the CLI so that would at least make it unnecessary to know all the key/values you don’t want to change. but the GUI doesn’t allow this.

Is it even possible? Or should I approach it differently: “you shouldn’t do it like that!”?

This is the policy I set:

path “appsecret/data/myapp” {
capabilities = [“read”]
}

So, there is already a question about this, now I saw:

If secrets have different desired level of access they should be different paths. A path is always handled as an atomic unit (so anyone with read or write can change everything). So it is always best to split things that might be used or updated at different points (e.g. have two paths for credentials for two apps/services instead of putting them as different keys in a single path).

Hi @stuart-c ,

I now see that I pasted the wrong policy. This Is what I have:

path “appsecret/myapp” {
capabilities = [“write”]
}

Through the GUI we can only write new versions. Which is what we want, we shouldn’t be able to read the secrets.

However, updating the secret becomes very tedious. As you need to know every key/value in the secret.

It would be nice if this would exist:

path “appsecret/myapp” {
capabilities = [“write”]
read_parameters = [ 'key1', 'key2']
}

Meaning that you can view the key values key1 and key2 in a secret, but the secret value itself.

or

path “appsecret/myapp” {
capabilities = [“write”]
read_parameters = ['*']
}
allow reading all the key values.


I do follow that splitting it up based on usage or updated frequency is a good way to go.

If you’re using 1.9, they now have a PATCH option that you can use to “add” more kv entries to a secret without reading and writing the whole secret again.

Ah thanks @aram . I saw the patch in the kv help, but didn’t know (well it looks I forgot!) it was new. I tried it and that failed. Ofcourse, now I saw that you need to add the patch ACL!
I’m going to try this!