Setting up access controls on connected controllers

SecurityAudit and compliance

You may want to limit the Developer teams’ access to only their team’s controller 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 controller 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 Controller-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.

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

Table 1. Sample controller-level groups
ContextGroupRole(s)Member(s)

ROOT

internal-oc-read-group

  • read_role

  • developers-team-A-group

  • developers-team-B-group

  • tester-team-group

Controller-1

  • internal-developers-team-A-group

  • read_role (current level/no propagation)

  • developers-team-A-group

Controller-1

  • internal-controller-1-group

  • developer_role (current level/propagation)

  • read_role (current level/no propagation)

  • tester-team-group

Controller-1/developers-team-A-folder

  • internal-developers-team-A-group

  • developer_role (current level/propagation)

  • developers-team-A-group

  • tester-team-group

Controller-2

  • internal-controller-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 Controller-1/developers-team-A-folder.