✅ Project Level Access Tokens
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*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.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
# Problem
Currently, GitLab customers are creating users instead of bots (since there is no official bot feature in GitLab) to specifically handle the automation of tasks. This is painful for customers for the following reasons:
* Compromised security
* Attaching tokens to a specific user means that that user account has access to the full API, if those account credentials are compromised, the whole instance is potentially in the hands of bad actors
* Additional license costs (further detailed below) causes customers to only create one user for many tasks to save money, which is also a potential security risk
* Cost
* Customers are having to pay not only for additional licenses, but also for the other surrounding costs such as email account provisioning via G-Suite or Office 365 in order for the user to have credentials
* There are users who are uncomfortable with converting to a paid customer due to the anxiety around increased license costs, especially if they are a small team or business with many automated tasks
* Decreased cycle time
* Provisioning bot users is a long and convoluted process for some customers, causing potential delays in getting work done
* If the cost of creating a bot user is too high, users may attempt to manually perform the tasks instead, which is not efficient
* Potential downtime
* If a user who's access token is being used for a task that many depend on gets deleted, this could cause potential disruption and downtime
#### Problem Validation
* Problem validation opportunity canvas: https://docs.google.com/document/d/1QMUNnCNDsK4DYZHRM4qEIJogiMpCWkXnrLtbuuGd5mg/edit
* Original issue with significant customer feedback: https://gitlab.com/gitlab-org/gitlab/issues/6883
## Proposal
Allow customers to create project level access tokens that are not attached to a paid account via project settings.
### Acceptance Criteria
A user can create an access token that they can use for automation purposes, which has scoped permissions to the project only with the maintainer role. This token can be deleted/revoked and users can create multiple tokens.
The "behind the scenes" bot user that exists as a carrier for the access token cannot be accessed by end users for any other purpose and is not included in the license. The created bot user has default values set and is not editable.
This should only be shipped to ~"self-managed" customers until we have completed https://gitlab.com/gitlab-org/gitlab/-/issues/15666 and https://gitlab.com/gitlab-org/gitlab/-/issues/22754.
## Feature flag
The feature is currently behind the `resource_access_token` feature flag with default off.
## Rollout plan
#### 13.0
* Self-managed only, behind a feature flag.
* This feature is shipping as an Alpha.
* A project Maintainer or Owner will be able to generate a project access token in the UI:

* Since access tokens still require access tokens to authenticate through a user, generating a token silently creates a bot user (like Ghost User) in the background.
* The bot user has Maintainer membership in the relevant project.
* If the token is revoked, the bot user is deleted and objects are assigned to Ghost User.
* The bot user does not increase the licensed seat count for the instance.
* Note that this is also how we handle other bot users like Ghost User and GitLab Support Bot.
* No API endpoint to create/manage project access tokens.
Docs are available here: https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html
#### 13.1
* Project Access Tokens available behind a feature flag for self-hosted instances.
#### 13.3
* General availability for self-managed instances.
* Improvement to prevent the hidden project bot from being added to other projects https://gitlab.com/gitlab-org/gitlab/-/issues/217512 https://gitlab.com/gitlab-org/gitlab/-/issues/215376
* Improvement to prevent the hidden project bot from being removed from the project, rendering it useless. https://gitlab.com/gitlab-org/gitlab/-/issues/217510
#### 13.5
* Address issue that causes bots to count as licensed seats (https://gitlab.com/gitlab-org/gitlab/-/issues/223695)
* Project Access tokens and TOS (https://gitlab.com/gitlab-org/gitlab/-/issues/225222)
* General availability in Gitlab.com (https://gitlab.com/gitlab-org/gitlab/-/issues/220220)
* https://gitlab.com/gitlab-org/gitlab/-/issues/238083
* https://gitlab.com/gitlab-org/gitlab/-/issues/235924
* https://gitlab.com/gitlab-org/gitlab/-/issues/244545
epic