RBAC multiple configurations in a CJOC-CJE architecture

Article ID:223657648
4 minute readKnowledge base

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 controller jenkins-a

      • Has full Job permissions to all items

    • Developer-GroupB

      • Associated with developerB-ext-group from AD

      • Has just access to controller 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 controller 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.

Step by step resolution

Diagram of hierarchy of Items

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 controllers 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 Sign-On (security realm and authorization strategy)

This is the recommended configuration by CloudBees.

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

Switching to this configuration, CJOC is going to override the root RBAC configuration of your client controllers (CJE) - i.e. the $CJE_HOME/nectar-rbac.xml. In other words:
  • Any roles/groups defined at the client controller’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 controllers

[ROOT] Roles

Roles must be created at the highest parent level.

The following roles would solve the proposed scenario

  1. administer -→ Full permissions

  2. overall-read -→ Overall/read: Ability to log into Jenkins

  3. job-read -→ Job/read: Ability to discover items (Jobs) into a node. In the proposed scenario, there are several types of items (client controller, folders or any type of jobs) and some of them are specific for each CJE or CJOC

  4. developer -→ All jobs permissions except Job/Build

  5. job-build -→ Job/Build

  6. 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
  • Clientcontroller-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
  • Cliencontroller-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.

Demo video