Table of contents

CloudBees Jenkins Distribution security guide


CloudBees Jenkins Distribution’s security options follow the standard Jenkins security model, offering two axes to security, as well as options for adjusting how strict enforcement of these security settings should be. Administrators can force connected masters to delegate all of their security settings, allow teams complete control over their own security settings, or delegate only some security settings to teams.

Preventing unauthorized interaction between builds

CloudBees Jenkins Distribution and CloudBees Jenkins Support customers may see Queue Authentication 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.

What the message means

This message alerts 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.

It’s important to note that these warnings do not necessarily indicate a security issue in all instances: each warning of this type should be individually evaluated for risks, including but not limited to:

  • The user being able to trigger builds which would ordinarily be inaccessible to them (like release builds) through the use of plugins like the Parameterized Trigger plugin or the build() step in a Jenkins Pipeline.

  • The user being able to retrieve sensitive data from build artifacts or workspaces associated with builds that would ordinarily be inaccessible under the current permissions.

Affected environments

  • CloudBees Jenkins Distribution version 2.176.x and later

  • CloudBees Jenkins Support version 2.176.x and later

When this risk does not apply

This security risk does not apply to the following configuration cases:

  • Untrusted users have permission to configure all jobs and view the results.

  • Untrusted users have permission to configure no jobs at all beyond globally applies Job/Configure permissions.

  • Untrusted users have Write permissions for Pipeline-as-Code definitions, either through the Jenkinsfile or through Pipeline Library definitions in Source Control Management (SCM). In these cases users can already modify Pipelines to access sensitive data and alter delivery functions without additional permissions.

  • Untrusted users have permission to configure and run jobs on the Jenkins master. This goes against best practices and is strongly discouraged, and if your system permits this, it should be reconfigured. If this case exists, users already have access to sensitive data and can alter the Jenkins configuration, which means that untrusted users are effectively given administrative privileges.

  • Untrusted users have Write permissions for the Jenkins home directory. This goes against best practices and is strongly discouraged.

Mitigating the issue

The best way to address these types of security issues is to isolate sensitive jobs to specific Jenkins masters. This configuration philosophy is called master-level isolation.

Master-level isolation

Job-level permissions that are assigned to individual users or user groups may not prevent users from taking actions that the UI would ordinarily prohibit. By contrast, master-level isolation permits you to isolate jobs from each other as required by organizational controls and restrictions. Master-level isolation also provides a mechanism through which you can prevent unauthorized users from triggering builds, or prevent unauthorized users from accessing sensitive data.

Master-level isolation is one of the recommended solutions for this issue, because sensitive Jenkins jobs and users are executed on their own instances, physically isolating data. This is also a good security-hardening measure, because it protects instances from contamination if a plugin grants users unauthorized access to data; only the plugins strictly required to run the jobs allocated to the master are installed.

Configuring master-level isolation

Features for managing multiple teams with fine-grained permissions, either in a single master or in connected masters, are available in CloudBees Core, but not in CloudBees Jenkins Distribution or Jenkins. However, there are some options for creating master-level isolation in CloudBees Jenkins Distribution or Jenkins:

  • CloudBees offers Docker and Marketplace images for CloudBees Jenkins Distribution, which you can use to quickly deploy multiple instances. For details on using the Marketplace images, see the blog post Start Using CloudBees Jenkins Distribution in the Cloud Today.

  • CloudBees products are being extended to provide support for the Configuration-as-Code plugin; once this plugin is fully supported by CloudBees Jenkins Distribution, it can be used to simplify the creation of masters with similar configurations.

Master-level isolation works best within CloudBees Core, which supports multi-master environments with SSO and a centralized user interface. CloudBees Core also offers features like Job Trigger Restrictions which can help you configure advanced restrictions for each instance.

If you are limited to a single master

In situations where you are limited to a single master, you can use the Authorize Project and/or Job Restrictions plugins to control permissions. These plugins are not recommended for inexperienced administrators, as their support level by CloudBees is best-effort only, with no SLA. There is also a risk that introducing a restrictive global configuration into an existing Jenkins instance with the Authorize Project plugin can disrupt the instance and possibly cause build failures or cause builds to be queued indefinitely.

For guidance on using these plugins, see the How to configure Access Control for Builds and Authorize Project plugin side effects articles in the CloudBees Knowledge Base. The known issues for the Authorize Project plugin are detailed in issue JENKINS-55624 in the Jenkins issue-tracking system.