ViPR 2.2 - Understanding ViPR Users, Roles, and ACLs
Table of Contents
ViPR users must belong to an Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) domain that has been registered as a ViPR authentication provider. Users who belong to a registered AD/LDAP domain can be given access to a ViPR tenant using a set of rules, the simplest of which is that users who belong to a domain can authenticate with ViPR.
ViPR has two types of users: end users and administrators. End users consist of provisioning users and data services users. Provisioning users create and manage file and block storage, mainly using the services in the service catalog. Data services users consume ViPR object storage; they authenticate with ViPR in order to be allowed to obtain a secret key which enables them to access object storage directly.
End users in ViPR have no explicit role assigned to them. All users who belong to a domain contributed by an authentication provider, and have been mapped into a tenant, can access the UI and perform end-user operations. For end users, access to certain ViPR functions is restricted using an access control list (ACL).Back to Top
The following table lists the available roles and their scope:
The Security Administrator assigns users into ViPR virtual data center roles and can assign users into tenant roles. The Tenant Administrator can assign users to the tenant roles.
After ViPR is deployed, there is a root user (superuser) which has all VDC roles and the Tenant Administrator role for the provider tenant. The root user acts as the bootstrap user for the system by assigning one or more users to the Security Administrator role. The Security Administrator can then assign other user roles.Back to Top
What a user can do when they log in to a site depends on whether they are assigned to a ViPR role and whether the role is a VDC or a tenant role.
VDC roles are specific to a VDC. A user who has a VDC role in a VDC, such as System Administrator, does not have that role in a linked VDC unless the user is specifically assigned to that role in the linked VDC.
Tenants and authentication providers are global resources, so tenants and tenant roles are available at any VDC and have the same meaning at all linked sites; a user assigned to the Tenant Administrator role for a tenant has that role at whichever site he or she logs in at. End user who belong to a tenant can see the tenant resources that are replicated (such as projects) at whichever site they log in at. The service catalog and service are not replicated and so are specific to a VDC.
Similarly, the virtual infrastructure that end users access in order to provision file and block storage, and the storage volumes and file systems that they create, are VDC resources and are specific to the site at which the user is logged in.
Root user in federated sites
- Root user from one VDC cannot log in to another VDC. For example, root user of vdc1 cannot log in to vdc2.
- Root user cannot perform any tenant management operations, such as creating projects, changing ACLs on projects, granting or revoking tenant roles, etc.
- Root user cannot perform any authorization provider management operations.
- Root user cannot perform Security Administrator or System Administrator tasks on global resources.
- Create new tenants (this only applies to the Tenant Administrator for the provider tenant)
- Assign users to tenant roles (can also be performed by a Security Administrator).
- Map users into a tenant.
- Customize the service catalog, add hosts, clusters, and vCenters, create projects, create consistency groups, create execution windows etc.
- The Security Administrator for the VDC can assign the Tenant Administrator role for a sub-tenant to a member of the sub-tenant, or to a member of the provider tenant. The latter is useful where you want a member of the provider tenant to be assigned as Tenant Administrator for the provider tenant and other tenants.
- The Tenant Administrator for the provider tenant can assign the Tenant Administrator role to a user who is a member of the provider tenant.
- The Tenant Administrator for a sub-tenant can assign the Tenant Administrator role to a user who is a member of the same sub-tenant.
- The Tenant Administrator for the provider tenant can also be the administrator for a sub-tenant even though the user does not belong to the sub-tenant. In fact, any member of the provider tenant is eligible to be assigned as the Tenant Administrator of a sub-tenants.
A Tenant Administrator for the provider tenant cannot automatically perform administration of sub-tenants, this only applies to sub-tenants for which they are assigned the Tenant Administrator role (usually due to creating the tenant).
- The Tenant Administrator that creates a sub-tenant is, by default, assigned to the Tenant Administrator role for the new tenant.
Where a provider Tenant Administrator is also a Tenant Administrator for a sub-tenant, the ViPR UI enables the user to perform administration on any tenant for which he or she is the Tenant Administrator and provides a drop-down to select the tenant on which an operation will be performed, as shown below.
- Assigning the provider Tenant Administrator as the Tenant Administrator of sub-tenants is useful in allowing a single user, from the provider tenant, to perform administration of all tenants. However, it does not change their user environment. A user mapped into the provider tenant, when performing user operations, will see:
- the service catalog for the provider tenant only
- the projects that they belong to in the provider tenant only
- the resources that belong to the provider tenant only
- the consistency groups for the provider tenant only
- the execution windows for the provider tenant only
- hosts belonging to the provider tenant only
They will not see the equivalent resources for the other tenants in which they have been assigned the Tenant Administrator role.It is important to understand the distinction between user and administration operations. When a user from the provider tenant who is a Tenant Administrator for more than one tenant performs project administration, such as editing the service catalog or creating projects, they can perform that task for any of their assigned tenants. However, when they view the service catalog they will only see the service catalog for their home tenant, and when they perform provisioning operations they will only be able to assign resources to projects that belong to their home tenant.
To avoid confusion, it is recommend that Tenant Administrators who also want to perform end-user operations, such as storage provisioning, should only be assigned as Tenant Administrator for a single tenant, their home tenant.
This means that despite the fact that a group has been assigned to a role, some of its members may not be eligible for assignment to that role because they are mapped into a different tenant. When a user who is a member of the group logs in, if they are not a member of the correct tenant, they will not be granted the role to which the group has been assigned.
For example, only users in the provider tenant can be assigned to VDC roles. So if a group that contains provider tenant and members of other tenants, only the provider tenants members will be granted the VDC role when they log in.
Similarly, a group can be assigned to a tenant role for a selected tenant, but only users who are eligible for the role will actually be granted that role when they log in. For example, to be granted the Tenant Administrator role, the user would have to be a member of the provider tenant or the tenant for which the group assignment was made. For other tenant roles, the user would have to belong to the tenant for which the assignment was madeBack to Top
Virtual data center-level roles
The actions authorized when you access ViPR from the UI can differ (be more constrained) from those available when you use the API/CLI.
The following table lists the authorized actions for each user role at the virtual data center level.
The following table lists the authorized actions for each user role at the tenant level.Back to Top
Each resource has a limit of 100 ACLs. In other words, projects have a maximum of 100 user/group assignments, and a virtual array or virtual pool has a maximum of 100 tenant assignments.
Virtual array and virtual pool ACLs
By default, virtual arrays and virtual pools are public. All tenants have access to them. A System Administrator or Security Administrator can assign an ACL to a virtual pool or virtual array to restrict them for use by only specified tenants. In this way, the System Administrator or Security Administrator can make certain virtual arrays or pools private (accessible to only specific tenants).
The ACL permission associated with virtual arrays and pools has a type of USE. If a specific tenant has a USE ACL on a virtual pool, users mapped to that tenant can use that virtual pool in their provisioning operations. The USE ACL permission is a parameter that displays in some API calls.
All newly created virtual arrays and pools have an empty ACL. It is the responsibility of the System Administrator or Security Administrator to manage the ACL. If no ACLs are set, the virtual arrays and pools remain accessible to the provider tenant and tenants in the ViPR system.
Service catalog ACLs
The service catalog is public by default. All users within a tenant can access the catalog unless access to the service categories or the services has been assigned using their ACLs. Access to the service catalog is assigned by the Tenant Administrator. The ACL permission associated with the service catalog is of type USE.
Unlike service catalog and virtual array and virtual pool ACLs, access to projects is normally prohibited and enabled by adding users or groups to the project ACL.
The ACL permission associated with projects have two types: ALL or BACKUP. There are also two internal ACLs of type ANY and OWN. The project ACLs are assigned to those self-service provisioning end users who are allowed access to a particular project
When a project is created, the Tenant Administrator or Project Administrator that creates the project is assigned as the owner of the project using the OWN ACL. The ACL for a project can be assigned by a Tenant Administrator (Tenant Administrators can access all projects for their tenant), the Project Administrator who created the project, or a user who has been assigned as the owner of the project.
The following table provides a description of the project ACL permissions:Back to Top