Issue

You don’t know how to correctly set-up the RBAC plugin on a CJOC-CJE architecture.
Limit certain permissions to certain items for certain groups/users on a CJOC-CJE architecture.
How to match External Groups coming from LDAP or AD to Internal Groups in RBAC

Environment

CloudBees Jenkins Operation Center (CJOC)
CloudBees Jenkins Enterprise (CJE)
Authorization strategy: CloudBees Role-Based Access Control Plugin (RBAC) plugin
Security Realm: Active Directory (AD) or LDAP

Resolution

To explain the resolution of this issue, we propose to do it by defining a scenario.

Scenario

CJOC-CJE architecture, we have 3 different types of developers according to their permissions:
- Developer-GroupA
  - Associated with developerA-ext-group from AD
  - Has just access to Master jenkins-a
  - Has full Job permissions to all items
- Developer-GroupB
  - Associated with developerB-ext-group from AD
  - Has just access to Master jenkins-b
  - Has full Job permissions to all items
- Developer-GroupC
  - Associated with developerC-ext-group from AD
  - Has access to both jenkins-a and jenkins-b
  - Doesn’t have Job permissions except on the DevC folder in each of the master instances as follow:
    - Inside a DevC folder in jenkins-a, Developer-GroupC just can build job1 from a group of 4 jobs (“1 from all”).
    - Inside a DevCfolder in jenkins-b, Developer-GroupC can build all the jobs but not job1 (“all except 1”).
Apart from all that, this scenario also counts with a browser and an admin groups of users.

The following diagram helps to locate ourselves on which node we need to configure what in order to resolve the proposed scenario.
On the diagram red letters represent node names, in the following points we refer them as [$NODE_NAME]

Diagram of items

[ROOT] Security Realm description

Security Realm must be configured at root level, later it will be inherited by the client masters connect to it.

The following description will be valid for AD Global Catalog or LDAP.

Domain: DC=contoso, DC=com
User and Groups (Forest):
- OU = admin-ext-group, CN = admin1
- OU = admin-ext-group, CN = admin2
- OU = developers, OU = developerA-ext-group, CN = developer1
- OU = developers, OU = developerA-ext-group, CN = developer2
- OU = developers, OU = developerB-ext-group, CN = developer3
- OU = developers, OU = developerB-ext-group, CN = developer4
- OU = developers, OU = developerC-ext-group, CN = developer5
- OU = developers, OU = developerC-ext-group, CN = developer6
- OU = browser-ext-group, CN = browser

[ROOT] Set up Single Sing-On (security realm and authorization strategy)

This is the recommended configuration by CloudBees.

For this, go to $CJOC_URL/configureSecurity > Client master security > for Security Setting Enforcement select Single Sing-On (security realm and authorization strategy)

Note: Switching to this configuration, CJOC is going to override the root RBAC configuration of your client masters (CJE) - i.e. the $CJE_HOME/nectar-rbac.xml. In other words:
* Any roles/groups defined at the client master’s root level will be lost
* Groups defined at the Folder’s level will not be lost
So if you don’t want to lose your current RBAC root configuration, it is suggested to backup the $JENKINS_HOME/nectar-rbac.xml ( or the entire instance) of your Client Masters

[ROOT] Roles

Roles must be created at the highest parent level.

The following roles would solve the proposed scenario

administer –> Full permissions
overall-read –> Overall/read: Ability to log into Jenkins
job-read –> Job/read: Ability to discover items (Jobs) into a node. In the proposed scenario, there are several types of items (client master, folders or any type of jobs) and some of them are specific for each CJE or CJOC
developer –> All jobs permissions except Job/Build
job-build –> Job/Build
job-build-devC-filter –> Job/Build: It will be used as filter in [Item 2.2.1]

Note : Please understand “Job/Build” in the roles 4,5 and 6 as the permissions to restrict for certain items and for certain groups/users. It could be another one depending on your requirements.

[ROOT] Groups

Administrators
- Granted Rol: administer / at Current Level / Propagates enabled
- Members: admin-ext-group
Overall-Readers
- Granted Rol: overall-read / at Current Level / Propagates enabled
- Members: admin-ext-group

[Item 1] Groups

ClientMaster-1-Users
- Granted Rol: job-read / at Current Level / Propagates enabled
- Members: browser-ext-group, developerA-ext-group, developerC-ext-group

[Item 1.1] Groups

Item-Developer
- Granted Roles:
  - developer / at Current Level / Propagated no enabled
  - job-build / at Current Level / Propagated no enabled
- Members: developerA-ext-group

[Item 1.2] Groups

Builders-Dev
- Granted Roles:
  - developer / at Current Level / Propagates enabled
  - job-build / at Current Level / Propagates enabled
- Members: developerA-ext-group
None-Builders-Dev
- Granted Rol: developer / at Current Level / Propagates enabled
- Members: developerC-ext-group

[Item 1.2.1] Groups

None-Builders-Dev-Exception
- Granted Rol: job-build / at Current Level / Propagated no enabled
- Members: developerC-ext-group

[Item 2] Groups

ClienMaster-2-Users
Granted Rol: job-read / at Current Level / Propagated
Members: browser-ext-group, developerB-ext-group, developerC-ext-group

[Item 2.1] Groups

Item-Developer
- Granted Roles:
  - developer / at Current Level / Propagated no enabled
  - job-build / at Current Level / Propagated no enabled
- Members: developerB-ext-group

[Item 2.2] Groups

Builders-DevB
- Granted Roles:
  - developer / at Current Level / Propagates enabled
  - job-build / at Current Level / Propagates enabled
- Members: developerB-ext-group
Builders-DevC
- Granted Roles:
  - developer / at Current Level / Propagates enabled
  - job-build-devC-filter / at Current Level / Propagates enabled
- Members: developerC-ext-group

[Item 2.2.1] Roles - Filter

Filter by job-build-devC-filter

Demo Video

The following video shows the proposed scenario already configured and test it.

References

RBAC multiple configurations in a CJOC-CJE architecture