CloudBees Jenkins Enterprise 1.x security
|CloudBees will no longer be supporting CloudBees Jenkins Enterprise 1.x after July 30, 2020. This end-of-life announcement allows CloudBees to focus on driving new technology and product innovation for CloudBees CI. For information on moving to CloudBees CI, please refer to CloudBees Jenkins Enterprise 1.x to CloudBees CI on modern cloud platforms migration guide which has been created to help you with the migration process. Existing customers can also contact their CSM to help ensure a smooth transition.|
Access controls are essential to ensure only authorized users have access to sensitive information, like credentials, to prevent potential malicious use of that information. In CloudBees Jenkins Enterprise, these controls are configured from a central dashboard in Operations Center and then enforced on all connected Managed or Client Masters.
Operations Center’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 Enterprise provides additional permission controls through:
Most administrators will choose to strictly enforce their security configurations to ensure their organization remains compliant with their industry’s security requirements. CloudBees Jenkins Enterprise enables this use-case through the Operations Center security dashboard.
Out of the box, CloudBees Jenkins Enterprise will create some basic security configurations restricting access to the cluster to only the administrator who created it. This protects the cluster from unauthorized and malicious access after the initial setup is complete.
The default password is the instance’s API token, which can be found on
Once logged in, navigate to Operations Center’s global security dashboard under themenu item.
Security will be enabled by default, but most administrators will also want to connect their existing authentication server to CloudBees Jenkins Enterprise to allow their organization’s users to quickly and easily onboard, while empowering the administrator to assign their organization’s existing groups certain access controls in CloudBees Jenkins Enterprise.
Because CloudBees Jenkins Enterprise includes a CloudBees Verified version of the open-source LDAP Plugin, administrators can connect their organization’s authentication server to CloudBees Jenkins Enterprise by selecting ‘LDAP’ as the CloudBees Jenkins Enterprise cluster’s Security Realm within the Global Security Configuration. Security realms are a security domain for the CloudBees Jenkins Enterprise cluster that identifies users and reports which groups a user belongs to within that realm.
Administrators can then set granular permissions on what users and groups can do within CloudBees Jenkins Enterprise by selecting Role-Based Access Control as CloudBees Jenkins Enterprise’s Authorization Strategy. An Authorization Strategy determines the set of permissions that a given user has on any specific object within CloudBees Jenkins Enterprise, including the permissions to create or delete configurations, update masters, and manage other users.
Most administrators should also opt to enforce that teams do not use any on-master executors to protect against a malicious user or script altering the master’s configuration. Most administrators should also ensure each connected master delegates their Security Realm and Authorization Strategy to the administrator’s definitions in the Operations Center security dashboard by enabling the
Single Sign-On (security realm and authorization strategy) enforcement policy.
In addition to propagating and enforcing security configurations in a cluster, Single Sign-On security mode provides a fallback mechanism for connected masters’ security in the event of Operations Center downtime. If Operations Center goes offline, the Client or Managed Master connected to Operations Center will fallback to using a local copy of the same Security Realm as defined in Operations Center. This fallback behavior allows connected masters to continue to authenticate users until Operations Center connectivity is restored.
|To enable this fallback behavior, ensure any plugins used for authentication in Operations Center are installed on all connected masters participating with Single Sign-On enabled.|
Administrators should also enable options for protecting connected masters from cross-site scripting (XSS) attacks and the Agent → Master Access Control option if they are not already on by default. Agent → Master Access Control__ restricts an agent’s permissions to prevent them from accessing files on a master, allowing teams who need to manually connect agents to their master with minimal risk to the master’s security.
For some advanced use-cases, administrators will need to further tweak the cluster’s security configurations to ensure connected masters have the correct permissions for those use cases.
If all masters in the CloudBees Jenkins Enterprise cluster will be Managed Masters and there are teams who will need the ability to promote artifacts and trigger jobs on other teams’ masters, administrators should also configure the CloudBees Jenkins Enterprise cluster’s Authentication Mapping to Trusted master with equivalent security realm .
This will grant Anonymous users permissions to view a team’s master and job configurations. These permissions will be used by a master in the CloudBees Jenkins Enterprise cluster to discover any downstream jobs on another team’s that it needs to trigger - e.g. a developer team’s master handing off an artifact to the QA team’s master for testing.
Operations Center acts as a gateway between each of the connected masters, so a request from one connected master to another will first be routed through Operations Center. Each request will be tagged with the authentication that originated the request.
Defining this default authentication mapping strategy standardizes Client Masters’ level of trust or authentication/authorization strategies and enables the cross-master communication necessary for teams to trigger jobs across their masters.
Changing the authentication mapping strategy
For security reasons, the authentication mapping cannot be updated while masters are connected to CloudBees Jenkins Enterprise.
After changing the authentication mapping, the connected masters must be reconnected to Operations Center because the authentication mapping is installed on connection to Operations Center’s remoting channel.
Administrators who anticipate performing bulk maintenance operations against their cluster’s masters and update centers will need to grant the Ad-hoc cluster operations authenticator access control for builds within the Operations Center Global Security Configuration. This option captures which user is performing an ad-hoc cluster operation in Operations Center and will run that operation with that user’s permissions.