VAST Cluster allows for operation of multiple cluster tenants. VAST Cluster's multi-tenancy enables you to divide cluster storage resources into tenants with isolated data paths, serving different clients. Multi-tenancy can help you achieve security goals, and control allocation of performance and capacity for any reason.
VAST Cluster has a default tenant, with which resources are associated by default. The default tenant cannot be deleted. To make use of multi-tenancy, you create additional tenants.
Limitations
Audit records for all tenants are stored on the default tenant. However, each audit record contains information about the tenant to which it refers.
If the tenant is associated with an Active Directory provider, setting up a list of authorized client IPs to control access to this tenant requires that the Active Directory provider is configured as SMB allowed.
Providing Client Access to Tenants
To provide for client access to tenants, ensure that each tenant can be uniquely identified through either a dedicated virtual IP pool or a unique client IP range. If a tenant does not have a virtual IP pool assigned or a client IP range defined, the tenant cannot be accessed by clients.
Do either or both of the following:
Assign one or more virtual IP pools exclusively to a tenant. Verify that the pool(s) are not assigned to any other tenants.
Define a unique range of client IP addresses for each tenant. These client IP ranges must not overlap between tenants.
When a client requests access to a virtual IP:
If the virtual IP belongs to a virtual IP pool that is assigned to a tenant, the client source IP is checked against the client IP range(s) for that tenant (if defined). The request is only allowed if the client source IP is within the tenant's client IP range(s).
If the virtual IP does not belongs to a tenant-specific virtual IP pool, the client source IP is checked against client IP ranges of all tenants. The request is allowed and directed to the tenant whose client IP range includes the client source IP. If no match is found, the request is rejected.
Client access to a view is authorized only if both of the following conditions are met:
The view belongs to the tenant to which the client has access (through the tenant's virtual IP pool or client IP ranges), and
The client host has permission to access the view according to the host-based access rules defined in the view policy.
Data Path Separation
When you create a tenant, an Element Store path is created for that tenant. This data path is isolated from all other tenants. It is deleted when the tenant is deleted.
Every view must be associated with a tenant.
A view policy can be associated with a specific tenant or it can serve all tenants. If a view policy is dedicated to a specific virtual IP pool, it must be a virtual IP pool that serves the same tenant as the view policy.
Since tenants' data paths are isolated from each other, file and directories may have the same path on different tenants.
Users cannot access directories and files, buckets and objects from tenants other than the tenant associated with the view that they are accessing. Client listings of exports, shares or buckets via any protocol do not include any data from tenants other than the tenant used for the client session.
Authorization Providers
Authorization providers can be separate or shared by multiple tenants. For supported combinations of provider types per tenant, see Authorization Providers in VAST Cluster. Providers in use for each tenant must be specified in the tenant configuration. Providers cannot be deleted from the cluster while in use by any tenant.
All providers must be resolvable via the DNS server configured at cluster installation.
Each tenant that has multiple external providers has its own setting for the POSIX primary provider.
Assigning Tenants for Asynchronous Replication
Asynchronous replication source and target paths can be on any tenant on each cluster and are specified in the protected path configuration.
Auditing with Tenants
Audit logs are stored under the default tenant, with each record specifying which tenant each operation belongs to.