ViPR 2.2 - Understanding ViPR Multi-Tenant Configuration

Table of Contents


ViPR can be configured with multiple tenants, where each tenant has its own environment for creating and managing storage which cannot be accessed by users from other tenants. The default or root tenant is referred to as the provider tenant and a single level of tenants can be created beneath it. This article describes the ViPR tenant model and describes how ViPR can be configured to use multiple tenants.

The following tenant scenarios are supported:
Enterprise single tenant
An enterprise single tenant ViPR configuration provides the same storage provisioning and management environment to all of its users. All users belong to the provider tenant.
Enterprise multi-tenant
In an enterprise multi-tenant environment, an organization creates additional tenants for different departments.
Enterprise multi-tenant as Managed Service Provider
In a managed service provider scenario, a company (Acme, for example) outsources its storage and compute requirements to a managed service provider. The service provider company uses ViPR to create an environment in which Acme can create storage and attach it to hosts located in the data center of the service provider.
The service provider can offer this service to a number of companies, each one assigned to its own ViPR tenant.

If you want to go straight to information on adding a new tenant to an existing VIPR VDC you should refer to the following article: Add ViPR Tenant to Existing VDC.

Back to Top

Multiple tenant configuration overview

Each tenant is created and configured from resources available to the virtual data center in order to provide a custom environment that can be managed and further customized at the tenant level.

The creation and configuration of a multi-tenant environment requires ViPR administrators to perform the following:
  • Create new tenants. (Requires the Tenant Administrator role for the provider tenant)
  • Map users into the tenant based on their AD/LDAP domain, groups to which they are assigned, and attributes associated with their user account. (Requires the Tenant Administrator role for the tenant)
  • Assign users to roles within a tenant. (Requires the Security Administrator role for the VDC or the Tenant Administrator role for the tenant)
  • Restrict access to provisioning resources based on tenant. For example, certain virtual arrays and/or virtual pools might only be accessible to a specific tenant. (Requires the System Administrator role)
  • Assign a Data Services namespace so that access to object buckets and the objects within the buckets can only be assigned to members of the tenant. (Requires the System Administrator role)

Where a single tenant (the provider tenant) exists, all tenant users have the same access to the ViPR virtual data center storage provisioning environment and to the ViPR Data Services. By default, all users associated with an authentication provider are mapped to the tenant. However, additional mappings can apply finer grained control to the selection of users.

Once the tenant is configured, the tenant environment can be managed by a Tenant Administrator. Each tenant environment provides the ability to:
  • Manage its own version of the service catalog and restrict access for tenant members to specific services and service categories.
  • Add hosts, clusters, and vCenters for which only tenant members can provision and managed storage.
  • Assign resources to projects and control access to the projects.
  • Create consistency groups.
  • Create execution windows.
Back to Top

Understanding the mapping of users into tenants

Users are added to ViPR using authentication providers. When an authentication provider is created in ViPR, one or more AD/LDAP domains are supplied and are used to provide ViPR users. A domain can be mapped to a single tenant or can provide users for multiple tenants.

An authentication provider usually specifies a whitelist group which defines the default group of users who will be available as ViPR users to the whole VDC. In addition to the whitelisted group, the available domain users can be mapped based on their group membership or based on attributes defined in their AD/LDAP entry.

By default, the provider tenant assumes that you want all users made available by the authentication provider. If that is not true you can use mappings. Sub-tenants below the provider tenant must specify user mapping; at a minimum, a domain must be specified.

The API and CLI provide the ability to specify mappings when a new tenant is registered and provide support for updating the mappings for all tenants, including the provider tenant. Creating and editing a tenant are functions of a Tenant Administrator. From the ViPR UI, the user mappings for a tenant are specified when you create or edit a tenant.

To create a subtenant, you must be Tenant Administrator in the provider tenant. To modify the mapping of the provider tenant, you must be Tenant Administrator in the provider tenant. To modify mappings in a subtenant, you must be Tenant Administrator in that sub-tenant.

The page below shows the Provider Tenant and an additional tenant called "Accounts". The Provider Tenant has not been explicitly mapped (there is no value in the Mapped Domains field), so it will take on any users from the configured authentication providers on the system that are not mapped to (the domain to which the Accounts tenant is mapped).

Tenants table

The user mappings must not overlap, so if the Accounts tenant maps users from the same domain as the provider tenant, it must provide additional mappings to differentiate its users. In the example below, the Accounts tenant uses the domain but maps users with specific attributes, in this case, those with their Department attribute set to Accounts in Active Directory.

User mappings for a tenant using AD attributes

The example below shows the use of multiple mapping criteria. All members of the domain who belong to the Storage Admins group and have their Department attribute set to Accounts AND Company set to EMC, OR belong to the Storage Admins group and have their Department set to EMCAccounts, will be mapped into the tenant.

Using multiple mapping criteria

When any of the mapped users authenticate with ViPR they will have access to the tenant to which they have been assigned.

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, group=group1 and attr1=xyz
Tenant 2, 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

Multi-tenant operation across multiple ViPR sites

If ViPR sites are linked, a tenant created in one ViPR site will automatically be available in other linked ViPR sites.

Tenants, tenant roles, and projects are shared across sites, so a user who is assigned to a tenant role will be granted that role at whichever linked site they log in at and can see the same projects. Services and the service catalog are not replicated and are specific to a VDC.

Virtual arrays and the block volumes and file systems created as a result of performing provisioning operations are VDC resources and so are not visible across sites.

Object data can be geo-replicated by using global virtual pools. When replication is enabled, users assigned to a tenant will be able to access buckets created in virtual pools located at any site.

More information on configuring multiple linked sites is provided in the following article: Plan and Deploy Multisite ViPR.

Back to Top

Set up the VDC for a tenant

You can add access control to virtual arrays and virtual pools to make them available to specific tenants.

A virtual array comprises array endpoints and host endpoints interconnected by a SAN fabric or an IP network. The virtual array can comprise both fibre channel and IP networks. In this way different array ports can be configured into different virtual arrays, allowing a physical array to contribute to more than one virtual array.

This partitioning of physical arrays into virtual arrays, coupled with the ability to assign access to specific tenants, provides control over the storage provisioning environment made available to a tenant.

Even finer grained control can be obtained by assigning specific virtual pools to tenants. For storage provisioning purposes, the physical storage pools of a virtual array are offered as virtual pools based on their performance and protection characteristics. Restricting access to a virtual pool to specific tenants could mean that if a virtual pool is configured to use a particular array type, restricting access to the virtual pool can prevent a particular tenants from accessing the array. Similarly, you could restrict access to a pool that provides a particular performance characteristic, such as SSD.

Back to Top

Set up the tenant for end users

Once a tenant has been created and configured, there are a number of Tenant Administrator tasks that can be performed. The tasks can be performed by the Tenant Administrator for the tenant.

The following administration tasks can be performed in preparation for using the tenant for block and file provisioning operations or for using ViPR Data Services.
  • Projects can be created and tenant users given access to the project.
  • The service catalog can be configured by arranging services in categories. Tenant users can be assigned access to the allow categories or individual services.
  • Hosts, clusters, and vCenters for the tenant can be added.
  • Consistency groups can be created.
  • Execution windows can be created.
Back to Top