Understanding ViPR Multi-Tenant Configuration

Table of Contents

Back to Top

Introduction

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.

This article applies to EMC ViPR 2.0.

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.

At the virtual data center level the tenant-specific configuration of the VDC provides the ability to:
  • Map users into the tenant based on their AD/LDAP domain, groups to which they are assigned, and attributes associated with their user account.
  • 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.
  • 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.

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

Assigning the Tenant Administrator role

The administration of ViPR requires users to be assigned to administration roles for the VDC and for the tenant.

You can refer to the article on Understanding Users, Roles, and ACLs for an overview of ViPR users and roles.

The administration of a tenant is the responsibility of the Tenant Administrator who can assign users to tenant roles, customize the service catalog, add hosts, clusters, and vCenters, create projects, create consistency groups, etc.

The following notes apply to the Tenant Administrator role.

  • The Tenant Administrator for the provider tenant can access the Admin > Tenants page and create new tenants. A single level of tenants below the provider tenant is allowed.
  • The Tenant Administrator that creates a sub-tenant is, by default, assigned to the Tenant Administrator role for the new tenant.
    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).

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

    Note Image
    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 always recommend that a Tenant Administrator who belongs to the sub-tenant is created for day-to-day management of a tenant.

  • A Tenant Administrator who is mapped into the tenant can access the Admin > Tenants menu and can modify the user mappings.
  • The Tenant Administrator role can be assigned to a member of the sub-tenant, as follows:
    • The Security Administrator for the virtual data center 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

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.

Because the tenant is replicated across sites, a logged in user moving between the linked sites has access to the same tenant resources: the service catalog, projects, consistency groups, etc. In addition, users assigned to tenant roles have those roles when logged in at any of the linked VDCs.

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:
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 and Security Administrator.

To create or edit a tenant from the UI, you must be a Tenant Administrator for the provider tenant and you must be a Security Administrator because the operations needs to obtain a list of domains.

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 corp.sean.com (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 corp.sean.com 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 show the use of multiple mapping criteria. All members of the corp.sean.com 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

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.