Convert ops_release-tools Personal Access Token to Service Account Token

What

Convert the ops_release-tools personal access token (PAT) currently used by release-tools to a service account token managed through automation in the infra-mgmt repository.

This work is part of the broader token automation effort tracked in the parent epic.

Why

The current ops_release-tools PAT requires manual rotation and has broad cross-repository access requirements that make it ideal for service account conversion:

  • Manual Maintenance Problem: Current PAT requires manual rotation every year
  • infra-mgmt Limitations: infra-mgmt doesn't have an admin PAT (and likely never will), so it can't manage users or their PATs (source)
  • Cross-Repository Requirements: Token "coordinates every aspect of the GitLab release process, this token interacts with all the repositories in the single application to generate branches, tag, commits, and changelogs" (source)

Current Token Details

  • Current CI/CD variable name: RELEASE_BOT_OPS_TOKEN
  • Current Vault path: protected/shared/Release_Bot_Ops/token@ci
  • New SAAT Vault path: ci/access_tokens/ops-gitlab-net/gitlab-org/_service_account_access_tokens/release-tools-ops/token@ci
  • Current scopes: api
  • Reference: Original token issue #2584

Access Requirements Analysis

Comprehensive API Analysis Results: The gitlab-release-tools-bot has direct membership in 9 groups/projects and the release-tools-ops SAAT requires equivalent access:

Resource Type Bot Access Level Delivery Group Inheritance Status
Group 61 ("release") Group Owner (50) Owner (50) via gitlab-com/delivery ❌ Delivery group membership required
Group 354 ("quality") Group Owner (50) Maintainer (40) via gitlab-com/delivery ❌ Direct membership required
Group 504 ("delivery") Group Owner (50) Direct membership ❌ Direct membership required
Group 1796 ("🔒 delivery group only 🔒") Group Owner (50) Direct membership ❌ Direct membership required
Group 2050 ("GitLab Delivery") Group Maintainer (40) None ❌ Direct membership required
Group 102 ("Infrastructure") Group Maintainer (40) Owner (50) via gitlab-com/delivery ❌ Delivery group membership required
Project 154 ("Merge Train") Project Maintainer (40) Maintainer (40) via gitlab-com/delivery ❌ Delivery group membership required
Project 151 ("Deployer") Project Owner (50) Maintainer (40) via gitlab-com/delivery ❌ Direct membership required
Project 842 ("test-project") Project Maintainer (40) None ❌ Direct membership required

Access Strategy Summary:

  • ✅ 2 resources: Direct membership via current MR (delivery groups)
  • ✅ 3 resources: Covered through delivery group inheritance
  • ❌ 4 resources: Require additional direct memberships due to access level gaps

Implementation Plan

  • Create service account in infra-mgmt following ops.gitlab.net pattern
  • Complete comprehensive access analysis via API investigation
  • Create MR with delivery group memberships foundation - infra-mgmt!2065 adds the direct memberships and delivery group access required to grant the SAAT equivalent access to the current ops_release-tools PAT and also adds the 4 direct memberships for access level gaps:
    • Group 354 ("quality") - Owner access
    • Group 2050 ("GitLab Delivery") - Maintainer access
    • Project 151 ("Deployer") - Owner access
    • Project 842 ("test-project") - Maintainer access
  • Update release-tools CI configuration to use new vault path
  • Test release-tools functionality with service account token
  • Decommission old PAT

Success Criteria

  • Service account token created and stored in vault.
  • Service account has equivalent access to all 9 groups/projects
  • Service account token successfully replaces RELEASE_BOT_OPS_TOKEN.
  • Release tools functionality verified with new token.
  • Automated rotation configured through infra-mgmt.
  • Documentation updated with new token management process.
Edited by Maina Ng'ang'a