Understanding ViPR Users, Roles, and ACLs

Table of Contents

Back to Top

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.

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

Back to Top

Summary of ViPR roles

The administrator role to which a user is assigned determines which administration operations they can perform. In the Administration Mode of the UI, a user's role determines the areas of the UI and menu items that are visible to the user.

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.

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

The root user cannot perform the linking of VDCs. Linking VDCs requires and 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 Tenant Administrator is responsible for managing tenant resources and for creating new tenants. As ViPR only supports one level of tenants under the provider tenant, only the Tenant Administrator for the provider tenant can create new tenants (also referred to as sub-tenants). However, the Tenant Administrator for the sub-tenant can modify the mapping of users in the sub-tenant.

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.

Note Image

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

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

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: