Multi-tenant design practices for cloud-based solutions

Tenant models determine the level of isolation required across resources that pertain to data, storage, network, and processing. This will ensure that each tenant’s data and processes are secure and cannot be accessed by other tenants. Therefore, it is important to choose the right tenant model based on specific non-functional requirements for security, scalability, and cost-effectiveness.

Different tenant models have their own advantages and disadvantages; the choice of which will depend on factors such as the number of tenants, the complexity of the application, and the level of data isolation required. Two opposite examples of tenant models are (a) fully shared Instance where multiple tenants share the same application (and other resource) instances, but each tenant has their own virtual environment within that instance, and (b) fully isolated Instance where each tenant has their own dedicated instances for application, database, and infrastructure.

Organizations can determine a possible design based on the level of isolation, customization, scalability, complexity and total cost, and often settle on a design solution that lies somewhere in between the two tenant models after performing suitable trade-off analysis between various non-functional requirements.

Design practices

Designing multi-tenant systems for the cloud requires careful planning and consideration of various cloud concepts and resourcing requirements.

Resource organization

Cloud platforms arrange their instantiated resources and services based on some organizational structuring or hierarchical arrangement. When planning out a multi-tenant solution, it is advantageous to define the tenants, divisions and organizations that will be using the system, including eliciting their various functional and non-functional needs. Further, it would also be prudent to identify the different groups of users that will be accessing these cloud resources and defining their access needs. By undergoing this exercise, a conceptual and logical grouping of resources and services would emerge that could be used to drive the resource organization design. Once such an understanding has been established, resource groups, namespaces or other grouping mechanisms native to each cloud platform can collectively identify resources that belong to a specific tenant. This can simplify the management of resources and provide better visibility and control over tenant-specific resources. Finally, configuration settings can customize the behavior of the application or service for each tenant, such as settings related to branding, access control, and other tenant-specific requirements.

Identity and access management

IAM (Identity and Access Management) refers to the ability for cloud platforms to provide authorization and authentication controls for users and services who require access to various cloud services. Multi-tenancy in IAM refers to the ability to manage access to resources for multiple organizations or tenants within a single IAM system. Setting up multi-tenancy in IAM requires a multi-pronged approach that leads from the previous organizational and resource design step. A robust authentication and authorization mechanism ensures that only authorized users can access the application and data with role-based access control (RBAC) mechanisms can then be used to grant permissions to resources based on the roles and responsibilities of the tenant, thus ensuring that each tenant has access only to the resources they need and prevents unauthorized access to other tenants’ resources. RBAC can enforce strict access controls and prevent unauthorized access to sensitive data. IAM policies for the tenants are defined based on the determined IAM architecture; these policies articulate the access rights and permissions for each tenant’s users. Based on these policy definitions, the IAM services are then configured to enforce the policies and confirm that each tenant’s users are only able to access the resources they are authorized to access.

Network

Ensuring tenant isolation at a network level is critical to prevent unauthorized access to tenant data and ensure the security of the multi-tenant system. Several network mechanisms can be used to attain this objective. Virtual Networks (VNets) and Virtual Private Clouds (VPCs) provide logical isolation between tenants by creating a virtual network for each tenant, with each VPC isolated from other VPCs while being configured with its own security rules and access controls. Additionally, network segmentation techniques, such as subnets and VLANs, further isolate tenant traffic within VPCs and prevent lateral movement of traffic between tenants. Private IP addressing within the VPCs results in tenant traffic staying within the VPC and does not traverse the public internet.

Outside of VPC design, VPN connections enable secure connectivity between the VPCs and tenant networks, and ensure that tenant traffic remains secure and isolated from other traffic on the public internet. Firewall rules control access to and from each VPC and should be configured to allow only authorized traffic and block all other traffic. Finally, Network Access Control (NAC) rules support the access of only authorized and trusted devices and users to the network through defined network security policies.

Application

There are several ways to support compute resource isolation, based on the tenant model and design that has been determined. Containerization technology is an excellent approach to have each tenant’s processes run in a separate compute resource (or containers). Containers provide lightweight, isolated execution environments that can be easily deployed and managed and be provisioned for a specific tenant based on assignment of tenant identifiers. Containers provide a middle-of-the-road approach to compute tenant isolation. If complete tenant isolation is required, then dedicated compute resources (like Virtual Machines) could be provisioned that just serve a single tenant. For shared instance, a single running application could serve multiple tenants by serving all incoming user and system requests by mandating a tenant identifier be part of those calls. This way, the application is aware of which tenant is being handled, and executes tenant specific logic while updating tenant-specific data locations.

In addition to application design practices, there are implementation specific considerations as well. Resource quota implementation confines tenant’s compute resources (such as CPU and memory) to a prescribed amount and prevents one tenant from consuming all available resources and impacting the performance of other tenants. Furthermore, usage of sandboxing techniques isolates each tenant’s processes from other processes running on the same system and prevents processes from unauthorized access of sensitive data or resources.

Database

Ensuring datastore isolation for tenants is essential to prevent unauthorized access to tenant data and support the security and integrity of the multi-tenant system. The tenant design model provides guidance on the approach that can be taken when setting up the database. In the shared database approach, multiple tenants share the same database schema but each tenant has their own data within that schema. This model provides sufficient data isolation between tenants with the isolation often being established by having separate tenant-specific tables or using row-level security based on tenant identifiers. In the shared schema approach, multiple tenants share the same database schema and data, but each tenant’s data is logically separated using a tenant identifier; this model provides good data isolation but can be more complex to implement. Finally, the separate database (for each tenant) approach results in each tenant having complete isolation of data for the highest level of data privacy and security. Both the shared database and shared schema approaches are more cost efficient than the separate database approach, but their implementation is more complex and requires more diligent testing and validation.

Data processing and storage

Most cloud-native solutions have data ingestion, data transformation and data storage services employed to bring data from external systems for consumption within the cloud environment. There has to be tenant-based isolation during the ingestion and transformation pipelines, including where the tenant is stored in data storage services. Separation of the data ingestion and transformation pipeline can be attained through parameterization and configuration approaches, where each ingestion job is passed a configuration that provides tenant-specific source, destination and other needed information. On the data storage side, separate storage buckets can be used for complete isolation of tenant data, thus providing the highest level of data privacy and security. As before, tradeoffs need to be made on the complexity and cost of solutioning, versus the need to complete tenant isolation and access control. 

Irrespective of the approach adopted, security and protection of tenant data can be further supported by implementing encryption, with each cloud platform providing various mechanisms for granular data encryption. Encrypting data-at-rest and data-in-transit ensures that tenant data is protected from unauthorized access. Furthermore, encryption can prevent data breaches and avoid the compromising of sensitive and confidential data.

Conclusions

Overall, multi-tenancy is an important feature of cloud-native applications that enables efficient and secure sharing of resources among multiple tenants, while still maintaining the privacy and security of each tenant’s data and processes. Multi-tenancy enables service providers to offer a single application to multiple customers, reducing the operational costs of managing and maintaining multiple instances of the same application. It also allows customers to scale their usage of the application based on their needs, without requiring significant investment in infrastructure or personnel. The design guidelines provided in this article are not meant to be exhaustive but rather, meant to promote and initiate a discussion on the possible design options to consider based on the tenant need and determined tenant model.

For more information on Multi-tenant design practices for cloud-based solutions and how we can help, contact us.