Vault: Vault list should only show paths if user (token) has access to a secret in that path

[drewmullen]

I have a hashi ticket opened with this information: https://support.hashicorp.com/hc/en-us/requests/10584 I tried to adapt the ticket info here so please let me know if something is unclear

Is your feature request related to a problem? Please describe.
Currently, for our users to be able to navigate the vault GUI, we need to apply path "secret/*" { capabilities = ["list"] } to that user. Without it, they receive an error after they click into the secret engine (see pic). However, when we grant that permission, the user can then list ALL secrets. From a user stand point, this is confusing because they can list every secret in our vault but cannot access the actual secret.

Describe the solution you'd like
it would be great for our users to be able to list (view in the gui) only secret paths that they have access to and not see secret paths if they dont have access.

Describe alternatives you've considered
Cant think of any.. probably the current solution is the only other alternative: grant secret/* list

Explain any additional use-cases
We're using 0.11 enterprise preimum + hsm with a kv2 secret engine. The guide ive been following is: https://www.vaultproject.io/docs/secrets/kv/kv-v2.html#acl-rules and https://support.hashicorp.com/hc/en-us/articles/360000953148-Vault-UI-Secrets-Navigation

In the example below, ive also tried in the CLI with the same results:

1. the policy we've applied to the user
   Taf policy

path "secret/metadata/taf/*" { capabilities = ["list", "read"] }
path "secret/data/taf/*" { capabilities = ["list", "read"] }

1. a secret exists at the end of that path

$ vault kv get secret/taf/test 
====== Metadata ====== 
Key Value 
--- ----- 
created_time 2018-09-12T13:25:57.871481033Z 
deletion_time n/a 
destroyed false 
version 1

====== Data ====== 
Key Value 
--- ----- 
test_key value

1. can list the secret at the path the policy provides

$ vault kv list secret/taf/ 
Keys 
---- 
taf/ 
test

1. we can not list at the root secret level <-- as i understand, this is what the GUI does when you click through past the secret engine

$ vault kv list secret/ 
Error listing secret/metadata: Error making API request.

URL: GET https://<ip>:8200/v1/secret/metadata?list=true 
Code: 403. Errors:

* 1 error occurred:

* permission denied

[servergeeks]

+1

[SanghmitraJohri]

I am also facing the same issue. Any update on this?

[mfuxi]

I'm facing the same issue as well, a workaround for this issue is to supply manually the secret path in the URL, like this:
secret/list/foo

[royt-via]

Hi @catsby, do you know if there's an estimation to when (if at all) this issue will be resolved?

[rfc1459]

This issue seriously limits the usefulness of Vault usage by humans because they would have to remember the path to each and every secret they have access to or the organization should give blanket list permissions to every human user (which might be unacceptable in some contexts and would create needless confusion among users).

By reading other issues about similar requests it seems that the stated position regarding policies is that filtering API replies using them will not be implemented. Is that position still standing? And if so, how is this specific issue going to be fixed if replies cannot be filtered?