This content applies only to CloudBees CI on modern cloud platforms.
Administrators can choose to strictly enforce their security configurations to ensure their organization remains compliant with their industry’s security requirements. CloudBees CI enables this use-case through the operations center security dashboard.
Out of the box, CloudBees CI requires an initial password, which can be retrieved from the Getting Started window when you set up the operations center. See Connecting a client controller to operations center.
|
For {CI-MODERN}, passwords are retrieved using the following command.
This password can be used to do the initial installation of operations center using the Setup Wizard. |
Once the Setup Wizard is completed, navigate to operations center’s global security dashboard under the Manage Jenkins > Global Security menu item.
Most administrators want to connect their existing authentication server to CloudBees CI 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 CI.
Because CloudBees CI includes a CloudBees Verified version of the open-source LDAP Plugin, administrators can connect their organization’s authentication server to CloudBees CI by selecting ‘LDAP’ as the CloudBees CI cluster’s Security Realm within the Global Security Configuration. Security realms are a security domain for the CloudBees CI 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 CI by selecting Role-Based Access Control as CloudBees CI’s Authorization Strategy. An Authorization Strategy determines the set of permissions that a given user has on any specific object within CloudBees CI, including the permissions to create or delete configurations, update controllers, and manage other users.
The following options control individual policy settings that are applied to all controllers. These options are enabled by default:
-
Enforce Cross Site Request Forgery exploits prevention settings
A cross-site request forgery, or CSRF/XSRF, is an exploit that enables an unauthorized third party to perform requests against a web application by impersonating another, authenticated, user. In the context of a Jenkins environment, a CSRF attack could allow a malicious actor to delete projects, alter builds, or modify the Jenkins system configuration.
To guard against this class of vulnerabilities, CSRF protection has been enabled by default with all Jenkins versions since 2.0. You should enable this option for connected controllers to protect from CSRF attacks, if it is not on by default. For more information, please refer to CSRF Protection.
Selecting this option prevents controllers from disabling this projection.
-
Enforce markup formatter settings
Certain features in Jenkins allow authorized users to add free-form text, such as job descriptions, user descriptions, view descriptions, and build descriptions to the user interface.
By default, these free-form text fields only allow plain text, but allowing richer formatting is a useful feature. The OWASP Markup Formatter Plugin is included by default in Jenkins. It allows you to use a subset of HTML elements that are safe, such as hyperlinks, bold, and italic.
Selecting this option applies and enforces the markup formatter settings specified on operations center and across all connected controllers. Please see https://www.jenkins.io/doc/book/managing/security/#markup-formatter for more information.
-
Enforce agent → controller security settings
In previous versions, Jenkins controllers and agents behaved as if they all together form a single distributed process. This means an agent can ask a controller to do just about anything within the confinement of the operating system, such as accessing files on the controller or triggering other jobs on Jenkins. This has become increasingly problematic, as larger enterprise deployments have developed a more sophisticated trust separation model, where the administrators of a controller might take ownership of agents owned by other teams. In such an environment, agents are less trusted than the controller.
Starting with versions 1.587 and 1.580.1, Jenkins added a subsystem to separate a controller and agent to safely allow less trusted agents to be connected to controllers. Since Jenkins 2.0, this subsystem is enabled for all new Jenkins installations. If you fit the "larger enterprise deployment" description above, CloudBees highly recommends that you turn this mode on. The following are examples of deployments that fit this profile:
-
You took agents that are managed by another person who is not a Jenkins administrator because they have special requirements for their build jobs.
-
You have some jobs that are configured to run on a specific agent because it is sensitive.
On the other hand, if all your agents are trusted to the same degree as your controller, then it is safe to leave this subsystem off. The following are examples that fit this profile:
-
You have set up your Jenkins controller and all agents by yourself
-
All your Jenkins users have the same access to all the jobs
Selecting this option applies and enforces the Enforce agent → controller security settings specified on the operations center across all connected controllers.
-
-
Enforce remember me settings
By default, Jenkins supports the ability for a user to check the Remember me checkbox when logging in, which persists a session cookie that will be used on subsequent logins. Although convenient for users, some administrators may consider this to be a security risk, and as such, it can be disabled under Jenkins > Configure Global Security > Disable remember me.
Selecting this option applies and enforces the remember me setting specified on the operations center across all connected controllers.
Most administrators should also opt to enforce that teams do not use any on-controller executors to protect against a malicious user or script altering the controller’s configuration.
Most administrators should also ensure each connected controller 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 controllers' security in the event of operations center downtime. If operations center goes offline, the Client or managed controller 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 controllers 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 controllers participating with Single Sign-On enabled. |