Restrict personal access tokens to specific projects
Currently, 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.
Add the ability to limit API access by personal access tokens to specific projects when creating a token.
This issue should cover the backend changes only. After this iteration, GitLab should be able to generate a PAT scoped to a single project that we'll use for Task Bots in &2587.
I was considering creating a new
project scope that requires an additional value which could be stored in a separate table as mapping between
Projects. Then extend
APIGuard to be able to use it, and finally make some of our API endpoints accessible with this new scope.
I 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).