Understanding ViPR Users, Roles, and ACLs
Table of Contents
This article applies to EMC ViPR 2.0.
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. To learn more about the addition of authentication providers and the mapping of users, see Add an Authentication Provider to ViPR and Map Users into a ViPR Tenant.
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 create and access ViPR object storage.
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 perform end-user operations and access the User mode at the UI. For end-users, access to certain ViPR functions is restricted using an access control list (ACL).
Roles can be specific to a tenant or can apply to all tenants within a virtual data center (VDC). 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.
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 are global resources, so tenant roles are available at any VDC and have the same meaning at all linked sites. A user assigned as the Tenant Administrator for a tenant has that role at whichever site he or she logs in at and tenant resources that the Tenant Administrator creates, such as projects, service catalog categories or services, consistency groups etc, are available at all sites.
End users are mapped into tenants, so an end user will be able to see the tenant resources at whichever site they log in at. However, the virtual infrastructure that they use 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 they are 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.
When a Tenant Administrator creates a sub-tenant, they are assigned, by default, as the Tenant Administrator for the new tenant. Hence, the Tenant Administrator for the provider tenant can be the administrator for a sub-tenant even through 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 capability only applies to sub-tenants for which they are assigned the Tenant Administrator role (usually due to creating the tenant).
- the service catalog for the provider tenant only
- the projects that they belong to in 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 recommended that a Tenant Administrator who belongs to the sub-tenant is assigned to each sub-tenant. This means that when the user in that role logs in, the Admin and User environments in which they are working apply to the sub-tenant.
- 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 the Tenant Administrator for the provider tenant.
- Any user who is a Tenant Administrator for the sub-tenant can assign the Tenant Administrator role to a user of the sub-tenant.
This user could be a Tenant Administrator for the provider Tenant who is also a Tenant Administrator for the sub-tenant.
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.
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: