What does this MR do and why?
Currently, all streaming audit events have a very similar data structure without a key that is easily identifiable without going through each request body and filtering based on values contained in the details object, and specifically the custom_messages object.
We have an Auditor class that accepts a name parameter, which is currently only used for error tracking.
This MR uses that same name to be sent as a header for each streaming audit event, so that customers can filter based on the different values in the header (denoting different types/categories of audit events) and process them accordingly.
This can be seen as a precursor for Allow filtering of streamed audit events (&6980).
Furthermore, this updates our auditing of repository git operations to use ::Gitlab::Audit::Auditor, which per our development docs is the recommended approach:
This inconsistency leads to unexpected bugs, increases maintainer effort, and worsens the developer experience. Therefore, we suggest you use Gitlab::Audit::Auditor to instrument new audit events.
Screenshots or screen recordings
How to set up and validate locally
- Enable stream git operations audit events
Feature.enable(:audit_event_streaming_git_operations) - Set up an audit event destination
- Clone/pull/push any repo and validate the response header with the HTTP collector, e.g., requestbin/pipedream, of your choosing.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.