Since a recent update (12.X to 13.3.7) our on-premises Gitlab creates a lot of accounts with username project_<some id>_bot and mail address project<some id>_bot@example.com.
What are these accounts and can I turn the creation off?
1 Like
Can’t say I’ve seen these types of users on my instance, but it could be because you have user registration enabled. You can turn this off under: /admin/application_settings/general and disable sign-up
That way, you will have to manually create login’s for users, and they will then receive an email to set a password. Maybe the problem is because of this, and bots are registering if the server is accessible from the internet.
The servers isn’t connected to the web and sign-up isn’t enabled. I added the example.com domain to the blacklist anyway.
@iis-mma , @iwalker : I observed the same issue. The problem, speaking for our instance is that
- user sign-in IS disabled
- the local “bot” user is created on the behalf of another unprivilegied user (see the user entry
Created by)
It seems the explanation is here : Remove example.com email from PAT users (#260305) · Issues · GitLab.org / GitLab · GitLab :
When a user creates a Personal Access Token, this creates a new user associated with the token.
By default, this user has a username of project_545_bot or similar.
An email address is also added by default, with a domain of example.com - e.g. project545_bot@example.com
Strange, since I create personal-access-tokens all the time and don’t see such activity. I expect it to be unique to your installation, or a particular method being used for creating the access tokens.
Please write the procedure that you are exactly doing, click by click to create the access token, maybe it will help to find out why. I just usually go to user settings, access tokens, and then create here but it is done to allow access to all projects that I as a user have access to. Maybe you are doing it another way? If so please explain the steps.
EDIT: yes, seems you are probably doing project access tokens under the actual project instead of the way I did it. This is most likely why and most likely normal behaviour of gitlab since it’s a project access token and not a user access token. If you don’t want this, suggest doing using my method.
Yes, I just discovered that aswell , this is about project access token, not personal. I’ll add a note to the issue mentioned above
I just added to the issue.
To do something similar, you can just manually create a special user, assign it to a group or project, and it’s level of permission, and then create a user token for this user. That way, only that particular user, which is restricted to the group or project has access. Similar to adding a project token, but comparable in terms of permissions and not giving access to every single project that your user has access to.
For example, I have an updates user, which has access to a group and the two projects underneath. It has reporter access (if I remember right), and then I create a user token for the updates user. Then he cannot do anything destructive, just git pull the repositories.
This problem isn’t unique to project tokens, but generally Gitlab. The bot users created during installation/upgrades also have example.com and they cannot be edited to use the domain configured. Obviously gitlab has some extra places that are using example.com and there is no obvious option in gitlab.rb or anywhere else in the system to fix this.
Ideally gitlab need to provide the config option to override this and stop it defaulting to using example.com when the external_url is configured. Or some other option like default_domain to utilise and finally get rid of example.com because it’s stupid really.
1 Like