UI navigation requesting `GET secrets/config` for kv mount and failing

[bmendric]

Describe the bug Navigation, via the UI, through a KV secrets mount point causes repeated calls to the secrets/config endpoint. Three areas of concern here:

1. I cannot find documentation describing why read access to the endpoint is necessary (my guess is for displaying max version information?)
2. We are correctly failing the permission check (ie the token does not have access to the endpoint), but it is strange we are retrying at (almost) every API request.
3. The below capture shows that we are querying the resultant-acl API which also does not list the token as having capabilities on secrets/config, so it is interesting we are querying it in the first place.

To Reproduce Steps to reproduce the behavior:

1. Create a KV secrets store with some data (possibly restricted to kv-v2?)
2. Create a token with a policy granting list permissions on secrets/metadata/* (in order to access it via the UI) -- Important to not include the secrets/config read permission
3. Navigate the UI, using the generated token.

Almost every navigation through the KV mount will trigger an API call to secrets/config which will 403 due to a lack of permissions. However, this does not seem to impact the UI experience and does not display to the user (check audit logs or network captures as above)

Expected behavior I would expect two things here:

1. Some documentation saying that this permission is necessary for full/complete user experience in navigating the KV mounts in the UI and describing why the permission is necessary (i.e. what it allows the UI to do for the user). Admittedly, I didn't spend a huge amount of time looking for documentation on this, so it might exist
2. Since the UI workflow already appears to be querying sys/internal/ui/resultant-acl, I would expect the process attempting to query secrets/config to leverage the resultant-acl, see the token does not have permissions, and simply not make the request. I think it would also be acceptable for the GET secrets/config to happen once to see/receive the 403 and then have the result cached and not queried again on that mount point.

The main issue here is that our audit logs contained a number of these requests, all 403'ing, and I would like that not to happen. For our environment, we are fine to simply add read access for secrets/config to some our policies, but this was still unexpected behavior and I felt deserved some documentation/discussion.

Environment:

• Vault Server Version (retrieve with vault status): 1.10.4
• Vault CLI Version (retrieve with vault version): 1.11.0
• Server Operating System/Architecture: Ubuntu 18.04 x86_64 running Vault within a container

Vault server configuration file(s): Can provide if needed, but does not seem relevant

Additional context Add any other context about the problem here.