Centrally managing security for masters

4 minute readSecurityAudit and compliance

Most administrators 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 using the following command.

kubectl rollout status sts cjoc
kubectl exec cjoc-0 -- sh -c "until cat /var/jenkins_home/secrets/initialAdminPassword 2>&-; do sleep 5; done"

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.

Configuration for centrally managing controller security

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. For more information, please see https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery.

    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 → master security settings

    Historically, 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 → master 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 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 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.

Administrators should also enable options for protecting connected controllers 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 controller, allowing teams to manually connect agents to their controller with minimal risk to the controller’s security.