Jenkins Authentication

In this lesson, we explore how authentication works in Jenkins and how to manage user access effectively. We cover the built-in user database authentication, enabling user registration, configuring authorization settings, and integrating external security realms.

Jenkins' Built-In Authentication

After the initial Jenkins setup, only a single admin account is created. Notice that when a team member tries to create an account via the Jenkins UI, there is no registration option by default. In many environments, you might want to integrate with your company’s LDAP server or Active Directory. However, we will first review Jenkins' built-in user database authentication.

To begin, navigate to Manage Jenkins and then click on Security. Here you will see that Jenkins uses its own user database for authentication rather than delegating to an external system. As described in the documentation:

For basic configuration, Jenkins manages its users internally. If you return to the Manage Jenkins page and click on Users, you will find the admin account. Although additional users can be created, we will demonstrate how in the next section.

Managing Users and Registration

Return to the Security page. You will notice settings such as “Keep me signed in” on the login page. For this demonstration, disable the “Keep me signed in” option and enable user sign-up. Once these changes are applied and you log out, the login page will no longer display the "remember me" option, and a registration option will be available:

Register a new account by entering a username (for example, "John"), full name, email address, and password. The registration page appears as shown:

After creating the account, Jenkins automatically logs you in, and you should now see two users—the original admin and the new user John—in the Jenkins user database:

Exploring Authorization Options

Next, let’s shift our focus to authorization. By default, Jenkins is set so that logged-in users can perform any action. It is also possible to configure Jenkins to grant anonymous users full access. For demonstration purposes, change the authorization option to “Anyone can do anything” and save the configuration. Then, log out. Now, even when not logged in, you can view jobs on the Jenkins dashboard—although options for creating new items or managing Jenkins remain disabled.

For example, when an anonymous user triggers a build, the dashboard displays that the build was initiated by an unknown user:

The build log output is similar to the following:

Started by user unknown or anonymous
Running as SYSTEM
Building in workspace /var/lib/jenkins/workspace/ascii-deploy-job
Copied 1 artifact from "ascii-test-job" build number 5
[ascii-deploy-job] $ /bin/sh -xe /tmp/jenkins3742226208397197254.sh
+ exit 1
Build step 'Execute shell' marked build as failure
Finished: FAILURE

This log demonstrates that while the build is triggered, it is executed under anonymous credentials.

With read-only access, users can inspect job details and builds without the ability to create, modify, or delete jobs.

Integrating External Security Realms

To simulate integration with an external LDAP server or Active Directory, Jenkins offers a feature to install and configure a mock security realm. This dummy security realm mimics external authentication systems but is intended only for evaluation purposes and should not be used in production.

Follow these steps:

1. Navigate to Manage Jenkins → Manage Plugins.
2. Update the required plugins.
3. Search for and install the "Mock Security Realm" plugin.
4. Return to the Security page. You will notice that the security realm now expects a list of users and groups instead of using the Jenkins user database.

In a typical LDAP server environment, you might have groups such as admin, developer, and QA. The mock security realm requires a list where each line contains a username and, optionally, one or more group names separated by spaces. For example:

alice
bob admins
charlie qa
darlene qa admins

For demonstration, add a few users with their respective groups:

• Siddharth belongs to the admin group.
• Ali is assigned to the manager group.
• Bob is part of the QA team.
• Ema belongs to the developer group.
• Tina is in both the developer and QA groups.

Additionally, disable anonymous read access while using the mock security realm. Once applied, you’ll notice that the user management tab is removed because Jenkins is no longer sourcing users from its internal database. Only the users defined in the mock realm will be valid for authentication.

Attempting to log in as the previously created admin or John will not work. Instead, use the credentials defined in the mock security realm (each user’s password is identical to their username). For example, logging in as Siddharth should be successful.

Review the users and their groups using the Jenkins UI:

After logging in as Tina, who belongs to the developer and QA groups, her group memberships will be clearly displayed:

It is important to note that the mock security realm only handles authentication and group association, not authorization. Consequently, even though Tina is a member of the developer and QA groups, she currently can build jobs and delete projects because the authorization setting remains “Logged-in users can do anything.”

For enhanced security, adjust your authorization rules so that only users in the admin group can delete projects. We will address how to implement these changes in a subsequent lesson.

Summary

In this lesson, we covered:

• How Jenkins' built-in user database works and managing users.
• How to enable user sign-up and configure basic authentication.
• The risks associated with full anonymous access and how authorization rules affect user capabilities.
• How to simulate an external security realm using the mock security realm plugin and define users with their associated groups.

Thank you for following along, and stay tuned for the next lesson where we will refine authorization rules to secure your Jenkins environment further.