Skip to content
Back to glossary
Kubernetes Architecture

What is Multi-tenancy?

Multi-tenancy is the hosting of multiple customers or teams on a shared infrastructure with strict logical isolation. The economic model of SaaS and internal platforms.

What multi-tenancy does

Multi-tenancy is the architectural pattern where multiple customers, teams or business units (the "tenants") share the same infrastructure while remaining isolated from each other. It is the economic model of every modern SaaS: a single cluster, a single database, and each customer sees only their own data.

On Kubernetes, multi-tenancy allows you to share a cluster between several product teams or subsidiaries, with a considerable operational efficiency gain. Rather than provisioning 10 clusters for 10 teams (each with its monitoring, etcd, control plane), you operate a single cluster that hosts the 10 teams in parallel.

Isolation levels

Multi-tenancy comes in several levels depending on the security requirement:

Soft multi-tenancy. Logical isolation via Kubernetes namespaces + RBAC + ResourceQuotas. Each tenant has its namespace, its CPU/RAM limits, its limited rights. Suitable for trusted tenants (internal teams, subsidiaries). Not suitable for hosting hostile external customers.

Hard multi-tenancy. Strong isolation with strict NetworkPolicies (Cilium or Calico), sandboxed runtime (gVisor, Kata Containers), per-tenant dedicated nodes (taints/tolerations). Operational cost increases but isolation approaches VM-level.

Cluster-as-a-Service. Each tenant receives its own virtual (vCluster, Capsule) or physical Kubernetes cluster. Maximum isolation, maximum operational complexity. Suited to critical SaaS and sovereign cloud.

Specific constraints

Secret isolation. A secret in namespace A must never be readable from namespace B. Strict RBAC, audit verification, ideally External Secrets Operator to store secrets in Vault rather than in Kubernetes itself.

Network isolation. By default, all pods in a cluster can talk to each other. That is unacceptable in multi-tenant. Per-namespace deny-by-default NetworkPolicies, explicit authorisation of inter-service flows.

Quotas and limits. Without ResourceQuotas, a tenant that over-consumes blocks the others. Configure CPU/RAM/storage quotas per namespace, with Prometheus alerts when a tenant approaches 80% of its quotas.

Multi-tenant observability. Each tenant must see its own logs and metrics, never those of others. Loki and Mimir support native multi-tenancy with an X-Scope-OrgID header that filters queries per tenant.

Independent lifecycle. A tenant upgrading its application version must not affect others. CI/CD per tenant, no global deployment forcing everyone to migrate together.

Multi-tenancy and Swiss compliance

For workloads subject to nFADP or FINMA, soft multi-tenancy (shared namespaces) is often insufficient. Auditors require proof of physical data isolation between tenants. In practice, two approaches are accepted:

  1. Dedicated cluster per regulated client: isolation by construction, simple audit.
  2. Hard multi-tenancy with dedicated nodes: infrastructure savings, but heavier documentation and isolation testing.

On Hikube, financial and healthcare workloads are systematically deployed on a dedicated cluster to simplify audits.

When multi-tenancy is not the right fit

For mono-tenant applications (a single user entity) or very specialised workloads (HPC, GPU-intensive), multi-tenancy adds complexity without benefit. Prefer a dedicated cluster in that case, simpler to operate.

Related Hidora services

  • Hikube: Swiss sovereign multi-tenant Kubernetes platform with dedicated-cluster options for regulated workloads.
  • Managed Services: operation of multi-tenant platforms with audited isolation, per-tenant quotas and per-tenant observability.
  • Consulting: multi-tenant architecture design, isolation-level selection, per-tenant CI/CD pipeline rollout.
  • Kubernetes, Service Mesh, Platform Engineering: associated building blocks.