Vault Policy & Web GUI

New to Vault here and trying to setup some policy which will allow my different user LDAP groups to access various top level kv-v2 paths (mainly from the Web GUI). I’ve created a policy below (definitely redundant a little, but just trying to get something working here):

path "kv" {
  		capabilities = ["read", "list"]
}
path "kv/" {
  		capabilities = ["read", "list"]
}
path "kv/linux" {
  		capabilities = ["create", "read", "update", "delete", "list"]
}
path "kv/linux/" {
  		capabilities = ["create", "read", "update", "delete", "list"]
}
path "kv/linux/*" {
  		capabilities = ["create", "read", "update", "delete", "list"]
}

$ vault policy write kv-combined kv-combined.hcl
Success! Uploaded policy: kv-combined

$ vault write "auth/ldap/groups/linux-admin" policies="kv-combined"
Success! Data written to: auth/ldap/groups/linux-admin

$ vault token capabilities <token> kv
list, read
$ vault token capabilities <token> kv/
list, read
$ vault token capabilities <token> kv/linux
create, delete, list, read, update
$ vault token capabilities <token> kv/linux/
create, delete, list, read, update
$ vault token capabilities <token> kv/linux/foo
create, delete, list, read, update

So pulling a token out of a Web GUI login and checking with “vault token capabilities” looks good on the command line, but in the Web GUI itself I’m still getting a “Not authorized” error on “kv/”. The point of adding read/list at the kv/ level was so people could click through to their own path, but that doesn’t seem to be working properly.

I would also add that attempting a “vault kv put kv/linux/foo” to that path also fails on the command line, so it seems I’m missing something with regards to that policy and the output of the capabilities command.

At what point do you get the error in the Web UI?

Could it be that the web UI is trying to list all secrets engines, and receives a “Not authorized” because you don’t have permission for that?

(Just guessing here, but I’m going to try to reproduce it on my homelab Vault instance. Seems like a fun thing to tackle :smiley: )

Looks like with kv-v2 you need to specify your policy at the first level API prefix (not just the path to data as in v 1). So something like this will work as expected:

path "kv/data/*" {
  		capabilities = ["read", "list"]
}
path "kv/metadata/*" {
  		capabilities = ["read", "list"]
}
path "kv/data/linux/*" {
  		capabilities = ["create", "read", "update", "delete", "list"]
}
path "kv/metadata/linux/*" {
  		capabilities = ["create", "read", "update", "delete", "list"]
}
2 Likes

Solution provided by @markski2 seems to do the trick.