The SaaS architecture checklist is a series of articles that cover the software and deployment considerations for Software as a Service (SaaS) applications. This article discusses architectural approaches for separating and isolating SaaS tenants to provide multi-tenancy, the provisioning of services to multiple clients in different organizations. For the approaches, the type and level of isolation provided are compared, along with their tradeoffs.
The approaches laid out in different sections of the article are not mutually exclusive and can be combined to provide the levels of separation and isolation necessary to satisfy the requirements of your SaaS customers and markets. We'll also discuss how to incorporate existing single-tenant applications into a SaaS environment.
The resources that are shared across multiple tenants vary, based on the architecture of the SaaS application. The level of sharing can be very high in large business-to-consumer (B2C) SaaS applications. In these cases, a given application instance potentially handles requests from thousands of unrelated tenants. For a more sensitive business-to-business (B2B) application, each tenant might get a dedicated application instance, though it could still be running on shared infrastructure.
Perhaps the most important aspect of a SaaS service is making sure tenants feel they have privacy and that no other tenant can see their data or activities. Additionally, tenant data must be stored securely and reliably. The integrity of each tenant's data must be protected from accidental loss, modification, or tampering.
When architecting a SaaS application, consider the level of isolation and controls required for the service you plan to offer. The requirements vary depending on the nature of the application, the sensitivity of the data, and the type of market. The contract or terms of service for the application usually detail what the provider is promising. However, regulatory or government agencies might issue compliance requirements for specific industries, such as financial services or health care, that you must adhere to when providing a SaaS application to customers under their jurisdiction.
It is worth considering that a one-size-fits-all approach might not be enough to balance the security requirements and costs for all prospective customers. Customers from highly regulated industries or groups might not be the target for your SaaS application. However, if you do attract customers from financial services, health care, or government organizations, you might have to adhere to requirements you didn't originally anticipate.
Also, some customers are under data sovereignty regulations that specify where the physical machines storing data must reside. These requirements potentially dictate data center locations and even which cloud providers can be used to host the SaaS services the customers consume.
When you think of SaaS applications, the ones that come to mind are probably those from large technology companies that are offered to millions of consumers. These applications are built from the ground up for multi-tenancy. They are designed for high-density deployments where large numbers of users can be served using minimal per-user resources. To achieve the necessary efficiency, a very high degree of sharing is usually necessary.
In an application design where each software instance handles requests from multiple tenants, the infrastructure generally can't provide the needed isolation. Instead, application logic is typically used to implement the controls that isolate tenants in application-level tenancy.
In this model, a single instance of the application serves requests from multiple tenants. The code is responsible for keeping each tenant's data separate and making sure other tenants can't see any data or activity that does not belong to them.
The controls in application-level tenancy must be implemented by software developers. Therefore, extensive automated testing and strict adherence to secure coding best practices are critical for application tenancy, as any bugs in the application could accidentally disclose tenant data or compromise data integrity. If a vulnerability in the application is found and exploited, relying solely on application logic to implement isolation could make it difficult to contain and mitigate the potential impact to tenants that share the same instances.
Application tenancy is best for applications that are designed for multi-tenancy as they are developed. Retrofitting an existing application to support multiple tenants can require extensive software development work as well as extensive testing. The costs and time necessary to modify an existing application could be high. For those applications, it might be better to consider the next two approaches we'll discuss in this article, where infrastructure-level controls provide the necessary separation and isolation.
Implementing multi-tenancy in the code of your application itself is appealing for a number of reasons:
However, there are also reasons you might want to avoid this architecture:
An alternative to the application-level tenancy described in the previous section is to use the capabilities available in Kubernetes to isolate applications that share a cluster. Using these controls, it is possible to run multiple instances of the same unmodified single-tenant application on the same cluster while keeping them logically separated. Namespace-level tenancy can allow existing applications that were not written for SaaS to be deployed as a SaaS solution.
Namespaces within Kubernetes provide a mechanism for isolating resources into different groups that keep user communities or application groups separate even while they share a cluster. For multi-tenancy, namespaces provide isolation between tenant workloads. Because Kubernetes enforces separation of namespaces, an application running inside of a namespace can't accidentally or intentionally access data or processes in a different namespace.
Kubernetes namespaces provide ways to use a single-tenant application in a multi-tenant SaaS deployment. The most common and perhaps most straightforward approach is to create a namespace for each tenant, and deploy the complete application stack and data store into each tenant's namespace. The namespace provides isolation between each application instance. This approach is referred to as namespace-level tenancy, and is illustrated in Figure 1.
Figure 1: Two tenants are shown with namespace-level tenancy, storing each application's resources including data in its own namespace.
To provide higher degrees of isolation and better control over resources, cluster administrators can control which worker nodes are available for each tenant's pods. Specific tenants can be configured to use only dedicated worker nodes, which could run on dedicated hardware if desired.
With namespace-level tenancy, a single control plane manages all the application instances and worker nodes used by all tenants of the cluster. The cluster's control plane contains configuration information for all tenant application instances running on that cluster. Anyone with cluster administration access can view and change configuration information for all tenants of the cluster.
This architecture is appealing for a number of reasons:
However, there are reasons why you might decide not to use this architecture:
Red Hat OpenShift has a number of features that improve security and isolation beyond what is available in upstream Kubernetes. These controls provide additional protection for namespace-level tenancy:
A future article will go into more detail on the security considerations for SaaS applications. For more information, please see:
To provide a very high level of isolation, a tenant can be assigned to a dedicated Kubernetes or Red Hat OpenShift cluster. In this case, no resources are shared between tenants—not even the cluster's control plane.
There are a number of cases where single-tenant clusters can be a good fit:
Figure 2 shows an overview of cluster-level tenancy.
Figure 2: Two separate clusters, each containing not only its own application resources but infrastructure elements such as control planes.
Single-tenant clusters provide a very high level of protection to mitigate the impact of security breaches. As discussed earlier, namespace-level tenancy limits any vulnerability within the application or application's components to the tenant using that namespace. However, parts of the technology stack are still shared when multiple tenants use the same worker node and control plane. A vulnerability in these shared parts of the stack could disclose or compromise the integrity of other tenant data. The shared components include:
The good news that is vulnerabilities in these lower levels of the technology stack occur far less frequently than application-level vulnerabilities. The best practice to guard against security vulnerabilities is to use a defense-in-depth strategy, where an attack would have to breach multiple layers of protection.
Single-tenant clusters are a very strong line of defense for situations that require this level of guaranteed security. A future article in this SaaS architecture checklist series will cover a number of the tools that can be used as part of a defense-in-depth security framework.
This architecture is appealing for the following reasons:
You might decide not to use this architecture for the following reasons:
There are a number of options to make the deployment and management of multiple Kubernetes or Red Hat OpenShift clusters faster and easier.
Red Hat Advanced Cluster Management for Kubernetes allows you to manage multiple Kubernetes or Red Hat OpenShift clusters from a single management interface. You can use Red Hat Advanced Cluster Management for Kubernetes's unified multi-cluster lifecycle management to create, update, upgrade, and decommission clusters as needed for your SaaS deployments. Some of the managed services for Red Hat OpenShift on public clouds can manage multiple clusters.
A feature planned for a future release of Red Hat Advanced Cluster Management for Kubernetes is hosted control planes. This feature allows the control plane for new clusters to be run on the worker nodes of an existing management cluster, which reduces the infrastructure and deployment time required. The upstream project for hosting OpenShift clusters at scale is called HyperShift. A future article will discuss multi-cluster management.
This article discussed three approaches to providing multi-tenancy for SaaS applications:
The first approach requires the application to be written for multi-tenancy. The latter two approaches can be used to deploy existing single-tenant applications as SaaS applications. Table 1 compares the three approaches.
| Application-level tenancy | Namespace-level tenancy | Cluster-level tenancy | |
|---|---|---|---|
| Tenant isolation enforced by | Application logic | Separate namespaces | Separate clusters |
| Level of infrastructure shared across tenants | High-all | Medium-mixed | Low-none |
| Tenant density possible | High | Medium | Low |
| Infrastructure costs per tenant | Low | Medium | High |
| Security protections | Low | Medium | High |
| Ability to monitor and scale per tenant | Low | Medium | High |
| Ability to customize deployment for each tenant | Low | Medium | High |
These three approaches are not mutually exclusive and can be combined to provide the best fit for your application, or to address the requirements of specific tenants. For example, an application that implements multi-tenancy could be deployed as multiple instances with either namespace-level or cluster-level tenancy to provide enhanced security protections and to contain the potential impact of vulnerabilities to a limited number of tenants.
A SaaS provider could offer multiple levels of service to address the requirements of tenants that are more risk-averse and are willing to pay for higher levels of service, versus those that are more cost-conscious and less sensitive to risk. Cost-conscious tenants can be served by environments with high degrees of sharing. The most risk-sensitive tenants could be offered the option of dedicated hardware to meet their requirements.
Future articles in this series will cover topics such as security and the options available for a defense-in-depth strategy. Another article will address single-tenant workloads that are difficult to containerize and will explain how these can be deployed for SaaS use as virtual machines using Red Hat OpenShift Virtualization with namespace-level isolation.
Red Hat SaaS Foundations is a partner program designed for building enterprise-grade SaaS solutions on Red Hat OpenShift or Red Hat Enterprise Linux platforms, and deploying them across multiple cloud and non-cloud footprints. Email us to learn more.
