Preventing unauthorized interaction between builds

Security

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

  • CloudBees CI 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 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.

Configuring controller-level isolation

For all cases

For all cases, first set your operations center security Authentication Mapping to "restricted" and disable "Allow per-controller configuration of authentication mapping".

For team controllers

If you are using team controllers, 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 controller:

  1. Start with the Dashboard:

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

  3. In the Trigger Restrictions interface, prevent any other controller from triggering jobs on this controller 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 controller:

  4. Click the Save button to save your changes.

Using an allowlist for the trigger-restricted controller

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

To grant permission to other controllers to run jobs on this controller:

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

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

    /teamB/**/*

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

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

  3. Click the Save button to save your changes.

Using an allowlist for any other controllers you want to permit

To give other controllers permission to run jobs on the trigger-restricted controller:

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

    http://<URL OF CONTROLLER>/license
  2. Open the Trigger Restrictions interface on the trigger-restricted controller using Manage Jenkins Configure SystemDefault Trigger Restrictions.

  3. Add a new line to the trigger restrictions:

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

    For example, the Instance ID of the Team A controller is fdaddf1bafd1ba4da0819d2e96654aad. To permit the Team A controller to trigger jobs on the Team B controller, the Trigger Restriction syntax on the Team B controller 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.