ViPR 2.1 - Understanding ViPR Users, Roles, and ACLs

Table of Contents

Introduction

ViPR administration tasks are controlled by assigning users into roles. In addition, access to the ViPR service catalog and to certain ViPR resources can be controlled by assigning users to the appropriate Access Control List (ACL). This article describes the permissions associated with the ViPR roles and provides an overview of ACLs.

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 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

Summary of ViPR roles

Roles can be specific to a tenant or can apply to the virtual data center (VDC), and as such will affect all tenants in the 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.

Back to Top

User Roles in federated ViPR sites

When ViPR VDCs, also called sites, are linked, ViPR replicates the authentication providers so that each site has user accounts provided by AD/LDAP and users can log in to any linked site.

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

The root user cannot perform the linking of VDCs. Linking VDCs requires an AD/LDAP user with the Security Administrator role. In addition, there are specific restrictions on the root user (and other local users) when sites are federated:
  • 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.

Back to Top

Tenant Administrator role in the provider tenant and sub-tenants

The administration of a tenant is the responsibility of the Tenant Administrator.

The Tenant Administrator can:
  • 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 Tenant Administrator role can be assigned to a member of the sub-tenant, as follows:
  • 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 following notes apply to the Tenant Administrator role:
  • 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.
    Note Image

    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.

    Tenant selector for provider Tenant Administrator

  • 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.

    Note Image
    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.


Back to Top

Assignment of roles by group

VDC and tenant roles can be assigned to users and groups associated with an authentication provider that has been added to ViPR.

When using group assignment, you must remember that a group can be assigned to more than one tenant, and group members can be mapped into different tenants based on attributes. For example, the mappings for two tenants could both include users from the same group, in this case, group1:
Tenant 1
domain=emc.com, group=group1 and attr1=xyz
Tenant 2
domain=emc.com, group=group1 and attr1=abc
For this reason, when assigning roles to groups, ViPR does not validate group membership, but allows any valid AD group to be assigned to a role.

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 made

Back to Top

Authorized actions in ViPR roles

ViPR roles fall into two groups: roles that exist at the ViPR virtual data center level, and roles that exist at the tenant level.

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.

Tenant-level roles

The following table lists the authorized actions for each user role at the tenant level.

Back to Top

Access Control Lists (ACLs)

An Access Control List (ACL) is a list of permissions attached to a ViPR resource (such as a virtual array, virtual pool, service catalog, or project) that specifies which users have authorization to access a given resource and which operations are allowed on a given resource.

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.

Project ACLs

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