Last week, we looked at the use of user-based access controls to keep storage tenants on separate SMB shares for Hyper-V hosted private clouds. This week, we’ll expand on that through separation using VLANs.
VLANs themselves are pretty straightforward as a way to partition a physical network into multiple virtual, isolated networks. Where this can get a little murky, is when we put Kerberos and SMB into the mix. That’s the area that we’ll aim to clear up here this week.
Networks, Subnetworks and Names
We can create separation by creating a distinct VLAN for each tenant’s compute. Alice might be on VLAN 11 and Bob might be on VLAN 12. The Tintri VMstore serving I/O for these tenants would have its data interface on each tenant’s VLAN.
Each of these VLANs would be assigned a different subnet and the VMstore would have an IP address on each VLAN. Each tenant can communicate with the VMstore’s data interface, but can’t communicate with each others’. Easy.
So what’s the problem?
As we saw in Kerberos Fundamentals a few weeks ago, we have a DNS name that maps to a data IP address on the VMstore and has an associated Service Principal Name (SPN) in Active Directory. It might be tempting to have that DNS record resolve to all of the data IPs assigned to the VMstore (for each VLAN), but that won’t work in a lot of cases. Most DNS servers by default will return those IP addresses in a round-robin rotation. Using our Alice and Bob example, Bob’s compute trying to resolve the DNS name of the Tintri VMstore would have a high likelihood of getting an IP address on Alice’s VLAN/subnet, which is not reachable by Bob.
Split-DNS or a DNS server that responds differently to queries based on source IP address (such as views in ISC bind) are valid ways to get past this, but can be more unwieldy to manage and troubleshoot.
By creating a DNS record for each tenant data IP address and an associated SPN, we have a solution to the problem where all components (DNS records and SPNs) are kept with each other. The following table shows an example:
|Data path DNS name||IP address and netmask||VMstore SPN|
You’ll notice that when deploying the VMstore, we assign the SMB data path hostname in the UI so that the VMstore knows the name used by default for its SPN. It is not necessary to tell the Tintri VMstore about the subsequent SPNs or data path names for Alice and Bob above.
So as you can see, it isn’t necessarily obvious, but it isn’t very difficult to use SMB and Kerberos in a multi-tenant environment where VLAN and subnet separation has been employed.