CloudBees CI customers may see "build warnings" displayed in the user interface. These warnings read:
Builds in {JOSS} 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.
-
Standalone CloudBees CI on traditional platforms controllers, version 2.176.x and later (controllers 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.
CloudBees CI on modern cloud platforms
This content applies only to CloudBees CI on modern cloud platforms.
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:
-
Start with the Dashboard:
-
Click on the down-arrow to the right of the controller for which you want to set the trigger restriction, and choose "Trigger Restrictions":
-
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:
-
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:
-
Open the Trigger Restrictions interface by clicking on the name of the trigger-restricted controller (in this case, Team B), and selecting Trigger Restrictions.
-
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:
-
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:
-
Retrieve the Instance ID of the controller you want to permit, using the URL:
http://<URL OF CONTROLLER>/license -
Open the Trigger Restrictions interface on the trigger-restricted controller using .
-
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/**/* -
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
-
For Pipeline jobs,
triggerRemoteJobcan be replaced with a "fire and forget" Event Driven Pipeline.
Replacing triggerRemoteJob in Freestyle, Matrix or Maven pipelines
-
For freestyle, matrix, or maven pipelines,
triggerRemoteJobcan be replaced with a call to an intermediate Pipeline that usespublishEventto 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.
CloudBees CI on traditional platforms
This content applies only to CloudBees CI on traditional platforms.
Transitioning to CloudBees CI and team controllers
CloudBees strongly recommends transitioning to CloudBees CI with operations center, which provides the ability to configure and manage multiple controllers (the Team controllers feature).
To upgrade your CloudBees CI on traditional platforms instance, contact your CloudBees support representative.
For standalone controllers
You can still practice controller-level isolation with standalone controllers.
For each of your standalone controllers, follow these steps to configure trigger restrictions for each top-level folder on the controller.
| Permissions are by default inherited from the parent, whether that parent is a folder or the root of the controller. 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 controller:
-
Start with the Dashboard:
-
Click on the down-arrow to the right of the controller for which you want to set the trigger restriction, and choose "Trigger Restrictions":
-
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:
-
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"}