Jenkins
Child pages
  • Matrix-based security
Create child page
Skip to end of metadata
Go to start of metadata

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

  1. 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?

    1. Udit Jhalani

      I have the same issue in one of the instances. Did you find a solution to this problem?

  2. Eduard von Feek

    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.

  3. Darya A.Z.

    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? 

  4. 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.

    1. Mike Dziedziela

      What about divide whole build job into smaller one like build, tests, deploy, notify and add desired permissions just for deploy job ?

      1. 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.

    2. 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:

          private static final PermissionGroup PERMISSION_GROUP
              = new PermissionGroup(DeployBuilder.class, new Localizable(myResourceBundle, "MyPermissionGroupName"));
          protected static final Permission DEPLOY_PERMISSION
              = new Permission(PERMISSION_GROUP, "Deploy", null, Jenkins.ADMINISTER, PermissionScope.RUN);

      Without own group:

          protected static final Permission DEPLOY_PERMISSION
              = new Permission(Run.Permissions, "Deploy", null, Jenkins.ADMINISTER, PermissionScope.RUN);

      The null parameter can be a Localizable with ResourceBundle defining the locales if needed.

Write a comment…