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

3 minute readKnowledge base

Issue

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.

Environment

Resolution

The best practice would be to use Trigger restrictions to restrict job triggers.

There is also an alternative solution using the plugin 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.

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

User Group(s)

admin

admin

developerA

groupA shared

developerB

groupB shared

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

restricting jobs admin view

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

restricting jobs developer a view

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

restricting jobs developer b view

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

restricting jobs browse group

  • 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):

restricting jobs group a folder group

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

restricting jobs issue demo

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):

restricting jobs issue demo 404

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:

    1. Grant the develop role to the shared group.

    2. Uncheck the Propagates check box when creating the group to ensure the role does not propagate to the child folders.

    3. Include the Job / Build permission in the develop role. While there are multiple ways to configure this setting, but this is one example:

      restricting jobs develop role top level

  • 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 Jenkins → Configure 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:

    restricting jobs global config

  • 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:

    restricting jobs job authorization

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'

    restricting jobs job a manual trigger

  • 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'

    restricting jobs job a manual trigger job a shared

  • jobB will always run with the access rights of developerB since it was configured to Run as Specific User → developerB. 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'

    restricting jobs job b as admin
    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'
    restricting jobs cron trigger
    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.

Tested product/plugin versions

CloudBees CI on Traditional Platforms, version 2.176.4.3 Authorize Project plugin, version 1.3.0

This article is part of our Knowledge Base and is provided for guidance-based purposes only. The solutions or workarounds described here are not officially supported by CloudBees and may not be applicable in all environments. Use at your own discretion, and test changes in a safe environment before applying them to production systems.