Access control

3 minute readAutomation

Access control is the CloudBees CD/RO functionality that provides security for all system objects. CloudBees CD/RO provides a comprehensive mechanism to control how individuals access the system.

  • Users must log in to view information or perform operations.

  • System access is limited based on:

    • The user’s name.

    • The groups to which that user belongs.

    • The permissions specified for various CloudBees CD/RO objects.

After you are familiar with the following information describing the access control system, review the two examples, Basic ACL Setup and Team ACL Setup, which provides insight to setup enhanced CloudBees CD/RO security at your site.


CloudBees CD/RO supports four privilege types for each object:

  • Read: Allows object contents to be viewed. In addition, users must have read privilege on the pipeline or release runtime in order to approve a manual task or gate rule.

  • Modify: Allows object contents (but not its permissions) to be changed.

  • Execute: If an object is a procedure or it contains procedures (for example, a project), this privilege allows object procedures to be invoked as part of a job. For resource objects, this privilege determines who can use this resource in job steps.

  • Change Permissions: Allows object permissions to be modified.

Users and groups

CloudBees CD/RO uses account information from multiple sources. In most cases, the primary account information source is an external LDAP or Active Directory repository:

  • Both user and group information is retrieved from the repository.

  • Local users and groups can be defined within CloudBees CD/RO.

To view user and group information, and to modify local user and group information, Administration  Users or Administration  Groups. External account information cannot be modified from here.

If the same user exists in multiple sources, only the highest priority name is used. A priority order is defined among external repositories, but local names have the highest priority. Thus, if you define a local user with the same name as an LDAP user, you will effectively mask the user in the LDAP account.

For local user accounts, only local groups are considered—group information from external repositories is not used. For accounts from a particular repository, groups from that repository are used along with local groups, but groups in other repositories are not considered.

In other words, you can define local groups in CloudBees CD/RO to supplement groups defined in external repositories. When you view information about users in CloudBees CD/RO, only relevant groups are shown. For example, when you view group information for a local user, only local groups are displayed.

Groups are managed by name only, without regard to source. If a particular group name exists in different repositories, there is no way to distinguish between these groups inside CloudBees CD/RO. Access given to one group is the same for any other group with the same name.

Special users and groups

The admin local user has special significance. If you are logged in as admin, you automatically have all privileges on all objects, regardless of any other system settings. This privilege set is a fallback mechanism in the event that too many privileges are removed for an object, leaving it unusable.

The admin account cannot be deleted.

If the admin account is missing, CloudBees CD/RO recreates the account the next time it starts up with password changeme.

The Everyone group is predefined by CloudBees CD/RO and cannot be deleted. Every user is automatically a member of the Everyone group.

For each project, CloudBees CD/RO uses the project name and automatically defines a user associated with that project, called the project principal. For example, the project principal for a project named nightly builds is project: nightly builds. Notice that there are two spaces in this name. This principal is used for jobs running under the project, as described in Access control and jobs .