Personal access tokens granular permissions via sub accounts
Personal Access Tokens ("PATs") are a way to impersonate users and while they have different scopes, they don't offer a lot of flexibility when it comes to restrict what projects they have access to. By nature, they give access to all projects the user has access to, including private ones. There's only a few rare cases where a user would want to give access to everything. It's also not a good security practice and make PATs with the api
scope very dangerous, even possibly leading to lateral movement.
Proposal
We're going to have soon Service Accounts as part of GitLab. We could maybe leverage this feature to create something specific to users. What if users could create sub-accounts of their own accounts? These sub-accounts would be entirely tied to the main user, and would act as service account. In other words, they just "represent" the user and can't login for example. Another main difference is that sub-accounts don't have access to anything by default. The user has to define which groups and projects they have access to. The role is also attached to the sub-account at this point, and can't exceed the level of the current user (if the user is Developer
in a project, the sub-account can't be Maintainer
).
In other words, sub-accounts are an aggregation of specific services accounts created each time a user grant access to one of their project.
These service accounts are added to the projects/groups with the selected role.
Sub-accounts can have their own PATS, which means users have a way to define very precisely what PATs can access on their behalf.
Actions performed via sub-accounts are made on the behalf of the user and reflect the user identity instead of the service account.
When a user account is blocked or deleted, or sub-accounts are updated accordingly in cascade.