Skip to content

List Revoked and Expired Project and Group Access Tokens

Problem to solve

Currently, GitLab automatically deletes project and group access tokens once they expire or are revoked, which can create challenges for auditing and security reviews due to the lack of a record of expired tokens. This proposal suggests retaining revoked Group / Project Access Token records, to help teams track token usage and expiration for compliance and monitoring purposes.

Proposal

Introduce a new table to the Group & Project Access Token pages that displays a list of expired project and group access tokens. This list should include relevant details such as the token name, expiration date, creation date, e.g.:

Screenshot_2024-06-10_at_2.38.26_PM

Benefits

  • Audit Trail: Provides an audit trail for access tokens, helping teams review and ensure compliance with security policies.
  • Security Monitoring: Enhances security monitoring by allowing administrators to review and investigate security incidents by determining which access tokens were active at the time.
  • Operational Transparency: Improves transparency into token usage and lifecycle management.

Implementation Details

Current State

  1. Projects::Settings::AccessTokensController and Groups::Settings::AccessTokensController include AccessTokenActions.
  2. AccessTokensActions#revoke calls ResourceAccessTokens::RevokeService.new(current_user, resource, @resource_access_token).execute.
  3. RevokeService calls access_token.revoke! and DeleteUserWorker.perform_async(current_user.id, bot_user.id, skip_authorization: true)
  4. DeleteUserWorker calls Users::DestroyService.new(current_user).execute(delete_user, options.symbolize_keys) which calls Users::GhostUserMigration.create!
  5. MigrateRecordsToGhostUserService migrates a bunch of records to the Ghost user, then calls user.destroy_dependent_associations_in_batches.
  6. This is, presumably, why the Bot's personal_access_tokens are revoked

Implementation Plan

At least 3 MRs:

  1. Update ResourceAccessTokens::RevokeService to not call DeleteUserWorker
    1. Use a FeatureFlag like Feature.enabled?(:retain_resource_access_token_user_after_revoke, resource)
  2. Update WHAT? to not expire bot user membership when a token expires
    1. Use the same FF
  3. Update the API & UI of Project Access Tokens to show expired or revoked tokens
    1. We can display this table if Feature.enabled?(:retain_resource_access_token_user_after_revoke, resource) to simplify rollout
    2. Note: this UI might show tokens that "haven't expired yet", but are still inactive as they're revoked. This might be confusing🤷
    3. Note: the UI would only show tokens that were revoked / expired after the FF is enabled. (We can't reconstruct lost data). This might also be confusing.
  4. Update the API & UI of Group Access Tokens to show expired or revoked tokens
    1. As above
  5. Update the Group & Project Resource Token API endpoints to accept a state parameter with either active|inactive, defaulting to active.
    1. This follows the same pattern as https://docs.gitlab.com/ee/api/personal_access_tokens.html#list-personal-access-tokens

Implications:

  1. An instance (incl .com) will retain an ever-increasing number of Group & Project Bot Users.
    1. An alternative was to migrate revoked tokens to the Ghost user, but then we lose the association to the group/project so that's a non-starter.
    2. I don't believe we need to Block them because this type of user can't do anything else anyway, and already don't count as a seat?...
  2. Because we retain the bot user, we will still see their username in comments / notes / whatever - current state is that these all get migrated to the Ghost user
  3. If a Group/Project Bot is deleted via the Admin panel (or some other method) we will lose it from this new table, too. I don't see a way around that.

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by Adil Farrukh