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.
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.
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
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.
CloudBees Jenkins Distribution version 2.176.x and later
CloudBees Jenkins Support version 2.176.x and later
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
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.
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.
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.
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.
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.
Online version published by CloudBees, Inc. under the Creative Commons Attribution-ShareAlike 4.0 license.
CloudBees and CloudBees DevOptics are registered trademarks and CloudBees Core, CloudBees CodeShip, CloudBees Jenkins Enterprise, CloudBees Jenkins Platform, CloudBees Jenkins Operations Center and DEV@cloud are trademarks of CloudBees, Inc.
Oracle and Java are registered trademarks of Oracle and/or its affiliates.
The registered trademark Jenkins® is used pursuant to a sublicense from the Jenkins project and Software in the Public Interest, Inc. Read more at www.cloudbees.com/jenkins/about.
Apache, Apache Ant, Apache Maven, Ant and Maven are trademarks of The Apache Software Foundation. Used with permission. No endorsement by The Apache Software Foundation is implied by the use of these marks.
Other names may be trademarks of their respective owners. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this content, and CloudBees was aware of a trademark claim, the designations have been printed in caps or initial caps.
While every precaution has been taken in the preparation of this content, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.