Overview

This is the first of a two part series of articles that will talk a little about multi-tenancy in for Hyper-V in a Hosted Private Cloud deployment. Not all Private Clouds need this level of separation, but for the cases where it’s a requirement, this series aims to help.

In the context of Hyper-V, I/O Multi-tenancy is where we serve storage for VMs over SMB 3 to two or more clients (tenants) where they are not aware that the storage is shared with others. Essentially there needs to be some degree of security and privacy between tenants — especially when it comes to traversing the data network.

This first article will deal with SMB shares for user-based access control as separation, and we’ll extend upon that in the second article, which will discuss VLANs and how they impact Kerberos authentication.

In the case of VM-aware storage, once inside the storage array, each tenant’s I/Os are kept separate from each other through either implicit or explicit VM-level QoS. That might be a topic for another day.

6343998733_c19420febc_b

[Public Domain image taken by Bart Lumber]

An Example

To keep this topical, let’s say that we’re a hosting service for US Presidential Candidates and their campaign folks. Using standard fictional security characters, we’ll call these two candidates Alice and Bob.

Each has access to a Hyper-V compute platform and manages their own VMs, which are stored on their Tintri VMstore. Both groups need the ability to manage and maintain their own virtual machines and applications, but neither group should be able to see each other’s, which might contain sensitive emails or tax returns. Bob should see Bob’s stuff and Alice should see Alice’s. Neither should see anything else.

Separate Shares

By creating an SMB share (or more) each, we can grant access to only the parties that need it. Probably the easiest way to do this is with the (free) Tintri PowerShell Toolkit.

Consider the following illustrative example of creating a share each that is accessible by the right compute nodes for both Alice and Bob. The VMstore in this case being vmstore01.vmlevel.com.

PS:\> Connect-TintriServer vmstore01.vmlevel.com
PS:\> New-TintriSmbShare -Name AliceVMs
PS:\> Grant-TintriSmbShareAccess -Name AliceVMs -User alice-hv01$ -Access FullControl
PS:\> Grant-TintriSmbShareAccess -Name AliceVMs -User alice-hv02$ -Access FullControl

PS:\> New-TintriSmbShare -Name BobVMs
PS:\> Grant-TintriSmbShareAccess -Name BobVMs -User bob-hv01$ -Access FullControl
PS:\> Grant-TintriSmbShareAccess -Name BobVMs -User bob-hv02$ -Access FullControl

Above, we create a connection to the VMstore, we create a new SMB share for each tenant (Alice and Bob) and grant each tenant’s compute nodes access to the correct share.

VM Administrators

In single-tenant deployments, in addition to granting hosts/clusters of compute nodes access to the storage, it’s necessary to grant your VM Administrators access to the VMstore to manage storage and create VMs. This is most-simply done by assigning their Active Directory group(s) the Tintri Super Admins RBAC role, which allows them the administrative access that they need.

It might seem like a straightforward case of simply assigning both Bob and Alice’s VM admins the same role. However, that would grant both parties access to management functionality over the VMstore, and would grant each other access to the other’s VM data — the very thing we’re trying to avoid.

Instead, we just grant both parties explicit access to their own share using the same PowerShell cmdlets above, but naming Active Directory groups containing Alice and Bob’s VM administrators:

PS:\> Grant-TintriSmbShareAccess -Name BobVMs -User "Bob Admins" -Access FullControl
PS:\> Grant-TintriSmbShareAccess -Name AliceVMs -User "Alice Admins" -Access FullControl

And there you have it. Bob’s team can now create VMs against the share \\vmstore01-data.vmlevel.com\BobVMs and Alice’s team can do the same from their compute nodes against \\vmstore01-data.vmlevel.com\AliceVMs. Neither can  see each other and our own admins can manage both should the need arise.

Summary

It’s possible with SMB 3 shares and access control lists to implement the foundation for a multi-tenant environment. In the next article, we’ll expand on this to include network-level multi-tenancy without breaking Kerberos.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s