Concept of bot user
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
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.
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
HN comment: https://news.ycombinator.com/item?id=17380625