VAULT-38846: Add attribution data to secret version metadata#206
VAULT-38846: Add attribution data to secret version metadata#206
Conversation
path_data.go
Outdated
| attributionWarning = append(attributionWarning, "no entity id found") | ||
| } | ||
|
|
||
| attr := &Attribution{ |
There was a problem hiding this comment.
Sorry for the drop-in comment here but would it make sense to include client ID as well? Just especially thinking about non-entity clients, obviously it's the same as clientId for entities.
There was a problem hiding this comment.
@VioletHynes we've got a separate Jira to track non-entity attribution (for root/batch tokens). We were thinking of providing the token issue time and token type to facilitate further lookup. ClientID might be the perfect substitute for that though. @davidadeleon and I are still deciding if we want to address that in a separate PR since the work is tracked elsewhere and basically an improvement to the actor/DisplayName for specific types of auth.
There was a problem hiding this comment.
Thanks for the extra context! I do think it makes sense to have clientId somewhere in the attribution, but if it's coming in a later PR then that's perfectly fine by me :)
Co-authored-by: Mike Palmiotto <mike@p4lm.io>
3 participants
Overview
This PR enhances secret version metadata to include attribution data. This allows operators and users who have access to the secret to be able to identify what operation caused a version of a secret along with a display_name and entity_id of who performed that operation.
Design of Change
A new attribution struct has been created that gets populated from the logical request. This struct gets passed as part of the version creation call which then has its field stored as part of the secret version metadata.
Related Issues/Pull Requests
N/A
Contributor Checklist
[ ] Add relevant docs to upstream Vault repository, or sufficient reasoning why docs won’t be added yet
My Docs PR Link
Example
[ ] Add output for any tests not ran in CI to the PR description (eg, acceptance tests)
[ ] Backwards compatible
[ ] Changelog entry added. See Updating the Changelog.
PCI review checklist
Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.