System 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. From the main menu, select to access the System access control page.
-
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.
-
For more information, refer to System access control objects.
Once you are familiar with the following system access control information, you can review the following examples, which provide insight to set up enhanced CloudBees CD/RO security at your site:
Privileges
CloudBees CD/RO supports four privileges for each object:
-
Read: Allows object contents to be viewed. In addition, users must have Read privileges on the pipeline or release runtime 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, select or . External account information cannot be modified. |
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. If you define a local user with the same name as an LDAP user, you 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.
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 the password changeme.
The Everyone group is predefined by CloudBees CD/RO and cannot be deleted. All users are 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, referred to as the project principal. For example, the project principal for a project named nightly builds is project: nightly builds. Notice there are two spaces in this name. This principal is used for jobs running under the project, as described in Access control for jobs.