DEV Community

Janak Shrestha
Janak Shrestha

Posted on

Day 76: Jenkins Project Security

#jenkins #devops

The xFusionCorp Industries has recruited some new developers. There are already some existing jobs on Jenkins and two of these new developers need permissions to access those jobs. The development team has already shared those requirements with the DevOps team, so as per details mentioned below grant required permissions to the developers.

Click on the Jenkins button on the top bar to access the Jenkins UI. Login using username admin and password Adm!n321. m

  1. There is an existing Jenkins job named Packages, there are also two existing Jenkins users named sam with password sam@pass12345 and rohan with password rohan@pass12345.
  2. Grant permissions to these users to access Packages job as per details mentioned below: a.) Make sure to select Inherit permissions from parent ACL under inheritance strategy for granting permissions to these users. b.) Grant mentioned permissions to sam user : build, configure and read. c.) Grant mentioned permissions to rohan user : build, cancel, configure, read, update and tag.

Note:

  1. Please do not modify/alter any other existing job configuration.
  2. You might need to install some plugins and restart Jenkins service. So, we recommend clicking on Restart Jenkins when installation is complete and no jobs are running on plugin installation/update page i.e update centre. Also Jenkins UI sometimes gets stuck when Jenkins service restarts in the back end. In this case, please make sure to refresh the UI page.
  3. For these kind of scenarios requiring changes to be done in a web UI, please take screenshots so that you can share it with us for review in case your task is marked incomplete. You may also consider using a screen recording software such as loom.com to record and share your work.

Understanding the Requirements

Task Overview

Requirement Details
Job Name Packages
Users sam, rohan
Inheritance Strategy Inherit permissions from parent ACL
sam's Permissions build, configure, read
rohan's Permissions build, cancel, configure, read, update, tag

User Credentials

User Password
admin Adm!n321
sam sam@pass12345
rohan rohan@pass12345

Understanding Jenkins Security Concepts

What is Project-Based Security?

Project-based security allows you to configure permissions at the individual job level, rather than only at the global level. This provides granular control over who can do what on specific jobs.

Inheritance Strategies

Strategy Description
Inherit permissions from parent ACL Combines global permissions with job-specific permissions
Inherit globally defined permissions Only inherits global permissions
Do not inherit permission grants from other ACLs Only uses permissions explicitly set on the job

Permission Definitions

Permission Description
Job/Build Trigger builds for the job
Job/Cancel Cancel running builds
Job/Configure Edit the job's configuration
Job/Read View the job on the dashboard
Job/Update Update parameterized builds
SCM/Tag Create tags in the source code repository

Step-by-Step Implementation

Step 1: Access Jenkins UI

  1. Click the Jenkins button on the top bar
  2. Login with:
    • Username: admin
    • Password: Adm!n321

Step 2: Install the Matrix Authorization Strategy Plugin

Before configuring project-based security, we need to install the Matrix Authorization Strategy plugin.

  1. Navigate to Manage Jenkins → Plugins
  2. Click on Available plugins
  3. Search for Matrix Authorization Strategy
  4. Check the box and click Install
  5. If prompted, select Restart Jenkins when installation is complete and no jobs are running
  6. Refresh the UI page if needed after Jenkins restarts

Why this plugin? It provides the ability to configure fine-grained permissions at both global and job levels.

Step 3: Configure Global Security (Parent ACL)

This step is critical because users need at least Overall/Read permission to log in and see the Jenkins dashboard.

  1. Go to Manage Jenkins → Configure Global Security
  2. Under Authorization, select Project-based Matrix Authorization Strategy
  3. In the global permission matrix:
    • Click Add user → Enter sam → Click OK
    • Click Add user → Enter rohan → Click OK
  4. Grant permissions:
    • sam: Check Overall/Read
    • rohan: Check Overall/Read
    • admin: Ensure Overall/Administer is checked (should already be)
  5. Click Save

Step 4: Enable Project-Based Security on the Packages Job

  1. Navigate to the Packages job on the Jenkins dashboard
  2. Click Configure in the left sidebar
  3. In the General section, check the box Enable project-based security

Important Note: The Authorization section (with inheritance strategy and permission matrix) will only appear AFTER you check this box. This is by design — Jenkins shows/hides sections based on the options you select.

Step 5: Configure the Inheritance Strategy

Once you check Enable project-based security, an Authorization section will appear below it.

  1. Under Inheritance Strategy, select: 
   Inherit permissions from parent ACL
Enter fullscreen mode Exit fullscreen mode
  1. You will see a description confirming: > "This item will inherit its parent item's permissions (in addition to any permissions granted here). If this item is at the top level in Jenkins, it will inherit the global security settings."

Step 6: Add User sam and Grant Permissions

  1. Click the Add user button
  2. Enter the username: sam
  3. Click OK
  4. In the row for sam, check the following permissions:
Permission Category Permission Status
Job Job/Build ✓
Job Job/Configure ✓
Job Job/Read ✓

Summary for sam: Job: Build, Configure, Read

Leave all other permissions unchecked for sam.

Step 7: Add User rohan and Grant Permissions

  1. Click the Add user button
  2. Enter the username: rohan
  3. Click OK
  4. In the row for rohan, check the following permissions:
Permission Category Permission Status
Job Job/Build ✓
Job Job/Cancel ✓
Job Job/Configure ✓
Job Job/Read ✓
Run Run/Update ✓
SCM SCM/Tag ✓

Summary for rohan: Job: Build, Cancel, Configure, Read · Run: Update · SCM: Tag

Leave all other permissions unchecked for rohan.

Step 8: Save the Configuration

  1. Click the Save button at the bottom left of the page
  2. The configuration will be applied immediately

Permission Matrix Visualization

After completing the configuration, the permission matrix should look like this:

┌─────────────────────┬─────────┬─────────┬───────────┐
│ Permission          │ sam     │ rohan   │ Anonymous │
├─────────────────────┼─────────┼─────────┼───────────┤
│ Job/Build           │   ✓     │   ✓     │           │
│ Job/Cancel          │         │   ✓     │           │
│ Job/Configure       │   ✓     │   ✓     │           │
│ Job/Read            │   ✓     │   ✓     │           │
│ Job/Update          │         │   ✓     │           │
│ SCM/Tag             │         │   ✓     │           │
│ (other permissions) │         │         │           │
└─────────────────────┴─────────┴─────────┴───────────┘
Enter fullscreen mode Exit fullscreen mode

Verification

Step 1: Log Out as Admin

  1. Click your profile icon (top right)
  2. Click Sign out

Step 2: Log in as sam

  1. Username: sam
  2. Password: sam@pass12345
  3. Navigate to the Packages job
  4. Verify you can:
    • See the job (Job/Read)
    • Click Configure (Job/Configure)
    • Click Build Now (Job/Build)

Step 3: Log in as rohan

  1. Log out from sam's session
  2. Username: rohan
  3. Password: rohan@pass12345
  4. Navigate to the Packages job
  5. Verify you can:
    • See the job (Job/Read)
    • Click Configure (Job/Configure)
    • Click Build Now (Job/Build)
    • Cancel a running build (Job/Cancel)
    • Update parameters (Run/Update)
    • Tag in SCM (SCM/Tag)

Troubleshooting Common Issues

Issue 1: Authorization Section Not Visible

Symptom: The Authorization section doesn't appear on the job configuration page.

Cause: The "Enable project-based security" checkbox is not checked.

Solution: Check the Enable project-based security checkbox in the General section.

Issue 2: Users Cannot Log In

Symptom: Users get "Access Denied" when logging in.

Cause: Users don't have Overall/Read permission at the global level.

Solution: Add users to the global security matrix and grant Overall/Read.

Issue 3: Job Not Visible to Users

Symptom: Users can log in but cannot see the Packages job.

Cause: Users lack Job/Read permission on the specific job.

Solution: Grant Job/Read permission in the project-level matrix.

Issue 4: Matrix Option Not Available

Symptom: "Project-based Matrix Authorization Strategy" is not listed in the Authorization options.

Cause: The Matrix Authorization Strategy plugin is not installed.

Solution: Install the plugin from Available Plugins and restart Jenkins.

Issue 5: Wrong Inheritance Strategy

Symptom: Users have more or fewer permissions than intended.

Cause: The wrong inheritance strategy was selected.

Solution: Change the inheritance strategy to Inherit permissions from parent ACL.

Best Practices for Jenkins Project Security

1. Principle of Least Privilege

Grant only the permissions that users absolutely need. Avoid giving broad permissions like Job/Delete or Overall/Administer unless necessary.

2. Use Groups Instead of Individual Users

For larger teams, use Jenkins groups (backed by LDAP or Active Directory) instead of managing individual users.

3. Regular Audits

Periodically review the permission matrix to ensure users have appropriate access. Remove permissions for users who no longer need them.

4. Document Permission Changes

Keep a record of who has what permissions and why. This helps during audits and troubleshooting.

5. Test with Non-Admin Accounts

Always verify permissions by logging in as the actual user, not just as an administrator.

Key Learnings

  1. Project-Based Security: Jenkins allows granular permission management at the job level using the Matrix Authorization Strategy plugin.

  2. Inheritance Strategy: The "Inherit permissions from parent ACL" strategy combines global and job-level permissions, ensuring users have at least the global Overall/Read permission.

  3. Conditional UI: The Authorization section in job configuration only appears after checking the "Enable project-based security" checkbox.

  4. Permission Verification: Always verify permissions by logging in as the actual user.

  5. Principle of Least Privilege: Grant only the permissions required for each user's role.

Task Summary

Requirement Status
Matrix Authorization Strategy plugin installed ✅
Global security configured with Overall/Read for sam and rohan ✅
Project-based security enabled on Packages job ✅
Inheritance Strategy: Inherit permissions from parent ACL ✅
sam granted: build, configure, read ✅
rohan granted: build, cancel, configure, read, update, tag ✅
No other job configuration modified ✅

Configuration Summary

sam's Permissions 

Job: Build, Configure, Read
Enter fullscreen mode Exit fullscreen mode

rohan's Permissions 

Job: Build, Cancel, Configure, Read
Run: Update
SCM: Tag
Enter fullscreen mode Exit fullscreen mode

Inheritance Strategy 

Inherit permissions from parent ACL
Enter fullscreen mode Exit fullscreen mode

Screenshots for Documentation

Make sure to capture the following screenshots for review:

  1. Global Security Configuration – Showing sam and rohan with Overall/Read
  2. Project-Based Security Enabled – The checkbox checked in the Packages job
  3. Inheritance Strategy – "Inherit permissions from parent ACL" selected
  4. Permission Matrix – Showing the permissions for sam and rohan
  5. Verification – Logged in as sam and rohan accessing the Packages job

Summary

In this challenge, we successfully:

  1. Accessed the Jenkins UI and logged in as admin
  2. Installed the Matrix Authorization Strategy plugin
  3. Configured global security with Overall/Read for both users
  4. Enabled project-based security on the Packages job
  5. Selected the correct inheritance strategy
  6. Granted the appropriate permissions to sam and rohan
  7. Verified the configuration by logging in as each user

This setup demonstrates how Jenkins project-based security provides fine-grained control over user permissions, following the Principle of Least Privilege. The developers now have exactly the permissions they need to perform their tasks without unnecessary access.

Top comments (0)