Configure Multi-Tenancy with Qumulo

REQUIREMENTS

Cluster running Qumulo Core version 3.1.0 or above

Note: A multi-tenant environment is not the same as multi-instance architecture, where the software instance operates on behalf of different tenants.

OVERVIEW

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 Segregation

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 8.8.8.8 --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

Share Permissions

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. For more information, see Qumulo Core's Encryption at Rest article.

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

Example:

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: You can enforce a similar restriction for NFS exports by using host access restrictions. For more information, see NFS Exports with Multiple IP Restrictions and User Mappings.

Authentication Segregation

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.

Considerations

Overlapping UIDs/GIDs for NFS

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) 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.

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.

Administrative Delegation

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 or admins require administrative control over certain functions of the system (for example, configuring replication relationships or network settings).