Preventing unauthorized interaction between builds

CloudBees Core customers 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 Core on modern cloud platforms, version 2.176.x and later.

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

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 masters, this may also permit a user to trigger a job on any other master in the same cluster.

Mitigating the problem

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

Configuring master-level isolation

For all cases

For all cases, first set your Operations Center security Authentication Mapping to "restricted" and disable "Allow per-master configuration of authentication mapping".

For Team Masters

If you are using Team Masters, replace instances of triggerRemoteJob and copyRemoteArtifact as detailed in Replacing triggerRemoteJob and copyRemoteArtifact.

Configure trigger restrictions

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

  1. Start with the Dashboard:

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

    trigger restrictions highlighted
  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:

    trigger restrictions interface
  4. Click the Save button to save your changes.

Using an allowlist for the trigger-restricted master

You may want to selectively permit other masters to trigger jobs on the trigger-restricted master. At a minimum, you should allowlist the trigger-restricted master itself so that you aren’t forced to manually execute builds!

To grant permission to other masters to run jobs on this master:

  1. Open the Trigger Restrictions interface by clicking on the name of the trigger-restricted master (in this case, Team B), and selecting Trigger Restrictions.

  2. In the value field, which you previously left empty, permit the trigger-restricted master to trigger jobs on itself by entering the following string:

    /teamB/**/*

    If you are unsure of what value to use for the master’s name, you can get the folder name by clicking on the name of the master in the navigation bar:

    name of master in navbar

    and use the value in the "Folder name" field:

    folder name
  3. Click the Save button to save your changes.

Using an allowlist for any other masters you want to permit

To give other masters permission to run jobs on the trigger-restricted master:

  1. Retrieve the Instance ID of the master you want to permit, using the URL:

    http://<URL OF MASTER>/license
  2. Open the Trigger Restrictions interface on the trigger-restricted master using Manage Jenkins  Configure System  Default Trigger Restrictions.

  3. Add a new line to the trigger restrictions:

    jenkins://<INSTANCE ID>/**/*

    For example, the Instance ID of the Team A master is fdaddf1bafd1ba4da0819d2e96654aad. To permit the Team A master to trigger jobs on the Team B master, the Trigger Restriction syntax on the Team B master is:

    jenkins://fdaddf1bafd1ba4da0819d2e96654aad/**/*
  4. Don’t forget to 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"}

Replacing triggerRemoteJob in Pipeline jobs

  1. For Pipeline jobs, triggerRemoteJob can be replaced with a "fire and forget" Event Driven Pipeline.

Replacing triggerRemoteJob in Freestyle, Matrix or Maven pipelines

  1. For freestyle, matrix, or maven pipelines, triggerRemoteJob can be replaced with a call to an intermediate Pipeline that uses publishEvent to trigger a remote job.

Replacing copyRemoteArtifact

Customers who wish to copy remote artifacts should strongly consider implementing a standalone Nexus or Artifactory instance, and replacing copyRemoteArtifact pipeline commands with shell script steps that use CLI commands to interact directly with the standalone Nexus or Artifactory instances.