Skip to content

Implement proper attribution to deploy token audit events

Dennis Tang requested to merge dennis-add-deploy-token-author into master

What does this MR do and why?

This MR adds a new type of NullAuthor to be able to properly attribute audit events to actions triggered by deploy tokens.

Specifically, when a git operation such as a pull is done via a deploy token, we can see specifically the deploy token name used in the audit event details. We can also see the newly added header x-gitlab-audit-event-type implemented via !86881 (merged)

Streaming audit event with attribution to deploy token
image

Why not show the creator of the deploy token instead?

We already tried this, and it doesn't solve the issue fully.

  1. Identifying the creator of a DeployToken was only recently added, only taking effect for deploy tokens created since this change was implemented. We would need to backfill this data and at this point it's unrealistic to be able to because...
  2. When a creator is deleted the creator_id is set to NULL, so we wouldn't have a complete picture of this anyhow.

More importantly, showing the creator of the deploy token hides the fact that a deploy token was used in the first place.

If we show that a deploy token is used, we can use that information to work our way through the audit trail to see who created the deploy token in the first place:

Streaming audit event of a deploy token being created
Bildschirmfoto_2022-05-09_um_17.37.29

Why did we create another type of NullAuthor? Why id = -2?

If we didn't, we would be passing the ID of the deploy token as the author.id.

This causes problems because the audit event build service will then instantiate AuditEvent and then load and replace author information using the wrong ID, mistaking the deploy token ID as a user ID. This would be bad as the resulting audit event would then list an entirely different user's name attributed to that audit event.

NullAuthor solves for this for a number of other use cases already, so we just use the same implementation.

How to set up and validate locally

  1. Enable stream git operations audit events 
    Feature.enable(:audit_event_streaming_git_operations)
  2. Set up an audit event destination
  3. Create a deploy token for a project of your choosing.
  4. Clone the repo with your deploy token and observe the audit event, it should list the name of the deploy token as the author. Example git clone "https://<token username>:<token>@gdk.test:3000/flightjs/blank-project.git"
  5. To further validate that we fixed the exception that caused this issue in the first place, set the creator_id of the deploy token you created to NULLin the deploy_tokens database table. The audit event should still send without issue. You can run the following in rails console to do the same DeployToken.last.update(creator_id: nil)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Resolves Cloning private repo continues to fail (audit_e... (#361812 - closed)

Edited by Huzaifa Iftikhar

Merge request reports