Preventing unauthorized interaction between builds

3 minute read

Customers operating either of the following configurations:

  • CloudBees CI on traditional platforms

  • Standalone masters (instances of CloudBees CI on traditional platforms that are neither managed by nor connected to operations center)

may see "build warnings" displayed in the user interface.

These warnings read:

Builds in Jenkins run as the virtual SYSTEM user with full permissions by default. This can be a problem if some users have restricted or no access to some jobs, but can configure others. If that is the case, it is recommended to configure the system and jobs to prevent unauthorized interaction between builds.

Affected environments

  • CloudBees CI on traditional platforms, version 2.176.x and later.

  • Standalone CloudBees CI on traditional platforms masters, version 2.176.x and later (masters not managed by or connected to operations center).

What the message means

This message is intended to alert administrators to potential escalation-of-privileges vulnerabilities. These vulnerabilities may occur when the system is configured with a permissions scheme that is more complex than a basic scheme like “all authenticated users are administrators” or “only one user is an administrator”.

This message indicates that under the current permissions scheme, the permissions that permit a user to configure and trigger one job may also permit the user to trigger another job, even if the UI would ordinarily prevent such an action. Depending on the configuration in operations center and/or on other controllers, this may also permit a user to trigger a job on any other controller in the same cluster.

Mitigating the problem

Mitigating the issue involves a configuration philosophy that is called controller-level isolation. Controller-level isolation can be combined with restricted controllers or job restrictions to prevent jobs from being triggered across controllers.

Transitioning to CloudBees CI and Team Masters

CloudBees strongly recommends transitioning to CloudBees CI with operations center, which provides the ability to configure and manage multiple masters (the team masters feature).

To upgrade your CloudBees CI on traditional platforms instance, contact your CloudBees support representative.

For standalone masters

You can still practice master-level isolation with standalone masters.

For each of your standalone masters, follow these steps to configure trigger restrictions for each top-level folder on the master.

Permissions are by default inherited from the parent, whether that parent is a folder or the root of the master. If you’ve specified permissions for a subfolder that are different from those of the parent, you should also configure trigger restrictions on the subfolder as appropriate.

Configure trigger restrictions

Configure trigger restrictions at the root level of each folder within the master:

  1. Start with the Dashboard:

  2. Click on the down-arrow to the right of the master for which you want to set the trigger restriction, and choose "Trigger Restrictions":

  3. In the Trigger Restrictions interface, prevent any other master from triggering jobs on this master by selecting "Overwrite Job Trigger Restrictions" and leaving the value field empty. A blank field implicitly denies the execution of jobs to everyone, including anyone on this master:

  4. Click the Save button to save your changes.

How to tell if your trigger restrictions are working

To see if your trigger restrictions are working, review the messages in the instance’s syslog log.

A trigger restriction that is denying triggers will display messages similar to:

INFO: Rejecting build on [teamB/Team-B-Pipeline] as the upstream job/s [jenkins://fdaddf1bafd1ba4da0819d2e96654aad/teamA/Team-A-pipeline] do not match trigger restrictions on folder [teamB]

A trigger restriction that is permitting triggers from a trusted source will display messages similar to:

INFO: Received trigger RemoteTrigger{authentication=ACL.SYSTEM, target=jenkins://fdaddf1bafd1ba4da0819d2e96654aad/teamB/Team-B-Pipeline, source=jenkins://fdaddf1bafd1ba4da0819d2e96654aad/teamA/Team-A-pipeline, sourceNumber=15, futureId[FINISHED]="ba6263a0-fca8-4135-928c-54cd0b136f43/7"}