Restricting jobs to run as a specific user using Role-Based Access Control and Authorize Project plugin

3 minute readSecurityAudit and compliance

Pipeline jobs run as the SYSTEM user by default, and this practice can be problematic when a pipeline is triggered by a specific user. For instance, with the SYSTEM user permissions, Pipeline builds are able to trigger any job in Jenkins, even if the user that triggered the original build does not have access to the downstream (triggered) job (for example if it’s protected using Role-Based Access Control.

In this example, there is one controller with one admin and two developers, each in different groups, using that controller:





groupA shared


groupB shared

  • Admin can access all folders and jobs on the controller, due to the Overall | Administer permission:

  • developerA can only access jobs in the groupA and shared folders:

  • developerB can only access jobs in the groupB and shared folders:

  • Read access is granted to both groups at the top level, but it does not propagate to child folders:

  • Access to each group’s folder is configured by creating a group at the folder level, and granting the develop role to the correct group. In the following example, groupA is granted the develop role for the folder groupA (a similar configuration is done for the groupB and shared folders):

  • The unexpected behavior is that a job triggered by developerA is able to trigger a job in groupB:

If developerA clicks the link for groupB » jobB #1, they will will be informed they don’t have access because access to that job has been restricted using Role-Based Access Control):

To Restrict jobs to run as a specific user using Role-Based Access Control and the Authorize Project plugin:

  • The example settings for Role-Based Access Control have been demonstrated above. However, if you encounter the message ‘developerA’ lacks permission to run on ‘Jenkins’, ensure you have granted the Job / Build permission at the top level of the controller for all users.

    To grant the Job / Build permission at the top level of a controller for all users: . Grant the develop role to the shared group. . Uncheck the Propagates check box when creating the group to ensure the role does not propagate to the child folders. . Include the Job / Build permission in the develop role. While there are multiple ways to configure this setting, but this is one example:

    + image::cloudbees-common::rbac-authorize-project-plugin/restricting-jobs-develop-role-top-level.png[scaledwidth=90%]

  • If you do not already have the Authorize Project plugin installed, create a backup as per the Backup and Restore guide and install that plugin.

  • Configure the Authorize Project plugin settings at Manage JenkinsConfigure Global Security. The Project default Build Authorization settings are the settings used for any jobs that are triggered automatically, for example by a cron timer, or via webhooks:

  • For each job, select the appropriate default setting to be used when a user manually starts that build. This example uses Run as User who Triggered Build for jobA and shared, and Run as Specific User for jobB:

After configuring the settings described above, you should achieve the following results:

  • Builds of jobA and shared triggered by a user are run as the user who triggered the build, which means that developerA can no longer use jobA to trigger builds of jobB, since they do not have access to that job. The Jenkinsfile for this example is just one step: build 'groupB/jobB'

  • developerA can still trigger the shared job from jobA, as expected since developerA has access to both of those jobs. The Jenkinsfile for this example is just one step: build 'shared/sharedJob'

  • jobB will always run with the access rights of developerB since it was configured to Run as Specific UserdeveloperB. So even if admin triggers jobB, it will run as the developerB user and cannot trigger jobA since developerB does not have access. The Jenkinsfile for this example is just one step: build 'groupA/jobA'

    Any cron triggers of builds or webhooks will run the build as the developerB user, so carefully consider the user account assigned. The Jenkinsfile for this example is just one step: build 'shared/sharedJob'
    This example uses the Authorize Project plugin, which is a tier 3 community plugin and is subject to the support terms as documented in the CloudBees plugin support policies.