Support "Script Users"
Description
Currently, personal access tokens can be used to allow external systems to interact with GitLab. These can be scoped to allow external scripts and systems to interact with GitLab. You can avoid creating additional "users" (thus avoid raising license cost) by using an existing user to generate a properly scoped Personal Access Token
.
This is functional, but all related activity is attributed to the owner of the Personal Access Token
rather than the system that performed the activity.
The middle-ground (our current solution) is to maintain a single Scripts
user. All external activity is attributed to this user with minimal additional annual cost. This is better but it still does not provide very granular attribution and it is not very good when it comes to ACL
.
An example of ACL challenges
is apparent with the new read_registry
scope for tokens that was introduced in 19.3
. It is reasonable that different external systems would be limited to accessing certain containers. As is, you have to (a) choose a user which has broad access and grant that broad access to all systems or (b) choose separate users which each have appropriate access. If you want to avoid license cost inflation, these would be actual
users so you could easily give one of the systems inadvertent access to more resources than it should have access to.
Proposal
Introduce script-only users. Such user would not have access to log into the GitLab UI. These users would not count towards the license limits, but may be reasonably limited based on license (i.e. x free script users per paid user).
Because they are otherwise treated like GitLab users:
- Attribution would function as-is
- Access control would function as-is
Feature checklist
Make sure these are completed before closing the issue, with a link to the relevant commit.
-
Feature assurance -
Documentation -
Added to features.yml