Role-Based Access Control (RBAC)

Each scope has its own set of roles. This section specifically describes the roles defined in the Provider scope. RBAC definitions are constrained to be limited to a Provider scope to isolate the defined roles or access groups of one Provider from those of the others. All roles for the Tenant scope or other roles across multiple tenants with access to resources under Provider and Tenants, are maintained in the Provider scope. To learn more about the administrative scopes, see Administrative Scopes

The role-based access control is based on the following concepts:

  • Resource: Resources are objects related to everything on which user’s access privileges need to be specified.

  • Role: Role defines a set of access rights to each of the user accessible resources, for example, Read only, Read/Write or No Access. This role can be then used to assign rights to individual users via Access Group assignment.

  • Access Groups: Access groups constrain the access rights defined in the Role to a set of resource instances. Roles cannot be directly associated to a user, only Access Group can be assigned to a user

Users can be assigned any of these Roles through Access Group membership which define their access rights and the list of resource instances they can access. When Access Groups are defined, roles are mapped to resources. When these Access Groups are assigned to users, the users get access to specific resources and functionalities in the Harmony Controller as defined by the role. The list of resource instances can also be dynamically defined, for example, Tenant Admin is given access to resources such as devices in a clusters only if some partitions were assigned to the tenant by a Provider Admin.

Resource

Resources are objects in Harmony Controller that can be associated to a role. Provider account contains resources such as tenants and devices. Similarly, tenant account contains application services. If not specified, the default access right is No Access for any role definition. The default instance scope is All Instances if not constrained in an Access Group definition.

Following image shows a subset of resources and their hierarchical relationships to the three administrative scopes, shown in yellow boxes, to illustrate the Harmony resource objects.

_images/resource_RBAC.png

Role

Role enables users to access various resources and perform tasks in Harmony Controller. Roles are pre-defined in Harmony Controller. Administrative roles provide read-write access to the user and operational roles provides read-only access. Some roles may allow accessing large set of resources, while some roles restrict users with granular access for performing specific tasks.

A Role is a collection of individual administrative privileges that can be put together, like a template to administrator accounts. It is a template that defines the privileges that a specific kind of user such as Provider Admin or a Tenant Admin uses to access resource objects such as, providers, tenants, infra objects, and so on.

Important

Role cannot be directly assigned to a user. Access Groups define access rights for specific instances of a resource object which can be assigned to a group of users.

_images/canned_roles.png

Canned Roles and Auto-created Users

Harmony Controller provides 10 canned roles. Super Admin role is defined within the Controller scope, which does not have any access to provider scope of any Provider except for the root provider which is auto-created on installation. The other nine are all within the Provider Scope. Among those two are defined within a Tenant scope of one or more tenants that will be assigned during access group creation. The figure below illustrates these canned roles, their scopes and the auto-created users whenever a Provider is created.

_images/canned_roles_2.png

The following table lists all roles along with their privileges.

Role
Access
Access Type
Unavailable Menu Options
Provider Admin
Provider, Tenant, App services, Devices, Organization
Read-Write
None
Provider Operator
Provider, Tenant, App services, Devices, Organization
Read Only
None
Tenant Admin
Tenant, App services
Read-Write
Infrastructure, Utilities, Organizations, Provider or Cluster or Device Dashboards
Tenant Operator
Tenant, App services
Read Only
Infrastructure, Utilities, Organizations, Provider or Cluster or Device Dashboards
Partition Admin
Only to App Services associated with a Logical Partition
Read-Write
Infrastructure, Utilities (except CLI), Organizations, Provider or Cluster or Device Dashboards, Monitor (except Alerts & Reports)
Partition Operator
Only to App Services associated with a Logical Partition
Read Only
Infrastructure, Utilities, Organizations, Provider or Cluster or Device Dashboards, Monitor (except Alerts & Reports)
Infrastructure Admin
Devices and Device Configuration
Read-Write
Harmony Apps, Services, Organizations
Infrastructure Operator
Devices and Device Configuration
Read Only
Harmony Apps, Services, Organizations
Certificate Admin
SSL Certificate
Read-Write
Infrastructure, Organizations

Auto Created Users and their Roles and Access Groups

In Harmony Controller, super-admin user is created by default for managing and operating the Harmony Controller instance. Along with the user a Provider named root is auto-created and an access group called root provider admin. The user super-admin is also given the Provider Admin role by default but only for the root provider. Whenever a new provider is created a provider-admin role and a <provider name> provider admin access group is created. A provider-admin user is also auto-created with the contact details of the first user.

Root User Roles

The root user can have any of these roles:

  • Root user (can be Root Admin)

  • Root level-Tenant Admin

  • Root level-Tenant’s user

Administrator Roles

The administrator roles include:

  • Root-level Administrator

  • Provider-level Administrator

  • Tenant Administrator

Access Groups

Roles and resources are connected via access groups definitions. Access Group creation associates the object instance to a Role. It defines the scope for the access group in association with object instances. Access Groups define scopes on specific instances of a resource object for the access rights specified in a Role. Each user will be assigned one of these access groups specifying a list of object instances for each object level to which the access rights in the Role are defined.

Note that the list of instances is usually assigned statically when an access group is created but are also assigned dynamically based on policies (for example a Tenant Admin can have access rights to instances of cluster partitions that have been provisioned to a tenant by a Provider admin). Using access groups provides a consistent and efficient method of setting the privileges of administrators that have similar roles or the same role.

These access groups can be assigned to users so that they can be authorized to perform tasks as defined in access groups. To learn more about these access groups and how they can be used with local or external authorization, click Authentication and Authorization.

Auto Created Access Groups

Access groups for Provider Admins is pre-created in each Provider whenever a new Provider is created. Users with provider admin access can create other access groups. Any number of access groups can be created with combinations of roles and resources.

Access Group Privileges

The access group privilege is the user’s having privilege to a specific object. These are selected whenever an. Access. Group is created as shown in the screenshot below. Here for this Access group of Service-Admins that will use Partition Admin role the administrator has to select for the. Three resources: Tenants, Clusters and Logical Partitions what instances the user will have the rights described in the Role on. Also note that for Clusters even though here “all” is specified, the actual access list of resource instances will depend on dynamic RBAC policies embedded in the definition.

_images/access-group-privileges.png

Service Partition for ADC and Partition Admin Role

ACOS allows a special partition to be created within the actual Shared Partition of a Thunder device called Service Partition. Multiple Service Partitions can be created within a Shared Partition and some App Services can remain within the Shared Partition without belonging to any of the Service Partitions. Each of these Service Partitions when the Thunder gets onboarded to Harmony get mapped to a Logical Partition and becomes a resource that can be assigned to an Access group based on a Partition Admin role. With this mechanism ADC App Services in the Shared Partition can be grouped and the corresponding LP of the Service Partition can be assigned to different Access Groups which then can be assigned to different users

_images/service_partition.png