Vault Policy & Web GUI

Vault
1

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.

2

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: )

3

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"]
}
3 Likes
4

Solution provided by @markski2 seems to do the trick.

5

DISCLAIMER: SOLVED

We’re actually using KVv2 and thus need the kv/data/ prefix :man_facepalming:

Hey guys :wave:
I happen to have exactly the same issues over here.

Auth: LDAP

Here’s the policy:

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

Created and applied to the LDAP group like this:

$ vault policy write team-myteam policies/myteam.hcl
Success! Uploaded policy: team-myteam

$ vault write auth/ldap/groups/team.myteam policies=team-myteam
Success! Data written to: auth/ldap/groups/team.myteam

Then I login with my LDAP user that’s in that group: vault login -method=ldap username=myuser

I retrieve the token from the output and test it:

$ VAULT_TOKEN=mytoken vault kv list kv/teams/myteam/
Keys
----
test

# BUT

VAULT_TOKEN=mytoken vault kv get kv/teams/myteam/test
Error reading kv/data/teams/myteam/test: Error making API request.

URL: GET https://vault.my.domain/v1/kv/data/teams/myteam/test
Code: 403. Errors:

* 1 error occurred:
	* permission denied

So I go with the root account to check the token capabilities and everything looks good:

vault token capabilities mytoken kv/                                    
list

$ vault token capabilities mytoken kv/teams/mytoken/
create, delete, list, read, update

$ vault token capabilities mytoken kv/teams/mytoken/test
create, delete, list, read, update

As a sidenote: if I add read capabilities to kv/*, this also applies in the subfolders.

I hope that someone can give me a hint on what’s wrong here, as I’m trying to get this set up for two days now…

Thanks in advance!

6

Check my solution above and also the docs for https://www.vaultproject.io/docs/secrets/kv/kv-v2 under “ACL Rules”. Basically in the kv-v2 engine the first node after the engine name is a prefix (e.g. data, metadata, delete, undelete, destroy) rather than the first node of the secret path. So your second policy path would need to be kv/+/teams/myteam/* if you wanted to allow full access to “kv/teams/myteam/*” secret paths.

1 Like