Understanding ViPR Multi-Tenant Configuration
Table of Contents
This article applies to EMC ViPR 2.0.
- 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.
- 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.
- 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.
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 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.
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.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 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.
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.
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).
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.
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.
When any of the mapped users authenticate with ViPR they will have access to the tenant to which they have been assigned.
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.
- 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.