Example Role-Based Access Control (RBAC) permission configurations

The following permission examples are solutions to common Role-Based Access Control (RBAC) permission configuration requirements and include the following conditions:

  • There are multiple teams of users sharing access to Operations Center.

  • The CloudBees CI instance is using a Role-Based Access Control (RBAC) authorization strategy.

    See Enabling the authorization strategy for more information.

  • The CloudBees CI instance has the Overall/Manage permission enabled.

    See Enabling the new permissions for more information.

    With the following roles:

    • Administrator: Member of a shared team, in charge of the security and the hosting of the solution. Has access to everything in the CloudBees CI instance.

    • Developer: Member of a team project, implementing features on a project.

    • Principal: Can also be called "tech lead" or "lead developer" in companies, is responsible for developers' code quality, and supports developers in their day-to-day work.

    • Tester: Member of a shared team, validates acceptance criteria in all projects across the company.

If you only need three groups, for instance an admin, developer, and read (browser) group, initialize RBAC with the Typical initial setup option in Manage Jenkins > Configure global security.
Selecting Typical initial setup
Figure 1. Selecting Typical initial setup

Roles and permissions setup using RBAC

The RBAC setup for the following permission examples includes two masters:

  • Master-A: Contains CI/CD jobs for the projects of team A.

  • Master-B: Contains CI/CD jobs for the projects of team B.

And the following project team-oriented groups:

  • Developers team A* and Developers team B: Will have read-only access to the Operations Center instance and will only be able to access its master. We will name these groups developer-team-A-group and developer-team-B-group.

  • Principal team A and Principal team B: Will have read-only access to the Operations Center instance with additional access to the master that has the team configuration. These teams are trusted to have management access to the master as well as developer access. We will name these groups principal-team-A-group and principal-team-B-group.

And shared team groups:

  • Tester team: Will have read-only access to the Operations Center instance and access to both Master-A and Master-B. We will name this group tester-team-group.

  • Admin team: Will be able to administer the Operations Center and masters systems. We will name this group admin-team-group.

Operations Center configuration

Creating roles

First, you need to create the roles on the Operations Center. From the Operations Center dashboard, select Roles > Manage in the left navigation pane. Then, add the following roles:

Leave the authenticated role with the Overall/Administer permission to avoid being locked out of the instance. Once the admin_role is assigned to an internal group, customize the permission in the authenticated role as required.
Role Permissions

read_role

  • Overall/ Read

  • Job/Read

admin_role

Overall/Administer (not filterable)

manager_role

  • Overall/Read

  • Overall/ Manage

  • Client/Managed Master/Configure

  • Client/Managed Master/Lifecycle

developer_role

  • Job/Build

  • Whatever additional permissions you want to include

authenticated, anonymous

No permissions

Example role set-up
Figure 2. Example role set-up

To add a new role:

  1. From the Operations Center dashboard, select Roles > Manage in the left navigation pane.

  2. Enter manager_role in Role to add and select Add.

  3. Select the Overall/Manage and Overall/Read permissions.

    The Overall/Manage permission will only appear if you have enabled it.

    See Enabling the new permissions for more information.

Overall/Manage permissions
Figure 3. Overall/Manage permissions
The admin_role role should NOT be filterable. Filterable means that the role can be removed on a sub-container (for example, a folder or a Managed Master). We want an Administrator to be an Administrator anywhere on the cluster.

Creating groups and assigning roles

Then you need to create the groups and assign the correct roles. From the Operations Center dashboard, select Groups > New Group in the left navigation pane. Then, create the following groups:

Context Group Role(s) Member(s)

ROOT (Operations Center and masters)

oc-admin-group

admin_role (current level/propagation)

All the administrator(s) of the Operations Center instance

ROOT (Operations Center and masters)

oc-read-group

read_role (current level/no propagation)

  • Developers and principal of team A

  • Developers and principal of team B

ROOT (Operations Center and masters)

oc-tester-group

read_role (current level/no propagation)

All testers

Do not forget to remove permissions from the authenticated and anonymous roles for the configuration once all groups and roles are created.
Example attribution of admin_role to the Admin group with propagation
Figure 4. Example attribution of admin_role to the Admin group with propagation

Masters configuration

After you have configured the roles and groups for the Operations Center, you need to configure the roles and groups for the masters. From the Master dashboard, select Groups > New Group in the left navigation pane. Then, create the following groups (for Master-B do the same and replace A with B):

Context Group Role(s) Member(s)

Master-A

developer-team-A

  • developer_role (current level/propagation)

  • read_role (current level/no propagation)

  • Developers and principal of team A

  • All testers (oc-tester-group)

Master-A

principal-team-A

  • manager_role (current level/propagation)

  • Principal of team A

Example of setup on Master-A with group inheritance from Operations Center and groups at master level
Figure 5. Example of setup on Master-A with group inheritance from Operations Center and groups at master level

Isolating permissions into folders at the master level

Some teams may want to have several levels of permissions inside one project team. For example, they may want developers to only have permission to create Pipeline jobs while the principals are able to create additional item types like Freestyle jobs.

This example uses the Roles and permissions setup using RBAC described above, adding the element of team folders. We concentrate on one master, Master-A, but similar or different configurations can be done in other masters.

Masters included in the following example need to have the CloudBees Folders Plus Plugin installed.

Master configuration

Create two folders on Master-A:

  • Team A pipelines: For all development-related continuous integration(CI), developers can create Pipeline jobs inside this folder.

  • Tech lead maintenance CI: For the principal(s) only, all job types are allowed, hidden for developers.

To create a Folder:

  1. From the master dashboard, select New Item.

  2. Select Folder from the list of options.

  3. Enter a name.

  4. Select OK.

Then you need to modify some group permission configurations. From the Master dashboard, select Groups in the left navigation pane. Then, modify the following groups (developer has only read_role at the ROOT level):

Context Group Role(s) Member(s)

Master-A

developer-team-A

  • read_role (current level/no propagation)

  • Developers and principal of team A

Master-A

principal-team-A

  • manager_role (current level/propagation)

  • developer (current level/propagation)

  • Principal of team A

Folder configuration

To configure the Team A pipelines folder:

  1. Select the Team A pipelines folder.

  2. At the bottom of the configuration, select the Restrict the kind of children in this folder checkbox.

  3. Next to This folder can contain the following items, select the Pipeline checkbox.

    Restrict folder to Pipeline jobs
    Figure 6. Restrict folder to Pipeline jobs
  4. Select Save.

  5. Select Groups in the left navigation pane.

  6. Select add some to add a group named Developers Team A - dev access.

  7. Select OK.

  8. Select the checkbox in the Granted column for the developer_role to assign the Developers Team A - dev access group the developer_role.

  9. Select Save.

  10. Select Add user/group.

  11. Add all developers of the project team A, including the principal, to the Developers Team A - dev access group.

    Group configuration for pipelines only folder
    Figure 7. Group configurations for pipelines only folder

You do not need to configure the Tech lead maintenance CI folder, as principal roles are propagated.

Developers can create pipelines and see the following
Figure 8. Developers can create pipelines and see the following
Principals can create folders
Figure 9. Principals can create folders, pipelines, and other items and can see the following
Overall view for administrator
Figure 10. Overall view for administrator, principal, and developer

Delegating the administration of groups at the master level to principal

This example uses the Roles and permissions setup using RBAC described above adding group management permissions to principal users at the master level.

Operations Center configuration

To configure the Operations Center, from the Operations Center dashboard, select Roles > Manage. Then add the following Group permissions to manager_role:

Role Permissions

manager_role

  • Overall/Read

  • Overall/ Manage

  • Client/Managed Master/Configure

  • Client/Managed Master/Lifecycle

  • Group/Configure

  • Group/Create

  • Group/Delete

  • Group/Manage

  • Group/View

Sign in to the Operations Center as a principal user of team A on master A. The principal user now has access to Groups > New Group in the left navigation pane, and can manage groups at the master level, but not at the Operations Center level.

Group configuration for principal users
Figure 11. Group configuration for principal users