À quoi sert le multi-tenancy

Le multi-tenancy (ou multi-locataires) est le pattern architectural où plusieurs clients, équipes ou unités métier (les « tenants ») partagent la même infrastructure tout en restant isolés les uns des autres. C'est le modèle économique de tous les SaaS modernes : un seul cluster, une seule base de données, et chaque client voit uniquement ses propres données.

Sur Kubernetes, le multi-tenancy permet de mutualiser un cluster entre plusieurs équipes produit ou plusieurs filiales, avec un gain d'efficacité opérationnelle considérable. Plutôt que de provisionner 10 clusters pour 10 équipes (chacun avec son monitoring, son etcd, ses control planes), on opère un cluster unique qui héberge les 10 équipes en parallèle.

Les niveaux d'isolation

Le multi-tenancy se décline en plusieurs niveaux selon l'exigence de sécurité :

Soft multi-tenancy. Isolation logique via namespaces Kubernetes + RBAC + ResourceQuotas. Chaque tenant a son namespace, ses limites CPU/RAM, ses droits limités. Convient pour des tenants de confiance (équipes internes, filiales). Pas adapté pour héberger des clients externes hostiles.

Hard multi-tenancy. Isolation forte avec NetworkPolicies strictes (Cilium ou Calico), runtime sandboxé (gVisor, Kata Containers), nodes dédiés par tenant (taints/tolerations). Le coût opérationnel augmente mais l'isolation se rapproche de la VM.

Cluster-as-a-Service. Chaque tenant reçoit son propre cluster Kubernetes virtuel (vCluster, Capsule) ou physique. Isolation maximale, complexité opérationnelle maximale. Adapté aux SaaS critiques et au cloud souverain.

Les contraintes spécifiques

Isolation des secrets. Un secret dans le namespace A ne doit jamais être lisible depuis le namespace B. RBAC strict, vérification d'audit, idéalement External Secrets Operator pour stocker les secrets dans Vault plutôt que dans Kubernetes lui-même.

Isolation réseau. Par défaut, tous les pods d'un cluster peuvent se parler. C'est inacceptable en multi-tenant. NetworkPolicies par namespace en mode deny-by-default, autorisation explicite des flux inter-services.

Quotas et limits. Sans ResourceQuotas, un tenant qui sur-consomme bloque les autres. Configurer des quotas CPU/RAM/storage par namespace, avec alertes Prometheus quand un tenant approche 80% de ses quotas.

Observabilité multi-tenant. Chaque tenant doit voir ses propres logs et métriques, jamais ceux des autres. Loki et Mimir supportent le multi-tenancy natif avec un header X-Scope-OrgID qui filtre les requêtes par tenant.

Cycle de vie indépendant. Un tenant qui upgrade sa version d'application ne doit pas impacter les autres. CI/CD par tenant, pas de déploiement global qui force tout le monde à migrer ensemble.

Multi-tenancy et conformité suisse

Pour les workloads soumis à la nLPD ou à la FINMA, le multi-tenancy soft (namespaces partagés) est souvent insuffisant. Les auditeurs exigent une preuve d'isolation physique des données entre tenants. En pratique, deux approches sont acceptées :

Cluster dédié par client régulé : isolation par construction, audit simple.
Hard multi-tenancy avec nodes dédiés : économie d'infrastructure, mais documentation et tests d'isolation plus lourds.

Sur Hikube, les workloads financiers et santé sont systématiquement déployés en cluster dédié pour simplifier les audits.

Quand le multi-tenancy n'est pas adapté

Pour des applications mono-tenant (une seule entité utilisatrice) ou des workloads très spécialisés (HPC, GPU intensifs), le multi-tenancy ajoute de la complexité sans bénéfice. Préférer dans ce cas un cluster dédié, plus simple à opérer.

Services Hidora associés

Hikube : plateforme Kubernetes multi-tenant souveraine suisse avec options de cluster dédié pour les workloads régulés.
Managed Services : exploitation de plateformes multi-tenant avec isolation auditée, quotas par tenant et observabilité par tenant.
Consulting : conception de l'architecture multi-tenant, choix du niveau d'isolation, mise en place du pipeline CI/CD par tenant.
Kubernetes, Service Mesh, Platform Engineering : briques associées.