Kubernetes Multi-tenant : Stratégies d'Isolation

Partager un seul cluster Kubernetes entre plusieurs équipes (multi-tenancy) est un excellent moyen de réduire les coûts et la charge de gestion. Cependant, cela nécessite une isolation stricte pour éviter les effets de "voisin bruyant" et les failles de sécurité.

Multi-tenancy "Soft" vs "Hard"

• Soft Multi-tenancy : Utilisateurs de confiance au sein de la même organisation. L'isolation se fait via les Namespaces et le RBAC.
• Hard Multi-tenancy : Lorsque les utilisateurs ne sont pas de confiance (ex: SaaS). Nécessite une isolation plus forte comme des clusters séparés ou des couches de virtualisation.

La Boîte à Outils d'Isolation

1. Namespaces : La frontière logique principale.
2. Resource Quotas : Empêchent une équipe de consommer tout le CPU ou toute la mémoire.
3. Network Policies : Restreignent le trafic entre les namespaces (Refus par défaut).
4. Virtual Clusters (vcluster) : Créent des "clusters dans le cluster" pour une meilleure isolation du control plane.

Une baseline pragmatique en contexte enterprise

Dans le cas le plus courant (soft multi-tenancy sur une plateforme interne), une configuration par défaut robuste inclut généralement :

• RBAC + moindre privilège avec ownership clair par namespace.
• Pod Security Admission (ou équivalent) pour imposer des defaults sûrs côté conteneurs.
• NetworkPolicies “deny-all” + règles d’egress explicites.
• Quotas + LimitRanges pour borner la consommation et limiter l’effet “voisin bruyant”.
• Node pools séparés pour les workloads sensibles (taints/tolerations) quand nécessaire.

Pièges fréquents

• penser que les namespaces suffisent comme frontière de sécurité
• laisser l’egress sans restriction (exfiltration et mouvements latéraux facilités)
• oublier que les composants “partagés” (ingress, agents de logging) amplifient le blast radius

Quand il faut une isolation plus forte

Namespaces + RBAC suffisent souvent pour des équipes internes, mais envisagez vcluster ou des clusters séparés quand :

• les équipes ont besoin de versions Kubernetes / policies d’admission différentes
• vous voulez des control planes par tenant (blast radius réduit)
• la conformité impose une séparation plus stricte (données régulées, environnements client)

Règle simple : clusters séparés pour le hard multi-tenancy, vcluster pour une isolation “intermédiaire”, namespaces pour le soft.

Checks opérationnels à ajouter

Le multi-tenancy, c’est aussi du day-2 :

• dashboards par namespace (throttling CPU/mémoire, usage quotas)
• rate limits sur l’ingress partagé
• checks de policies automatisés en CI (manifests, charts Helm)

Ce qu’il faut mesurer

• saturation de quotas et événements d’eviction
• violations de network policies / flux refusés
• blast radius des incidents (combien de tenants impactés)

Conclusion

Le multi-tenant ne se limite pas aux Namespaces. Il nécessite une approche en couches combinant limites de ressources, sécurité réseau et potentiellement des control planes virtualisés pour être réellement efficace et sécurisé.