IN THIS ARTICLE
Outlines how to configure a multi-tenant environment via the network, filesystem, or authentication layers on a Qumulo cluster
- Cluster running Qumulo Core version 3.1.0 or above
NOTE: Keep in mind that a multi-tenant environment is not the same as a multi-instance architecture where the software instance operates on behalf of different tenants.
To guarantee security and meet compliance policy requirements, access segregation may need to be configured on different layers between different tenants. By implementing a multi-tenant environment, a group of users can share a common access with specific privileges on your cluster. With Qumulo, you can configure the networking, filesystem, and authentication layers to achieve the multi-tenancy needs of your workflow by providing a dedicated share of the instance.
Network traffic segregation for multiple tenants is not always required, but can be useful if you want to connect different tenant networks to the filesystem with restricted visibility that prevents network packets of the different tenants from being visible to one another.
For this purpose, Qumulo supports VLAN configuration to limit the broadcast domains of Layer 2 networks and offer additional security. Even though packets from different VLANs use the same media, Layer 3 packets from different VLANs cannot ‘see’ each other in the different customer networks that are segregated through VLANs in the Layer 2 storage network as illustrated below.
To create multiple networks for different tenants, specify the VLAN ID (and other cluster specific details) in the following qq command:
qq network_add_network --name CustomerB --ip-ranges 192.168.0.10-14 --floating-ip-ranges 192.168.0.15-25 --netmask 255.255.255.0 --dns-servers 220.127.116.11 --dns-search-domains customerb.com --mtu 1500 --vlan-id 200
You can configure up to 4096 VLANs in Qumulo Core, which provides you with more flexibility than the alternative of connecting different physical networks to your storage server. For more details on VLAN configuration, reference the Connect to Multiple Networks in Qumulo Core article.
Filesystem Access Segregation
When creating an SMB share, permissions can be assigned to users or groups via the Create SMB Share page in the Web UI or using the SMB qq commands featured in the SMB Share Permissions article. Note that if Access Based Enumeration is enabled for the SMB share, the share will not be available to users without permission access. Additionally, SMB shares and their traffic can be encrypted to add another level of security for network traffic.
NOTE: Software-based encryption at rest is available by default on new clusters created with Qumulo Core 3.1.5 and above. Check out the Qumulo Core's Encryption at Rest article to find out more.
SMB Host Restrictions
In addition to setting share permissions for users or groups, an SMB share can be restricted to a single host, multiple hosts, or a network range using the QQ CLI.
To create an SMB share with host restrictions, use the following qq command:
qq smb_add_share --fs-path PATH --name NAME --all-access --full-control-hosts RANGE --read-only-hosts RANGE
qq smb_add_share --fs-path / --name share --all-access --full-control-hosts 10.1.1.42 10.1.2.84-110 --read-only-hosts 10.100.0.0/16
NOTE: A similar restriction can be enforced for NFS exports using host access restrictions. For additional details, reference the SMB Host Restrictions article.
Users from different tenants typically authenticate through different Active Directories. Qumulo supports this workflow if there is a trusted relationship between the different ADs. If a tenant does not want to establish a full trust between their domain and the domain that Qumulo joined, a one-way trust is sufficient.
In the example above, the Qumulo system is joined to Active Directory (AD) X, which has a one-way trust to the Active Directories A, B, and C so that AD X trusts ADs A, B, and C but not vice versa. For example, AD A would not trust any authenticated user from AD X, B, or C so that Qumulo can securely authenticate users from different domains.
Overlapping UIDs/GIDs for NFSv3
- It is strongly recommended to store Unix POSIX attributes in Active Directory to have system-wide unique UIDs/GIS and a single source of truth. However, Unix attributes such as User IDs (UIDs) and Group IDs (GIDs) will likely overlap in different Active Directories. If multi-protocol access is needed, configure a separate LDAP Server to host Unix Users and Attributes and use User-Defined Identity Mappings. However, a better solution for this NFSv3 specific limitation is to use NFSv4, where a user is defined through a unique user@domain string rather than a UID.
Overlapping Share Names
- Share names must be unique across the system.
Overlapping IPv4 Ranges
- Tenants with overlapping private IPv4 address ranges are not currently supported. Use IPv6 address ranges, which do not overlap, or organize the IPv4 range in such a way that there is no overlap.
Multiple Default Gateways
- Qumulo supports only one default gateway. If you have multiple networks connecting to the storage network via different gateways, set static routes for those networks that cannot be routed through the default gateway until a separate gateway is supported for each configured network, combined with source-based routing.
- Qumulo supports a fine-grained Role Based Access Control (RBAC) model where administrative permissions can be assigned to AD users or groups. Before configuring RBAC, keep in mind that this workflow may not be ideal if tenant users/admins require administrative control over certain functions of the system (e.g., configuring replication relationships or network settings).
You should now be able to successfully configure a multi-tenant environment via the network, filesystem, or authentication layers on a Qumulo cluster
Like what you see? Share this article with your network!