ViPR 2.1 - Understanding ViPR Multi-Tenant Configuration
Table of Contents
- 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
- 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.
- 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.
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 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 shows 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.Back to Top
- 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 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 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.
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.
- 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.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.
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 madeBack to Top
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
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
- 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.