Restricting access and delegating administration with Role-Based Access Control

Administrators with a CloudBees Core cluster supporting multiple teams of users can delegate some management powers to team leads and limit the permissions that unauthenticated and other users have to make changes and view items in the cluster. Delegating the assignment of such permissions to project administrators allows teams to define more granular permissions for specific projects and objects within their master, enabling them to do things like hiding a "secret" project from other teams.

These fine-grained permissions are enabled through the Role-Based Access Control (RBAC) Authorization Strategy defined by an administrator in the Operations Center Global Security Configuration.

Administrators will need to define various security roles for use in their cluster and assign those roles to groups of users, including groups and users imported from an authentication server like LDAP.

To illustrate this use case, consider the following scenario where an administrator has two configured client masters with some Folders configured for projects:

  • Master-1

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

    • another-folder (accessible by everyone)

  • Master-2

The administrator in this scenario will support four different teams with their CloudBees Core cluster. Each team will only need access and permissions over a very limited set of items within the context of the CloudBees Core cluster, specifically:

  • Developers team A - Within CloudBees Core, this group will be called internal-developers-team-A-group. They should only have read access to the Operations Center instance and only be able to access to Master-1. In Master-1, these users should only see the folder developers-team-A-folder.

  • Developers team B - Within CloudBees Core, this group will be called internal-developers-team-B-group. They should only have read access to the Operations Center instance and should only be able to access to Master-2.

  • Tester team - Within CloudBees Core, this group will be called internal-tester-team-group. They should only have read access to the Operations Center instance and should be able to access to Master-1 and Master-2.

  • Admin team - Within CloudBees Core, this group will be called internal-admin-team-group. They should be able to administer the Operations Center and client masters systems.

There are at least two levels of permissions for an administrator to consider when configuring permissions - permissions over the cluster itself (Operations Center-level) and permissions over particular masters, the administrator will first need to log into Operations Center and creates roles and groups.

Roles are sets of configured permissions that can be assigned to groups, and they are configured from the "Roles" > "Manage Roles" configuration page.

oc rbac img 001
Figure 1. Manage Roles

Out of the box, Operations Center offers two options - anonymous and authenticated. For this scenario, administrators will want to create 3 new roles in Operations Center with the following permissions:

Table 1. Sample roles for a CloudBees Core cluster
Role Permissions

read_role

  • Overall | Read

  • Job | Read

admin_role

  • Overall | Administer

developer_role

  • Overall | Read

  • Job | Read

  • Job | Configure

  • Job | Build