vault
vault copied to clipboard
hashicorp
List all secret paths a user has permission to view
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:
- the policy we've applied to the user Taf policy
path "secret/metadata/taf/*" { capabilities = ["list", "read"] }
path "secret/data/taf/*" { capabilities = ["list", "read"] }
- 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
- can list the secret at the path the policy provides
$ vault kv list secret/taf/
Keys
----
taf/
test
- 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
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
Hi @catsby, do you know if there's an estimation to when (if at all) this issue will be resolved?
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?
+1
This is holding us back as well. We are using role based generators. Without developing systems/documentation to show users what roles (paths) they have access to, users are required to click on each path to see which they can use with trial and error.
+1
Some sort of filtering of list api based on access would be ideal for many resources
+1 From a user's standpoint, it is difficult to hop to every path available and check if the token is accessible. Listing only those which can be accessed will help.
+1 It is also very frustrating and annoying that the presence of this bug is NOT described ANYWHERE in the documentation. I spent about 8 hours in total trying to write appropriate policy and only now I found this ticket
Same as above There should be other way to allow access to the certain engine resources subdirectory. Sadly for now, even 'deny' policy on path listing does not work (according to this issue). If denying listing on path would be a thing, workaround would be pretty easy.
This is a major UX headache. I have written a CLI that performs a tree operation on Vault, and this lets me display which "folders" a user can actually access. However, people primarily access vault via the UI so most of my users are struggling with the "I can see everything, but I don't know which stuff is mine problem."
I'm contemplating writing middleware to sit in front of Vault and strip out paths that the user isn't supposed to see. This seems like something I should be able to express using the policy engine, though. For example, I have now:
path "secret/+/" {
capabilities = ["read", "list"]
}
path "secret/+/project/" {
capabilities = ["read", "list"]
}
path "secret/+/project/* {
capabilities = ["create", "read", "update", "delete", "list"]
}
The policy engine seems to evaluate the path first and then the capabilities are all-or-nothing -- there's currently no way to say "list X in Y", only "list everything in Y".
Perhaps something like this?
path "secret/+/" {
capabilities = ["list"]
allowed_paths = ["project"]
}
There still appears to be no progress on this. Is a solution on the roadmap at least? @hsimon-hashicorp
This is a major UX headache. I have written a CLI that performs a
treeoperation on Vault, and this lets me display which "folders" a user can actually access. However, people primarily access vault via the UI so most of my users are struggling with the "I can see everything, but I don't know which stuff is mine problem."I'm contemplating writing middleware to sit in front of Vault and strip out paths that the user isn't supposed to see. This seems like something I should be able to express using the policy engine, though. For example, I have now:
path "secret/+/" { capabilities = ["read", "list"] } path "secret/+/project/" { capabilities = ["read", "list"] } path "secret/+/project/* { capabilities = ["create", "read", "update", "delete", "list"] }The policy engine seems to evaluate the path first and then the capabilities are all-or-nothing -- there's currently no way to say "list X in Y", only "list everything in Y".
Perhaps something like this?
path "secret/+/" { capabilities = ["list"] allowed_paths = ["project"] }
Posting to hopefully bump this thread again. I feel a solution like this where you can specify allowed_paths would be excellent.
Right now, if folks want to use the Vault UI to access a secret inside of a secret engine, I need to provide list access for the entire secret engine so they can navigate. I feel that this design reveals too much about the secrets in the secret engine that they do not have access to (even if they cannot read them). It also can cause confusion to users thinking they have read access to the other secrets when they really do not.
Maybe there is a counter argument that my secret engine design isn't the best, but I feel this type of functionality would alleviate many headaches and make the Vault UI more user friendly.
Hi folks! Thanks for your interest and discussion around this request. Please know that I am tracking these and doing my best to bubble these up to our product owners, so we can try to provide a better user experience for folks. I don't say this to discourage further discussion, only to let you know that you're not just shouting into the void. :) Thanks for your patience, and I'll be sure to let our engineering teams know that people are still watching this issue!
