Add custom metadata to data responses

[ccapurso]

Overview

This PR extends KVv2's key metadata field custom_metadata to the CreateOperation, ReadOperation, and PatchOperation responses for the /<mount>/data/:path endpoint. Extending this field to other endpoints allows for better auditing capability.

There is an associated implicit change in ACL semantics in that the field is available to the data endpoint independent of the calling token's ACLs (i.e. read access to /<mount>/metadata/:path). This concept has been mentioned in a separate docs PR.

Design of Change

The CreateOperation, ReadOperation, and PatchOperation handlers already access the secret's key metadata. The field will simply be added to the logical.Response for these handlers. It should also be noted that this field will automatically be included in the CLI output and has been verified in Vault PR #12907.

Related Issues/Pull Requests

• CLI test updates PR #12907
• Docs PR #12920

[raskchanky]

There is an associated implicit change in ACL semantics in that the field is available to the data endpoint independent of the calling token's ACLs (i.e. read access to //metadata/:path).

I'm curious if this is by design or an unavoidable side effect of something else. Are customers likely to be surprised if they issue a token that does not have read access to the metadata endpoint but find metadata present in the data response?

[ccapurso]

I'm curious if this is by design or an unavoidable side effect of something else. Are customers likely to be surprised if they issue a token that does not have read access to the metadata endpoint but find metadata present in the data response?

@raskchanky, this was discussed internally and it was determined that there wasn't a big security concern of providing this information as custom_metadata contains less sensitive information than the secret itself. We did discuss the potential for configuring the backend to enable/disable this functionality but will not be implementing anything like that at this time.