Skip to main content

Command Palette

Search for a command to run...

Day 76: Jenkins Project Security | 100 Days of DevOps

Updated
โ€ข7 min read
R
Iโ€™m currently working in DevOps and documenting my learning journey along the way. From CI/CD pipelines to cloud and containers, Iโ€™m exploring how modern systems are built and deployed. This blog is where I share what I learn, break down concepts in simple terms, and track my progress. Learning one concept at a time, and trying to apply it practically.

Content

Today I worked on configuring project-level security in Jenkins by granting specific permissions to individual users on an existing Jenkins job. The objective was to provide controlled access to a project while ensuring that global Jenkins security settings remained unchanged.


๐Ÿ”น What I Learned

  • Jenkins Authorization Strategies

  • Project-Based Security in Jenkins

  • Matrix Authorization Strategy Plugin

  • User Permission Management

  • Job-Level Access Control

  • Jenkins Security Inheritance

  • Restricting User Actions on Jenkins Jobs

  • Applying Least Privilege Security Principles


๐Ÿ”น Task Requirement

The xFusionCorp Industries team recruited new developers who needed controlled access to an existing Jenkins job named Packages.

The requirement was to grant different permissions to two existing Jenkins users without modifying any other job configurations.

Jenkins Access Details

Field Value
Username admin
Password Adm!n321

Existing Jenkins Job

Job Name
Packages

Existing Users

User Password
sam sam@pass12345
rohan rohan@pass12345

Required Permissions

User: sam

Permission
Read
Build
Configure

User: rohan

Permission
Read
Build
Cancel
Configure
Update
Tag

Additional Requirement

The project must use:

Inherit permissions from parent ACL

as the inheritance strategy.


๐Ÿ”น Steps I Followed

1. Accessed Jenkins

Clicked the Jenkins button from the lab navigation bar.

This opened the Jenkins login page.


2. Logged Into Jenkins

Used the administrator credentials:

Username

admin

Password

Adm!n321

Successfully logged into the Jenkins Dashboard.


3. Installed Required Plugin

To enable project-level security management, I navigated to:

Manage Jenkins
โ†’ Plugins

Searched for and installed:

Matrix Authorization Strategy

This plugin provides fine-grained permission control for Jenkins users and jobs.

After installation completed, Jenkins prompted for a restart.


4. Restarted Jenkins

Navigated to:

Manage Jenkins
โ†’ Restart Jenkins

Waited for Jenkins to restart successfully.

Sometimes the Jenkins UI became temporarily unavailable during restart, so I refreshed the browser page and logged in again.


5. Logged Back Into Jenkins

Used the same administrator credentials:

Username: admin
Password: Adm!n321

Successfully accessed the Jenkins Dashboard.


6. Enabled Project-Based Matrix Authorization

Navigated to:

Manage Jenkins
โ†’ Security

Under Authorization settings, selected:

Project-based Matrix Authorization Strategy

Important observations:

  • Existing permissions for Anonymous users were left unchanged.

  • Existing permissions for Authenticated users were left unchanged.

  • No global permissions were modified.

Clicked:

Apply
Save

This enabled project-level permission management without affecting existing Jenkins security settings.


7. Opened Packages Job Configuration

Navigated to:

Jenkins Dashboard
โ†’ Packages
โ†’ Configure

Opened the configuration page of the existing job.


8. Enabled Project-Based Security

Inside the General section of the job configuration, enabled:

Enable project-based security

This allows permissions to be assigned specifically for this job.


9. Configured Inheritance Strategy

Under project security settings, selected:

Inherit permissions from parent ACL

This ensures the job inherits global Jenkins permissions while allowing additional project-specific permissions to be assigned.

This was a mandatory requirement of the task.


10. Added Permissions for User sam

Added the existing Jenkins user:

sam

Granted the following permissions:

Permission Granted
Read โœ“
Build โœ“
Configure โœ“

This allows sam to:

  • View the job

  • Trigger builds

  • Modify job configuration


11. Added Permissions for User rohan

Added the existing Jenkins user:

rohan

Granted the following permissions:

Permission Granted
Read โœ“
Build โœ“
Cancel โœ“
Configure โœ“
Update โœ“
Tag โœ“

This allows rohan to:

  • View the job

  • Trigger builds

  • Stop running builds

  • Modify job configuration

  • Update job metadata

  • Create and manage build tags


12. Saved the Configuration

After verifying all permissions, clicked:

Save

The Packages job was updated successfully.


13. Verified Configuration

Reviewed the project security settings to confirm:

Inheritance Strategy

Inherit permissions from parent ACL

User sam

Read
Build
Configure

User rohan

Read
Build
Cancel
Configure
Update
Tag

All permissions matched the task requirements.


๐Ÿ”น Final Permission Matrix

Permission sam rohan
Read โœ“ โœ“
Build โœ“ โœ“
Cancel โœ— โœ“
Configure โœ“ โœ“
Update โœ— โœ“
Tag โœ— โœ“

๐Ÿ”น Simple Explanation of Jenkins Components Used

Matrix Authorization Strategy

The Matrix Authorization Strategy plugin provides fine-grained access control within Jenkins.

Instead of granting broad administrator permissions, specific actions can be assigned to individual users.

Examples:

  • Read

  • Build

  • Configure

  • Delete

  • Cancel

  • Tag

  • Update

This improves security by following the principle of least privilege.


Project-Based Security

Project-based security allows permissions to be applied to a specific Jenkins job rather than globally.

Benefits:

  • Better access control

  • Improved security

  • Team-specific permissions

  • Reduced risk of accidental changes

In this task, permissions were assigned only to the Packages job.


Inheritance Strategy

Inheritance determines how a job receives permissions from Jenkins.

The selected option:

Inherit permissions from parent ACL

means:

  • Global permissions remain available.

  • Additional job-specific permissions can be granted.

  • Existing security configurations remain intact.


Build Permission

Allows a user to:

  • Start builds manually

  • Trigger job execution

In this task:

sam
rohan

were both granted Build permission.


Configure Permission

Allows a user to:

  • Edit job settings

  • Modify build steps

  • Change job configuration

Both users received Configure permission.


Cancel Permission

Allows a user to:

  • Stop a running build

Only:

rohan

received this permission.


Update Permission

Allows a user to:

  • Update job-related information

Only:

rohan

received this permission.


Tag Permission

Allows a user to:

  • Create and manage build tags

Only:

rohan

received this permission.


๐Ÿ”น My Understanding

This task gave me hands-on experience with Jenkins security management and project-level authorization. I learned how the Matrix Authorization Strategy plugin enables granular access control and how project-based security can be used to grant different permissions to different users on the same job.


๐Ÿ”น What I Found Interesting

What I found most interesting was how Jenkins allows security to be managed at both the global and project levels. By enabling Project-based Matrix Authorization, I was able to grant precise permissions to individual developers without affecting other jobs or users.

๐Ÿ“Œ Full notes: GitHub link

100_days_of_devops

Part 1 of 50

Documenting my 100 Days of DevOps journey with hands-on practice from KodeKloud, along with notes, commands, and mini projects