Restrict personal access tokens to specific projects [BE]
@jeremy_
Overview fromCurrently, personal access api
tokens do not have scoping at the project/group or functional level. This is problematic; this approach gives individual tokens too much power. A single api
token applies to all projects on the instance, and we should limit the blast radius for individual tokens by allowing them to be scoped.
In this issue, we'll limit PATs to specific projects. PATs will still be attached to a particular user. This'll allow for use cases like a large organization with hundreds of projects designating a single bot user, and creating individual PATs for each of their projects. This increases security considerably, and allows us to limit misuse of an api
-scoped token to a specific project.
After this issue is complete, we'll continue to iterate with improvements like limiting PATs to groups and limiting the functional scope of the api
token.
Proposal
Add the ability to limit API access by personal access tokens to specific projects when creating a token.
- In
/profile/personal_access_tokens
, allow a user to optionally specify which project should be accessible when creating a PAT. A user should still be able to create a PAT scoped for all projects/groups.- A user should be able to specify a single project or multiple projects.
- The list of active Personal Access Tokens presented on this page should reflect the scope of the token (e.g. if applicable, the projects the PAT is scoped to).
- A user should be able to revoke from the list, as they're currently able.
- Project-specific tokens should not be able to create, delete, or list SSH keys for the current user.
@doits
OP byI have a bot you does some code analysis (with https://github.com/mmozuras/pronto). This bot has access to Gitlab with a special user (and to each project with reporter rights) and is only run on CI. But to access the API, it uses a Gitlab access token which is stored in a secure variable. This is good so far, but a malicious developer could still output this access token by changing the tests and then do what he wants with it, e.g. seeing/accessing all projects the bot has access to (most of them are private).
- This can be mitigated by restricting an access token to specific projects/groups. I would create different access tokens for different projects for that bot user, so when a malicious developer extracts it, he only has access to that specific project he sees the builds to (which means he has access to it anyway in my case).