New role to read keys of secrets but not the values

[georgeamason]

Is your feature request related to a problem? Please describe.
In our org we have two paths under a particular secrets engine; those being prod and staging. We have full access to the staging path i.e. we can read and view all secret information - keys and values. With the prod path we can't view either the secret key or value. We have to ask our internal infra team to let us know what the keys of the secrets are. We don't ever want to be able to see the secret values, just the keys.

Describe the solution you'd like
Add an extra role that can be assigned to users for viewing the keys of secrets.

Describe alternatives you've considered
With the advent of v2 engines, we have used metadata to display the keys that are available under a certain secret path but v1 engine has no metadata.

Explain any additional use-cases
N/a

Additional context
{
"AdminUsr" : "joe.blogs",
"AdminPwd": "super-secret"
}
Add a role to only allow viewing AdminUser and AdminPwd

[dosubot]

Hi @georgeamason! I'm Dosu and I'm helping the HashiCorp, an IBM Company team.

This has been requested before — GitHub Issue #3286 covered essentially the same ask (field-level read restrictions in policies) [1]. That issue was open from 2017 to 2022 and was closed without implementation. A HashiCorp maintainer noted there were no plans to add field-level ACL controls, as Vault's policy model operates at the path level, not the field level within a secret [1].

Workarounds suggested by the team:

1. Split secrets by path — store keys that different audiences need to see at different paths, and grant read access per path via policy.
2. KV v2 metadata (which you've already discovered) — metadata can expose field names without the values, but this only applies to KV v2.

For your KV v1 use case specifically, the recommended approach is to reorganize secrets so that field names you want visible to your team live at a path they can list or read separately from the actual secret values.

That said, this is a valid feature request and it may be worth the product team re-evaluating given the time since #3286 was closed. Tagging @heatherezell to flag this for product and engineering review.

Written by @dosu, approved by heatherezell

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[heatherezell]

I checked with our teams, and unfortunately we aren't adding new features to kvv1. The guidance remains to use kvv2 for this capability. Thanks!