Matrix-based security is one of the authorization strategies available for securing Jenkins. It allows you to grant specific permissions to users and groups. The available permissions are listed below with their descriptions, and are also available by hovering over the permission heading in the Jenkins UI.
Note: These are the most common permissions available. Other plugins may add their own permissions.
Overall
Several of these permissions are at least as powerful as Administer, but for historical reasons are implied by the Administer permission (i.e. everyone with Administer can also perform the actions associated with these other permissions):
- RunScripts allows executing arbitrary code in the context of any (Jenkins internal) user, including the internal SYSTEM user.
- UploadPlugins allows uploading plugins, which in turn can execute arbitrary code in the context of any (Jenkins internal) user.
- ConfigureUpdateCenter can configure proxy settings and thereby control the update site metadata and plugin files downloaded by the Jenkins plugin manager, which in turn can be used to execute arbitrary code.
Permission |
Description |
---|---|
Administer |
Make system-wide configuration changes. Perform highly sensitive operations that amounts to full local system access (within the scope granted by the underlying OS). |
Read |
View almost all pages within Jenkins. |
RunScripts |
Run groovy scripts via the groovy console or groovy cli command. |
UploadPlugins |
Upload arbitrary plugins. |
ConfigureUpdateCenter |
Configure update sites and proxy settings. |
Slave
Permission |
Description |
---|---|
Configure |
Configure existing slaves. |
Delete |
Delete existing slaves. |
Create |
Create new slaves. |
Disconnect |
Disconnect slaves or mark slaves as temporarily offline. |
Connect |
Connect slaves or mark slaves as online. |
Job
Permission |
Description |
---|---|
Create |
Create a new job. |
Delete |
Delete an existing job. |
Configure |
Update the configuration of an existing job. |
Read |
Grants read-only access to project configurations. |
Discover |
Redirect anonymous users to a login form rather than presenting an error message if they don't have permission to view jobs. |
Build |
Start a new build and cancel a running build. |
Workspace |
Retrieve the contents of a workspace that Jenkins has checked out for performing a build. |
Cancel |
Cancel a running build. |
Run
Permission |
Description |
---|---|
Delete |
Delete specific builds from a build's history. |
Update |
Update the description and other properties of a build. (For example, to leave notes about the cause of a build failure.) |
View
Permission |
Description |
---|---|
Create |
Create new views. |
Delete |
Delete existing views. |
Configure |
Update the configuration of existing views. |
Read |
See any existing views. |
SCM
Permission |
Description |
---|---|
Tag |
Create a new tag in the source code repository for a given build. |
8 Comments
Unknown User (sergey_ryabov)
Hi.
I'm try set settings for 'project-based security' for disable 'grants the ability to cancel a build' . I performed initial steps in Configure Global Security page. I added 2 users, first - zzz with all grants and second - xxx with Job 'read' and 'build' grant. In my Job settings look like how in image below:
When i build Job as 'xxx', i can cancel a build. What am I doing wrong?
Unknown User (jenkins_fighter)
I have the same issue in one of the instances. Did you find a solution to this problem?
Unknown User (eduard)
My configuration includes a permission group "Credentials"/"Zugangsdaten" with selections for "Create, Delete, ManageDomains, Update, View". Can you give examples what these permissinos allow, especially when used with the LDAP authentication plugin?
Also, the permission group "Slave" has a selection for "Build". What is it good for?
Thanks.
Unknown User (daryaa)
Hello,
Selecting Read under Job does not seem to grant read-only access to project configurations. In fact, users with "Read" access do not have access to jobs' configuration page at all.
Am I missing anything here?
Unknown User (marco_jacob)
Is there a way to extend the security matrix for an own plugin?
We wrote an own plugin and use job build permission for restricted access.
However we need to define an own permission "deploy", so we can deny build but
offer deploy to users.
So far I found nothing to extend permission matrix.
Unknown User (widgetpl)
What about divide whole build job into smaller one like build, tests, deploy, notify and add desired permissions just for deploy job ?
Unknown User (marco_jacob)
Deploying the artefact with another job would be just a workaround.
Is there no possibility for plugins to extend the matrix?
We don't like to reuse an existing right but want to define our own.
Unknown User (marco_jacob)
I found the solution myself. Define static variables with PermissionGroup (optional, may use existing) and Permission in plugin class (class tagged with @DataBoundConstructor:
Without own group:
The null parameter can be a Localizable with ResourceBundle defining the locales if needed.