Setting up access controls on connected masters

You may want to limit the Developer teams’ access to only their team’s master while giving the Tester team access to both. This configuration protects teams from unauthorized users accessing their credentials and artifacts while still empowering a trusted team to access only the resources they need. Within the master itself, administrators can also set up specific permissions to restrict access on certain objects, such as a folder containing a "secret" internal project.

In this scenario, the administrator will configure permissions on two folders that exist on Master-1 - the developers-team-A-folder, which will be restricted to only the developers-team-A-group as a "secret project", and another-folder, which will be accessible by everyone logged into the instance.

oc rbac img 010

To achieve this, the administrator will configure the following groups and roles on the following masters:

Table 1. Sample master-level groups
Context Group Role(s) Member(s)

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

Once these settings are configured any member of the internal-developer-team-A-group who logs into Operations Center will only be able to access to the Master-1/developers-team-A-folder.