2021 Call for Code Awards: Live from New York, with SNL’s Colin Jost! Learn more

Introduction to multitenancy

A Red Hat OpenShift cluster is often used to host workloads from a single tenant (or, customer) who owns the cluster. However, multiple workloads from different tenants can also be run in the same cluster. In this case, you must isolate those workloads from one another so that the tenants cannot interfere with each other. This article explains how to isolate workloads in OpenShift so that they can be used by multiple tenants.

What is multitenancy?

Software multitenancy refers to a software architecture where a single software instance serves multiple users or groups, also called tenants.

Many times, an existing software solution is designed for a single tenant. In this case, you can achieve multitenancy by provisioning a separate instance of the software for every tenant while also isolating each tenant. Tenants refers to a single user, group of users, or an organization.

In multitenancy, every tenant needs to be isolated from and invisible to each other to protect the tenant’s data privacy and security.

Benefits of sharing workloads

In many companies, different departments (such as Human Resources and Finance) use their own set of workloads that run on shared software and hardware . For instance, a company might have multiple departments running their workloads on a WebSphere Application Server with a DB2 server.

A dedicated hardware and software setup for every workload would be expensive, hard to maintain, and impractical.

In a shared computing environment, multiple workloads share capacity. So, workloads are able to acquire capacity when needed and release it when the capacity is not needed. This is possible because in companies, the usage of every application varies during different times day, months, and years.

The key to this shared computing environment being valuable to all tenants is for the environment to support multitenancy. That is, the environment needs to keep the workloads related to compute, network, and other hardware resource for each tenant isolated from the other tenants’ workloads.

New virtualization and containerization techniques make it possible to provide complete isolation for the tenants on a shared hardware infrastructure. The software as a service (SaaS) model makes software available to a user without the user having to install or manage it themselves. A SaaS service can be used by multiple tenants, as long as the tenants are isolated from each other.

A multitenant SaaS service uses shared computing resources efficiently, enables multiple tenants to use the service while being isolated from each other, and makes the service consumer more productive because the service provider is responsible for managing the service and its computing environment.

Approaches to achieving multitenancy

There are a couple of approaches to achieving multitenancy using OpenShift:

  1. Multitenant service — In this ideal solution, a service is implemented such that a single instance can support multiple tenants.

If a service is not multitenant, then each tenant will need its own service instance. How can those instances be isolated from each other for multitenancy? There are a couple of options:

  1. Multiple clusters — The highest isolation between service instances is to deploy each in a separate cluster. Then each cluster can be installed on separate hardware, separate networks, even separate data centers or regions located thousand of miles apart. The downside to this is that having a separate cluster for each service instance would be expensive with extremely low utilization and create many clusters to manage.

  2. Single shared cluster — A more economical and practical approach is to deploy multiple service instances within the same cluster. Compared to multiple clusters, a single cluster is less expensive, easier to manage, and better utilized. However, the workloads in a cluster share the same resources and network, so their isolation is limited. The container isolation between workloads in a cluster is appropriate for a single tenant or multiple tenants who trust each other, but not sufficient for multiple tenants where one tenant should not even know the other tenants’ workloads exist.

So A cluster can handle multiple workloads. How can they be isolated?

Isolating workloads in OpenShift

To understand how isolation works in OpenShift, first let’s quickly review how OpenShift is set up. An OpenShift cluster is a collection of projects, which are based on Kubernetes namespaces. A project is like a virtual cluster, logically separating its resources from those in other projects, so that multiple projects work like multiple virtual clusters all within a single physical cluster.

Projects provide several advantages:

  1. Name scope — Each project has its own name scope, so two resources of the same kind can have the same unique name as long as they’re in separate projects.

  2. User community — The cluster users (such as application developers and deployers) who can access a project is controlled via cluster RBAC. This makes it easy for a cluster administrator to isolate different projects in the same cluster by putting the users for different teams in different projects.

  3. Resource quota — The cluster administrator can configure each project with resource limits. This way, a project cannot use too much of the cluster’s resources, so each project should get some resources.

  4. Configuration scope — Some cluster configuration can be specified on a per-project basis. Configuration that would normally be global to the cluster can be scoped to a project so that projects can be configured independently.

Projects group resources, but, by default, they do not isolate workloads. However, you can configure projects to isolate workloads. By creating a project per tenant and configuring each one for isolation, the workloads for a tenant in one project are isolated from those for a tenant in another project.

A cluster administrator configures project isolation in two main aspects:

  1. Network isolation

  2. Resource isolation

Let’s explore those aspects in a little more detail.

Network isolation

You configure an OpenShift project using Kubernetes network policies to prevent network connections between its pods and pods in other projects. Effectively, the pods in one project cannot see the pods in other projects on the network. It’s as if they don’t exist on the network. This ensures that network traffic is allowed between pods within the project but not between pods in different projects, thereby providing network isolation between projects.

Learn how to achieve network isolation by applying network policies on your project. Read the tutorial.

Resource isolation

In a multitenant environment, the resource usage of one tenant’s workloads should not impact the performance or resource availability for other tenants’ workloads. You can configure OpenShift project with resource quotas for compute resources such as CPU and memory. This ensures that the workloads in one tenant’s project cannot exceed its resource limits, thereby reserving resources for the workloads running in other tenants’ projects.

Learn how to configure project resource quotas for CPU and memory and achieve resource isolation between tenants. Read the tutorial .


In this article, you saw the need and benefits of multitenant deployment of applications. You can use OpenShift projects to separate tenants, and use network policies and resource quotas to achieve isolation for multitenancy, thereby achieving multitenancy in a container environment.