Audit Log logging issue when browsing the Web UI in KV Secrets

[agcorreatech]

Describe the bug Through the Web UI, in the KV Secret Engine, if a user navigates to a secret, even not clicking on the eye icon to effectively "read" the value of the secret, the Vault stores in the Audit Log the information that the user has read the secret.

Analyzing the Web UI, even if the user does not click on the eye icon to display the secret, it has already been redeemed and is available in the frontend.

This causes confusion when analyzing the Audit Log... it's impossible to know which users actually read the secret, or which ones are just analyzing the available keys or the structure of the KV Secret.

I believe that the best approach here would be to fetch the secret from the vault only when the user clicks on the eye icon, before that, the secret must not be retrieved from the Vault... only the list of keys.

To Reproduce Steps to reproduce the behavior:

1. Access Vault Web Interface (UI)
2. Navigate to a Secret in KV Secret Engine
3. Don't click on the eye icon to show the secret
4. Analyze the Audit Log and realize that was already logged that the secret was read by the user, even not clicking on the eye icon.

Expected behavior The Audit Log should record that the secret was actually read only when the user clicks on the eye icon.

Environment:

• Vault Server Version (retrieve with vault status): 1.14.0
• Vault CLI Version (retrieve with vault version): Vault v1.14.0 (13a649f860186dffe3f3a4459814d87191efc321), built 2023-06-19T11:40:23Z
• Server Operating System/Architecture: Windows

[maxb]

(Note: I'm not a HashiCorp employee, I'm just a Vault user and sometimes community contributor.)

Let's break this down into two separate components:

Component 1

The entire architecture of the KV secrets engine API is built around working with secrets at paths - in your case here, example/secret. These secrets are natively JSON objects which can have potentially multiple keys - in your case here, key.

Talking about the KV secrets engine frequently gets rather ambiguous, as when a user uses words like "secret" or "key", do they mean the thing at an URL-path (example/secret) or a single key within it (key).

Individually revealing individual keys would require a conceptual jump in design, as currently there is no individual access to keys in the Vault API at all, and consequently they can neither be separately permissioned, nor do the appear separately in the audit log. The API always treats the whole entity at the path as a single thing.

Component 2

On the other hand, some versions back, support for retrieving just the keys within a path, with the values replaced with nulls, was added to Vault: https://developer.hashicorp.com/vault/api-docs/secret/kv/kv-v2#read-secret-subkeys

So, conceptually, the capability is there in the existing API, so that a future UI version could progressively display the keys only, and then fetch all of the values to go with them once any one of them is requested.

---

Bear in mind I don't work for HashiCorp - but if you share your reaction to this breakdown of your initial posting, you may give them more information to work with, when deciding if/when to do any work in this direction.

[heatherezell]

Thank you, @maxb as always :)