The goal of https://gitlab.com/gitlab-org/gitlab/-/issues/460777+ is to revoke all the tokens GitLab generates, but this isn't realistic for an MVP. This task is to identify: - Which tokens are easily detected by prefix (https://docs.gitlab.com/ee/security/token_overview.html#token-prefixes) AND - Can be attributed to a group AND - Have an existing `RevokeService` (e.g. https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/personal_access_tokens/revoke_service.rb) ## By Revocation Services The following have existing revoke services: - Cluster Agent Tokens - Resource Access Tokens (Project & Group Access Tokens) - Group Deploy Tokens - x509 Certificates - Keys <details><summary>Click to expand `find`</summary> ``` % find app lib ee/app ee/lib -name '*revoke*.rb' 2>/dev/null app/graphql/mutations/achievements/revoke.rb app/graphql/mutations/clusters/agent_tokens/revoke.rb app/workers/x509_certificate_revoke_worker.rb app/controllers/projects/google_cloud/revoke_oauth_controller.rb app/services/achievements/revoke_service.rb app/services/clusters/agent_tokens/revoke_service.rb app/services/resource_access_tokens/revoke_service.rb app/services/groups/deploy_tokens/revoke_service.rb app/services/personal_access_tokens/revoke_service.rb app/services/personal_access_tokens/revoke_token_family_service.rb app/services/x509_certificate_revoke_service.rb app/services/keys/revoke_service.rb ee/app/graphql/mutations/dast_site_validations/revoke.rb ee/app/services/ee/clusters/agent_tokens/revoke_service.rb ee/app/services/ee/resource_access_tokens/revoke_service.rb ee/app/services/ee/groups/deploy_tokens/revoke_service.rb ee/app/services/ee/personal_access_tokens/revoke_service.rb ee/app/services/personal_access_tokens/revoke_invalid_tokens.rb ee/app/services/app_sec/dast/site_validations/revoke_service.rb ``` </details> ## By Prefix Table copied from https://docs.gitlab.com/ee/security/token_overview.html#token-prefixes | Token name | Detectable? | Attributable? | Revoke Service | Notes | |-----------------------------------|--------------------|-------------------------|----------------|-------| | Personal access token (User) | `glpat-` | :white_check_mark: Check user membership from the top level ancestor down to the given group | :white_check_mark: | There will always be a user, because structure states `user_id integer NOT NULL` | | Personal access token (Project) | `glpat-` | :white_check_mark: `project_bot` belongs to a project, check if project is in namespace | :white_check_mark: See above | | | Impersonation token | `glpat-` | :white_check_mark: Same as a Personal Access Token (User) | | | | Project access token | `glpat-` | :white_check_mark: | :white_check_mark: `We can use PersonalAccessTokens::RevokeService` | :warning: Will leave a hanging Bot user | | Group access token | `glpat-` | :white_check_mark: | :white_check_mark: As above | " | | Deploy token (Group) | `gldt-` | :white_check_mark: `GroupDeployToken#has_access_to_group?` | :white_check_mark: `Groups::DeployTokens::RevokeService` | | | Deploy token (Project) | `gldt-` | :white_check_mark: | :x: | Only a destroy service exists. It'd be trivial to add a Revoke service though / make the Group one generic | | OAuth Application Secret (User) | `gloas-` | :white_check_mark: via `owner_id` when `owner_type == 'User'` | :x: <br /> See also: https://docs.gitlab.com/ee/api/applications.html#renew-an-application-secret | _"provides secure delegated server resource access to client applications on behalf of a resource owner"_ <br /> &bull; https://docs.gitlab.com/ee/api/oauth2.html <br /> &bull; https://docs.gitlab.com/ee/integration/oauth_provider.html | | " (Group) | " | white_check_mark: via `owner_id` when `owner_type == 'Group'` | | | | " (Instance) | " | :x: | N/A | | | Runner authentication token | `glrt-` | | | | | CI/CD Job token | `glcbt-` | | | | | Trigger token | `glptt-` | | | | | Feed token | `glft-` | | | | | Incoming mail token | `glimt-` | | | | | GitLab agent for Kubernetes token | `glagent-` | | | | | GitLab session cookies | `_gitlab_session=` | | | | | SCIM Tokens | `glsoat-` | | | | | Feature Flags Client token | `glffct-` | | | | | - | - | - | - | - | | SSH Keys | :white_check_mark: Keys have predictable formats | :x: | :x: The revoke service calls the destroy service | Not all SSH Keys have users | ### Side notes #### Revoke vs. Destroy vs. Rotate Many of these have Destroy services, which aren't helpful here. If we destroy a record we can no longer look it up. Revocation would need to be added to each token type before we could add these to this API. Similarly a rotation service isn't helpful; we want to allow any authenticated caller to neutralise the threat of a leaked token. Rotating it provides the caller with a new secret. #### Permissions The pattern used by PATs looks good: ```ruby def revocation_permitted? case @source when :self Ability.allowed?(current_user, :revoke_token, token) when :secret_detection true else false end end ``` https://gitlab.com/gitlab-org/gitlab/-/blob/3c135704a04185fcdbf489c149a8941f663df120/app/services/personal_access_tokens/revoke_service.rb ### API Errors We can't return `422` when we don't support a certain type of token, because some token types re-use the same prefix and that could be indicitive. E.g. you find `gldt-ABC`: - If it's a Group Deploy Token, the error returned will be `404` or `200` depending on if the group is right. - If it's a Project Deploy Token it'll return `422`. - To determine if you've got a Group vs. Project deploy token, you'd fire this at a group you're sure it doesn't belong to. Then a `422` vs `404` tells you the type of token you've got. - I don't think we want to allow this type of enumeration. Recommendation: always return the same error for tokens we can't revoke. #### What error code? https://datatracker.ietf.org/doc/html/rfc9110 > _The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent_ > _The 422 (Unprocessable Content) status code indicates that the server understands the content type of the request content (hence a 415 (Unsupported Media Type) status code is inappropriate), and the syntax of the request content is correct, but it was unable to process the contained instructions._ Either seem fine. I'll go with `404`. We are either "willing to revoke it and return a 200" or "not willing to disclose whether the resource exists". ## Result For MVP we can support the revocation of: - Personal Access Tokens (whether they belong to a User or Project) - Group and Project Access Tokens, which are also just Personal Access Tokens - Group deploy tokens Other tokens will need to have `RevokeService`s built for them.