Jenkins’ Matrix-based security is a surprisingly flexible, yet often misunderstood, way to manage user permissions that goes far beyond simple administrator/user splits.
Let’s see it in action. Imagine you have a Jenkins instance and you want to grant your "developers" group the ability to build jobs, but only their jobs, and your "testers" group the ability to view build logs but not trigger builds.
First, you need to enable Matrix-based security. Go to Manage Jenkins -> Configure Global Security. Under Authorization, select Matrix-based security.
+-----------------------------------------------------------------+
| Authorization |
+-----------------------------------------------------------------+
| [ ] Use system default |
| [*] Matrix-based security |
| ... |
+-----------------------------------------------------------------+
Now, you’ll see a table where you can add users and groups and assign permissions.
Let’s add a group called developers. In the User/Group column, type developers. In the Permissions column, check Job: Build and Job: Read. You’ll also want to grant them Job: Workspace so they can see their build artifacts.
+-------------------------------------------------------------------------------------------------------+
| Matrix-based security |
+-------------------------------------------------------------------------------------------------------+
| Add User/Group... |
| |
| User/Group | Overall | SCM | Job | Run | Credentials | Folders | ... | Save | Cancel | Help | |
|------------------|---------|-----|-----|-----|-------------|---------|-----|------|--------|------| |
| developers | | | B | | | | | [ ] | [ ] | | |
| | | | R | | | | | [ ] | [ ] | | |
| | | | W | | | | | [ ] | [ ] | | |
| testers | | | R | | | | | [ ] | [ ] | | |
| | | | | | | | | [ ] | [ ] | | |
| hudson-admin | ALL | ALL | ALL | ALL | ALL | ALL | | [ ] | [ ] | | |
| ... | ... | ... | ... | ... | ... | ... | | ... | ... | | |
+-------------------------------------------------------------------------------------------------------+
In this table:
Bstands for BuildRstands for ReadWstands for Workspace
For the testers group, you’d add testers and check only Job: Read.
Crucially, to restrict developers to only their jobs, you need to use folder permissions. If you have jobs in folders, you can grant permissions at the folder level. Create a folder named dev-jobs. Inside this folder, add the developers group and grant them Job: Build, Job: Read, and Job: Workspace. Now, any job inside dev-jobs will be buildable by developers, but jobs outside this folder will not.
The underlying mechanism is that Jenkins evaluates permissions hierarchically. Global permissions apply everywhere unless overridden. Folder permissions override global permissions for jobs within that folder. Permissions granted to a specific job override folder permissions. If a user or group is not explicitly granted a permission at any level, they don’t have it.
The most surprising part is how granular you can get without plugins. You can grant a user the ability to Job: Configure for a specific job but not Job: Delete. This level of control prevents accidental or malicious deletion of critical build pipelines while still allowing authorized individuals to tweak build steps. You can even grant Credentials: View for a specific credential ID, allowing someone to see a password but not use it.
Once you’ve configured your matrices, click Save. Now, users in the developers group (assuming they have developers as a Jenkins group membership or are mapped from an external source like LDAP) can build jobs within the dev-jobs folder, but not others. Testers can view all job logs.
The next logical step is to explore how to automate the creation and management of these user groups and their corresponding Jenkins permissions, likely through integration with an external identity provider.