Example configurations

This section details some solutions to common configuration requirements. There are other ways to solve these configuration requirements, and there is no one "correct" solution for any of these, so it is better to think of these as examples of what can be done.

Operations Center instance shared along multiple teams with read/administration access in Operations Center

This example considers the case where there are multiple teams of users sharing the access to Operations Center. Only the administrator team has the permission to do any task in both the Operations Center instance and the client masters. The rest of the teams will only use Operations Center instance as an intermediate element to log-in.

In this example we have declared two client masters:

  • Master-1

  • Master-2

And four different teams:

  • Developers team A - will only have read access to the Operations Center instance and will only be able to access to Master-1. We will call this group as developer-team-A-group.

  • Developers team B - will only have read access to the Operations Center instance and will only be able to access to Master-2. We will call this group as developer-team-B-group.

  • Tester team - will only have read access to the Operations Center instance and will be able to access to Master-1 and Master-2. We will call this group as tester-team-group.

  • Admin team - will be able to administer the Operations Center and client masters systems. We will call this group as admin-team-group.

Sample solution.

  • 1. At Operations Center ROOT level create the groups internal-oc-admin-group and internal-oc-read-group and assign the roles admin_role and read_role respectively.

  • 2. At Master-1 level create the internal-master-1-group and assign both the developer_role and the read_role.

  • 3. At Master-2 level create the internal-master-2-group and assign both the developer_role and read_role.

Table 1. Sample roles for a Operations Center instance shared by different teams
Role Permissions

read_role

  • Overall | Read

  • Job | Read

admin_role

  • Overall | Administer

developer_role

  • Whatever permission you want to use

Table 2. Sample groups for an instance shared by different teams
Context Group Role(s) Member(s)

ROOT

internal-oc-admin-group

  • admin_role (current level/propagation)

All the administrator(s) of the Operations Center instance

ROOT

internal-oc-read-group

  • read_role (current level/no propagation)

  • developers-team-A-group

  • developers-team-B-group

  • tester-team-group

Master-1

  • internal-master-1-group

  • developer_role (current level/propagation)

  • read_role (current level/no propagation)

  • developers-team-A-group

  • tester-team-group

Master-2

  • internal-master-2-group

  • developer_role (current level/propagation)

  • read_role (current level/no propagation)

  • developers-team-B-group

  • tester-team-group

Step by step set-up.

  • 1. At Operations Center ROOT level create the groups internal-oc-admin-group and internal-oc-read-group and assign the roles admin_role and read_role respectively.

Create the following roles in the Operations Center ROOT context:

  • read_role enabling the Overall\Read and Job\Read permission.

  • admin_role with the administration permission.

  • developer_role with whatever permissions you want to use.

Notice that authenticated permission still has the Overall/Administer permission in order not to be blocked ourselves in the instance. Once the admin_role is assigned to a Jenkins internal group, we can customize the permission in the authenticated role as required.

From Operations Center dashboard click on Roles→Manage in the left side panel. Then, create the following roles.

oc rbac img 001
Figure 1. Manage Roles

Create the two internal groups.

  • internal-oc-read-group which contains all the groups which should have read access in Operations Center to only access the client master.

oc rbac img 002

Assign the read_role granted at current level without propagation.

oc rbac img 003

Add the members of this group.

oc rbac img 004
  • internal-oc-admin-group which contains all the Operations Center/client masters administrators.

oc rbac img 005

Assign the admin_role granted at current level with propagation.

oc rbac img 006

Add the members of this group.

oc rbac img 007

At this point, admin_role is fully set-up. However, users with read_role will only be able to read the Operations Center dashboard, but not to see any Client master. We still need to do the next step to sort this out.

  • 2. At Master-1 level create the internal-master-1-group and assign the read_role and the developer_role.

From Operations Center dashboard, click on the Groups option in the dropdown menu of the Master-1.

oc rbac img 008

Add a new internal group defined in Master-1 called internal-master-1-group.

oc rbac img 009

Assign the role read_role granted at current level without any propagation and the developer_role with propagation this time.

oc rbac img 010

Add the members of this group:

oc rbac img 011
  • 3. At Master-2 level create the internal-master-2-group and assign the developer_role and read_role.

The same approach in the point before can be done in Master-2 with the only difference that now we need to map developers-team-B-group and tester-team-group instead.

Do not forget to remove permissions to the Authenticated role for the configuration above to work properly.

Operations Center instance shared along multiple teams with read/administration access in Operations Center and isolating teams into folders at client master level.

Background.

This example considers the case where there are multiple teams of users sharing the access to Operations Center. Only the administrator team has the permission to do any task in both the Operations Center instance and the client masters. The rest of the teams will only use Operations Center instance as an element to log-in. One team will only be able to see the folder they belong to.

In this example we have declared two client masters:

  • Master-1

    • developers-team-A-folder (Working folder for developers-team-A-group)

    • another-folder (accesible by everyone)

  • Master-2

And four different teams:

  • Developers team A - will only have read access to the Operations Center instance and will only be able to access to Master-1. In Master-1 these users will only see the folder developers-team-A-folder. We will call this group as internal-developers-team-A-group.

  • Developers team B - will only have read access to the Operations Center instance and will only be able to access to Master-2. We will call this group as internal-developers-team-B-group.

  • Tester team - will only have read access to the Operations Center instance and will be able to access to Master-1 and Master-2. We will call this group as internal-tester-team-group.

  • Admin team - will be able to administer the Operations Center and client masters systems. We will call this group as internal-admin-team-group.

Sample solution.

  • 1. At Operations Center ROOT level create the groups internal-oc-admin-group and internal-oc-read-group and assign respectively the roles admin_role and read_role. Create the developer_role as well since it will be used later.

  • 2. At Master-1 create the internal group internal-developers-team-A-group and assign the read_role.

  • 3. At Master-1 create the internal group internal-master-1-group and assign the developer_role and the read_role.

  • 4. At Master-1/developers-team-A-folder level create the internal-master-1-group and assign the developer_role.

  • 5. At Master-2 level create internal-master-2-group and assign the developer_role.

Table 3. Sample roles for a Operations Center instance shared by different teams
Role Permissions

read_role

  • Overall | Read

  • Job | Read

admin_role

  • Overall | Administer

developer_role

  • Whatever permission you want to use

Table 4. Sample groups for an instance shared by different teams
Context Group Role(s) Member(s)

ROOT

internal-oc-admin-group

  • admin_role (current level/propagation)

All the administrator(s) of the Operations Center instance

ROOT

internal-oc-read-group

  • read_role

  • developers-team-A-group

  • developers-team-B-group

  • tester-team-group

Master-1

  • internal-developers-team-A-group

  • read_role (current level/no propagation)

  • developers-team-A-group

Master-1

  • internal-master-1-group

  • developer_role (current level/propagation)

  • read_role (current level/no propagation)

  • tester-team-group

Master-1/developers-team-A-folder

  • internal-developers-team-A-group

  • developer_role (current level/propagation)

  • developers-team-A-group

  • tester-team-group

Master-2

  • internal-master-2-group

  • developer_role (current level/propagation)

  • developers-team-B-group

  • tester-team-group

Step by step set-up.

  • 1. At Operations Center ROOT level create the groups internal-oc-admin-group and internal-oc-read-group and assign respectively the roles admin_role and read_role. Create the developer_role as well since it will be used later.

Create the following roles in the Operations Center ROOT context:

  • read_role enabling the Overall\Read and Job\Read permission.

  • admin_role with the administration permission.

  • developer_role with whatever permissions you want to use.

Notice that authenticated permission still has the Overall/Administer permission in order not to be blocked ourselves in the instance. Once we assigned the admin_role to a Jenkins internal group, we can customize the permission in the authenticated role as required.

From Operations Center dashboard click on Roles→Manage in the left side panel. Then, create the following roles.

oc rbac img 001
Figure 2. Manage Roles

Create the two internal groups:

  • internal-oc-read-group which contains all the groups which should have read access in Operations Center to only access the client master.

oc rbac img 002

Assign the read_role granted at current level without propagation.

oc rbac img 003

Add the members of this group.

oc rbac img 004
  • internal-oc-admin-group which contains all the Operations Center/client masters administrators.

oc rbac img 005

Assign the admin_role granted at current level with propagation.

oc rbac img 006

Add the members of this group.

oc rbac img 007

At this point, admin_role is fully set-up. However, users with read_role will only be able to read the Operations Center dashboard, but not to see any Client master. We still need to do the next steps to sort this out.

  • 2. At Master-1 create the internal group internal-developers-team-A-group and assign the read_role.

From Operations Center dashboard, click on the Groups option in the dropdown menu of the Master-1.

oc rbac img 008

Add a new internal group defined in Master-1 called internal-developers-team-A-group.

Assign the role read_role granted at current level without any propagation.

oc rbac img 012

Add the members of this group:

oc rbac img 013
  • 3. At Master-1 create the internal group internal-master-1-group and assign the developer_role and the read_role.

You need to do the exactly same operations than the point before but this time creating a group called internal-master-1-group which includes tester-team-group and assign the read_role and the developer_role.

oc rbac img 010
  • 4. At Master-1/developers-team-A-folder level create the internal-developers-team-A-group and assign the developer_role.

Create the group internal-master-1-group.

oc rbac img 014

Assign assign the developer_role granted at current level with propagation.

oc rbac img 015

Add the members of this group.

oc rbac img 016

Now, when any member of the internal-developer-team-A-group log-in in Operations Center will only be able to access to the Master-1/developers-team-A-folder and not any of the rest of the elements in the instance.

  • 5. At Master-2 level create internal-master-2-group and assign the developer role.

Understanding what is done in the previous section we should be able now to create the internal-master-2-group at Master-2 level and assign the developer_role permission.

Do not forget to remove permissions to the Authenticated role for the configuration above to work properly.

Operations Center Instance shared along multiple teams with read/admin access in Operations Center delegating the administration of groups at client master level to no-admin teams.

Background.

This example considers the case where there are multiple teams of users sharing the access to Operations Center. Only the administrator team has the permission to do any task in both the Operations Center instance and the client masters. The rest of the teams will only use Operations Center instance as an intermediate element to log-in. Client masters group-admins will be able to administer the role assignment inside the client master they belong to.

In this example we have declared two client masters:

  • Master-1

  • Master-2

And four different teams:

  • Developers team A - will only have read access to the Operations Center instance and will only be able to access to Master-1. We will call this group as developer-team-A-group.

  • Developers team B - will only have read access to the Operations Center instance and will only be able to access to Master-2. We will call this group as developer-team-B-group.

  • Groups administration team - will only have read access to the Operations Center instance and will be able only to access to Master-1 to configure groups inside the client masters. We will call this group as m1-groups-admin-team-group.

  • Admin team - will be able to administer the Operations Center and client masters systems. We will call this group as admin-team-group.

Sample solution.

  • 1. At Operations Center ROOT level create the groups internal-oc-admin-group and internal-oc-read-group and assign the roles admin_role and read_role respectively.

  • 2. At Master-1 level create the internal-master-1-group and assign both the developer_role and the read_role.

  • 3. At Master-1 level create the internal-m1-groups-admin-team-group and assign both the group_role and the read_role.

  • 4. At Master-2 level create the internal-master-2-group and assign both the developer_role and read_role.

Table 5. Sample roles for a Operations Center instance shared by different teams
Role Permissions

read_role

  • Overall | Read

  • Job | Read

admin_role

  • Overall | Administer

developer_role

  • Whatever permission you want to use

group_role

  • Group | View

  • Group | Manage

  • Group | Configure

Table 6. Sample groups for an instance shared by different teams
Context Group Role(s) Member(s)

ROOT

internal-oc-admin-group

  • admin_role (current level/propagation)

All the administrator(s) of the Operations Center instance

ROOT

internal-oc-read-group

  • read_role (current level/no propagation)

  • developers-team-A-group

  • developers-team-B-group

  • m1-groups-admin-team-group

Master-1

  • internal-master-1-group

  • developer_role (current level/propagation)

  • read_role (current level/no propagation)

  • developers-team-A-group

Master-1

  • internal-m1-groups-admin-team-group

  • group_role (current level/propagation)

  • read_role (current level/propagation)

  • m1-groups-admin-team-group

Master-2

  • internal-master-2-group

  • developer_role (current level/propagation)

  • read_role (current level/no propagation)

  • developers-team-B-group

Step by step set-up.

  • 1. At Operations Center ROOT level create the groups internal-oc-admin-group and internal-oc-read-group and assign the roles admin_role and read_role respectively.

Create the following roles in the Operations Center ROOT context:

  • read_role enabling the Overall\Read and Job\Read permission.

  • admin_role with the administration permission.

  • group_role enabling the Group\View, Group\Manage and Group\configure permission.

  • developer_role with whatever permissions you want to use.

Notice that authenticated permission still has the Overall/Administer permission in order not to be blocked ourselves in the instance. Once the admin_role is assigned to a Jenkins internal group, we can customize the permission in the authenticated role as required.

From Operations Center dashboard click on Roles→Manage in the left side panel. Then, create the following roles.

oc rbac img 017
Figure 3. Manage Roles

Create the two internal groups.

  • internal-oc-read-group which contains all the groups which should have read access in Operations Center to only access the client master.

oc rbac img 002

Assign the read_role granted at current level without propagation.

oc rbac img 003

Add the members of this group.

oc rbac img 019
  • internal-oc-admin-group which contains all the Operations Center/client masters administrators.

oc rbac img 005

Assign the admin_role granted at current level with propagation.

oc rbac img 020

Add the members of this group.

oc rbac img 007

At this point, admin_role is fully set-up. However, users with read_role will only be able to read the Operations Center dashboard, but not to see any Client master. We still need to do the next step to sort this out.

  • 2. At Master-1 level create the internal-master-1-group and assign the read_role and the developer_role.

From Operations Center dashboard, click on the Groups option in the dropdown menu of the Master-1.

oc rbac img 008

Add a new internal group defined in Master-1 called internal-master-1-group.

oc rbac img 009

Assign the role read_role granted at current level without any propagation and the developer_role with propagation this time.

oc rbac img 021

Add the members of this group:

oc rbac img 022
  • 3. At Master-1 level create the internal-m1-groups-admin-team-group and assign both the group_role and the read_role.

From Operations Center dashboard, click on the Groups option in the dropdown menu of the Master-1.

oc rbac img 008

Add a new internal group defined in Master-1 called internal-m1-groups-admin-team-group.

oc rbac img 023

Assign the role read_role and the group_role both with propagation.

oc rbac img 024

Add the members of this group:

oc rbac img 025
  • 4. At Master-2 level create the internal-master-2-group and assign both the developer_role and read_role.

Following the previous points, now you should be able to complete this step in Master-2. The main difference is that now you will need to map developers-team-B-group.

Do not forget to remove permissions to the Authenticated role for the configuration above to work properly.

Restricting jobs to run as a specific user using Role-Based Access Control and Authorize Project plugin

Background.

Jenkins Pipeline jobs run as the SYSTEM user by default, and this practice can be problematic when a pipeline is triggered by a specific user. For instance, with the SYSTEM user permissions, Pipeline builds are able to trigger any job in Jenkins, even if the user that triggered the original build does not have access to the downstream (triggered) job (for example if it’s protected using Role-Based Access Control).

In this example, there is one Master with one admin and two developers, each in different groups, using that master:

User Group(s)

admin

admin

developerA

groupA shared

developerB

groupB shared

  • Admin can access all folders and jobs on the master, due to the Overall | Administer permission:

restricting jobs admin view
  • developerA can only access jobs in the groupA and shared folders:

restricting jobs developer a view
  • developerB can only access jobs in the groupB and shared folders:

restricting jobs developer b view
  • Read access is granted to both groups at the top level, but it does not propagate to child folders:

restricting jobs browse group
  • Access to each group’s folder is configured by creating a group at the folder level, and granting the develop role to the correct group. In the following example, groupA is granted the develop role for the folder groupA (a similar configuration is done for the groupB and shared folders):

restricting jobs group a folder group
  • The unexpected behavior is that a job triggered by developerA is able to trigger a job in groupB:

restricting jobs issue demo

If developerA clicks the link for groupB » jobB #1, they will will be informed they don’t have access because access to that job has been restricted using Role-Based Access Control):

restricting jobs issue demo 404

To Restrict jobs to run as a specific user using Role-Based Access Control and the Authorize Project plugin:

  • The example settings for Role-Based Access Control have been demonstrated above. However, if you encounter the message ‘developerA’ lacks permission to run on ‘Jenkins’, ensure you have granted the Job / Build permission at the top level of the master for all users.

    To grant the Job / Build permission at the top level of a master for all users: . Grant the develop role to the shared group. . Uncheck the Propagates check box when creating the group to ensure the role does not propagate to the child folders. . Include the Job / Build permission in the develop role. While there are multiple ways to configure this setting, but this is one example:

    + image::cloudbees-common::example-configurations/restricting-jobs-develop-role-top-level.png[scaledwidth=90%]

  • If you do not already have the Authorize Project plugin installed, create a backup as per the Backup and Restore guide and install that plugin.

  • Configure the Authorize Project plugin settings at Manage JenkinsConfigure Global Security. The Project default Build Authorization settings are the settings used for any jobs that are triggered automatically, for example by a cron timer, or via webhooks:

    restricting jobs global config
  • For each job, select the appropriate default setting to be used when a user manually starts that build. This example uses Run as User who Triggered Build for jobA and shared, and Run as Specific User for jobB:

    restricting jobs job authorization

After configuring the settings described above, you should achieve the following results:

  • Builds of jobA and shared triggered by a user are run as the user who triggered the build, which means that developerA can no longer use jobA to trigger builds of jobB, since they do not have access to that job. The Jenkinsfile for this example is just one step: build 'groupB/jobB'

    restricting jobs job a manual trigger
  • developerA can still trigger the shared job from jobA, as expected since developerA has access to both of those jobs. The Jenkinsfile for this example is just one step: build 'shared/sharedJob'

    restricting jobs job a manual trigger job a shared
  • jobB will always run with the access rights of developerB since it was configured to Run as Specific UserdeveloperB. So even if admin triggers jobB, it will run as the developerB user and cannot trigger jobA since developerB does not have access. The Jenkinsfile for this example is just one step: build 'groupA/jobA'

    restricting jobs job b as admin
    Any cron triggers of builds or webhooks will run the build as the developerB user, so carefully consider the user account assigned. The Jenkinsfile for this example is just one step: build 'shared/sharedJob'
    restricting jobs cron trigger
    This example uses the Authorize Project plugin, which is a tier 3 community plugin and is subject to the support terms as documented in the CloudBees plugin support policies.