Package registry authentication token
Problem to solve
We have deploy tokens, CI_JOB_TOKENs, and personal access tokens that are all used for accessing the package registry. These tokens all have specific use cases that don't always match the need for being able to consume packages in a group setting.
Personal access tokens belong to a user, so sharing them with a team does not make sense. CI_JOB_TOKENs mimic the user that ran the job, leading to inconsistent permissions from job to job. Deploy Tokens were built with the repository in mind and are tied to a project or a group. Deploy tokens also were not meant to have access to the API. This means that deploy tokens have access to package manager API endpoints, but not GitLab package API endpoints.
Some users may want to have tokens that can access only specific projects within a group, or have read_package
permission but not have read_project
permission (something that is not currently possible).
A token customized with scopes specifically directed towards package consumption may make the most sense for many of these scenarios.
Intended users
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
User experience goal
Users have more flexibility in their token options and can feel better about if their packages and projects are secure.
Proposal
We have a few options to consider:
- Create a new token that is made for package use only.
- Update deploy tokens to be more customizable to solve some of these problems (some of these customizations are already laid out, such as being able to specify multiple projects/groups).
Further details
This issue has been opened as a result of this MR and discussion around making CI_JOB_TOKENs more secure and scoping them to a single project or a selected list of projects (meaning, users could not use CI_JOB_TOKEN to install packages from projects not in the known list).