Understanding ViPR Controller Users, Roles, and ACLs

Table of Contents

ViPR Controller Users, Roles, and ACLs

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

ViPR Controller users must belong to an Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) domain that has been registered as a ViPR Controller authentication provider. Users who belong to a registered AD/LDAP domain can be given access to a ViPR Controller tenant using a set of rules, the simplest of which is that users who belong to a domain can authenticate with ViPR Controller.

For information to add authentication providers and the map of users, see the ViPR Controller User Interface Tenants, Projects, Security, Users and Multisite Configuration Guide, which is available from the ViPR Controller Product Documentation Index.

ViPR Controller has two types of users: end users and administrators. End users provision, create and manage file and block storage, mainly using the services in the service catalog.

End users in ViPR Controller 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 ViPR Controller UI and perform end-user operations. For end users, access to certain ViPR Controller functions is restricted using an access control list (ACL).

Back to Top

Summary of ViPR Controller 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 Controller virtual data center roles and can assign users into tenant roles. The Tenant Administrator can assign users to the tenant roles.

After ViPR Controller 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 Controller sites

When ViPR Controller 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

Provider tenant roles, and sub-tenants

The Provider tenant is the default tenant created by the ViPR Controller.

Upon initial login to ViPR Controller, the provider tenant is created. Any tenant created in ViPR Controller after the provider tenant is a sub-tenant for example:

Assigning Tenant Administrator to the provider tenant

Initially, the Security Administrator for the VDC is the only user that can configure the provider tenant. Configuring the provider tenant, includes assigning a Tenant Administrator to the provider tenant. Once a Tenant Administrator is assigned to the provider tenant, the Tenant Administrator for the provider tenant can do all of the tenant level operations including assigning tenant roles to the other provider tenant users and access the virtual data center resources configured for the provider tenant.

Back to Top

Security Administrator role

Only the Security Administrator can perform the following tenant functions in ViPR Controller.

  • See the tenants that exists in the VDC.
  • Create, modify, and delete existing tenants.
  • Assign the Tenant Quota.
  • Assign User Mapping Rules to the Tenant.
Back to Top

Tenant Administrator roles

The Tenant Administrator can perform the following operations for the tenants assigned to them:

  • View the tenants, and tenant attributes.
  • Assign roles to users in the tenant.
  • Modify the tenant name, and description.
  • Perform administration tasks for the tenant, such as creating a project, or editing the service catalog.

The Tenant Administrator role can be assigned to a member of the sub-tenant. The Security Administrator for the VDC and Tenant Administrator for the subtenant can assign a Tenant Administrator role to the other users mapped to the same subtenant or to the users mapped to the provider root tenant.

Back to Top

Assignment of roles by group

VDC and tenant roles can be assigned to the Users or Groups in the authentication provider or User Groups in the ViPR Controller.

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 Controller does not validate group membership, but allows for any valid AD, LDAP, or ViPR Controller User Groups 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 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 Controller roles

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

Virtual data center-level roles

The actions authorized when you access ViPR Controller 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 Controller 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 Controller 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