About Role-Based Access Control
Moab Web Services administrators use role-based access control to specify what operations each user can perform. They do this by assigning one or more roles to each user. Each role contains multiple permissions (such as create service template, power on/off nodes, and view reservations). By assigning a role to a user, an administrator grants each of that role's permissions to that user.
Example scenario
As part of his work, John needs to be able to create and manage services. The administrator therefore assigns John to the User role, which contains the create service and view services permissions.
Role-based access control is related to, but is not the same as, multi-tenancy. In order to function, Moab Web Services requires at least one tenant. By default, Moab Web Services creates a placeholder tenant named Organization when the system is installed or upgraded. If you do not need more than one tenant, this placeholder tenant is all you need. You will use this tenant to assign users to roles.
|
Image 4-1: Role-based access control model |
|
|
Click to enlarge |
Before you assign users to roles, there are a number of things to consider and to verify are properly set up. Role-based access control will only work for users that have been added to an LDAP server. Additionally, you should determine whether there is a need for multi-tenancy in your environment.
Prerequisites:
- Moab Web Services must be configured with an LDAP server. For more information, see LDAP Configuration Using mws-config.groovy.
- Moab Web Services users must be added to the LDAP server. Optionally, users can be organized in LDAP groups or organizational units (OUs).
For the how-to, see Setting Up and Provisioning a Tenant via the REST Interface or Provided Scripts.
Whether or not your organization has a single tenant or multiple tenants, assigning users to roles works exactly the same. Just remember that if your organization only requires one tenant, you'll use the default tenant named Organization for adding roles to users. If your organization includes multiple tenants, you'll need to create those tenants. (For more information, see Modeling Your Organization with Tenants).
Considerations for Using or Not Using Multi-Tenancy
Why use multi-tenancy?
Multi-tenancy isolates each tenant's services, jobs, and virtual machines from other tenants, which makes it impossible for a given tenant's work to run on the same nodes as other tenants' work.
Why not use multi-tenancy?
The following points out consequences of choosing multi-tenancy and alternatives to multi-tenancy:
- There are good alternatives. Administrative reservations isolate work. Another option is to create a physically separate cluster, which does require additional administration overhead, but it absolutely guarantees that work from the isolated department or project will not intermix.
- Multi-tenancy essentially divides a node cluster into two or more mini-clusters, which may impact scheduling efficiency.
- Adding multiple tenants makes it more difficult for an administrator to manage the cluster. Reproducing and debugging problems are thus more challenging, and role and user management are more complicated.
Moab Web Services automatically creates default roles when it is installed or upgraded.
Cloud
| Role | Description |
|---|---|
| User | Basic user, with permissions to start and view services. |
| PowerUser | Advanced user. In addition to starting and viewing services, can also create and manage service templates, and manage nodes. |
| Administrator | Has all permissions, including the ability to manage principals, roles, and permissions. |
HPC
| Role | Description |
|---|---|
| HPCAdmin | Has all permissions. Can manage principals, roles, and permissions, and can view and manage all jobs and reservations. |
| HPCUser | Basic user, with permissions to start and view their own jobs. |
CSA
| Role | Description |
|---|---|
| Administrator | Has all permissions. |
If the default roles described above don't meet your needs, administrators have the ability to create their own custom roles. You can customize roles via the Moab Web Services REST interface. See Editing an existing roleCreate Single Role in the MWS REST interface documentation.
The default roles can also be modified and even deleted. Care should be taken, however, when modifying these roles. Please consult Adaptive Computing Support or Professional Services for help.
If the default roles have been modified or deleted, a Moab Web Services administrator (moab-admin) can use the REST interface to reset these roles to their "factory" state.
POST /mws/rest/roles/reset-default?api-version=3
Resetting ensures that each of the default roles for the current suite have been created (or recreated), and that they contain all the default permissions they had when they were first created. This will not delete any roles or permissions, nor will it remove any permissions that may have been added to the default roles.
RBAC how-toRelated Topics