Setting up Operations Center-level access controls

In this scenario, the administrator wants to delegate administer permissions, so the internal-oc-admin-group will be assigned the default pre-configured admin_role. All users in that group will be able to perform cluster management functions in Operations Center, so membership for this group should be limited to only the Admin team in this example organization. This configuration is propagated to all connected masters, so Operations Center-level admins will also have administer permissions over those masters.

For non-admin teams, the administrator will want to prevent them from changing any configurations to the cluster in Operations Center, and so the administrator will need to create another group - internal-oc-read-group - and assign to that group the pre-configured read_role. Developer teams and Tester team belong in this group, as they will have limited interactions with Operations Center and therefore do not need any permissions above read access at the Operations Center-level.

oc rbac img 002

Groups can be created and configured from the "Groups" item in the left-hand menu. Once a group has been added, administrators will be able to assign roles and users to the group.

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

ROOT

internal-oc-admin-group

  • admin_role (current level/propagation)

All the administrator(s) of the Operations Center instance

ROOT

internal-oc-read-group

  • read_role

  • developers-team-A-group

  • developers-team-B-group

  • tester-team-group

oc rbac img 004

Once the administrator has added themselves to a group with the admin_role, the administrator should disable the default roles of authenticated and anonymous. The *authenticated permission includes overall administration permissions and is no longer necessary once a formal admin role exists and is assigned to an administration group.