- We have seen users that we didn’t create or that are not part of our security realm. Where did they come from? Is it safe to delete them?
- CloudBees CI (CloudBees Core) on modern cloud platforms - Managed Master
- CloudBees CI (CloudBees Core) on traditional platforms - Client Master
- CloudBees Jenkins Distribution
- CloudBees Jenkins Enterprise - Managed Master
- CloudBees Jenkins Platform - Client Master
- Jenkins LTS
The first step is to check how these users were created. To do this, please execute this script on “Manage Jenkins” -> “Script console”. This script will generate a CSV output with the permissions, type of users, and how they were created.
If you are checking out source code from an SCM, Jenkins automatically creates local accounts that track the authors of commits to the SCM repo, if those accounts do not already exist. Since usernames are likely to be the same across multiple SCM systems, as well as Jenkins itself, ideally we end up with a single Jenkins user record that maps to all source code changes that person made. This enables features such as seeing all builds that contain code committed by a given user, or emailing commit authors (based on their Jenkins user account email address) when a build fails. These auto-generated users are not on the secure realm, so they are not going to be able to log in and they have no permission in Jenkins. If you later explicitly create a Jenkins account with the same username, this commit history data will be preserved and associated with that account.
These users can safely be deleted, but they will be recreated when the user shows up as an SCM author again. The above-mentioned script will detail what users have been created due to SCM checkouts on the description field.