Centrally managing security for masters

Most administrators choose to strictly enforce their security configurations to ensure their organization remains compliant with their industry’s security requirements. CloudBees Core enables this use-case through the Operations Center security dashboard.

Out of the box, CloudBees Core 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 Core 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 Core.

Because CloudBees Core includes a CloudBees Verified version of the open-source LDAP Plugin, administrators can connect their organization’s authentication server to CloudBees Core by selecting ‘LDAP’ as the CloudBees Core cluster’s Security Realm within the Global Security Configuration. Security realms are a security domain for the CloudBees Core 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 Core by selecting Role-Based Access Control as CloudBees Core’s Authorization Strategy. An Authorization Strategy determines the set of permissions that a given user has on any specific object within CloudBees Core, including the permissions to create or delete configurations, update masters, and manage other users.

recommended config
Figure 1. Configuration for centrally managing master security

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 to manually connect agents to their master with minimal risk to the master’s security.