Multi-tenancy in Kubernetes: modelli, layer di isolamento e best practice

TL;DR

• Multi-tenancy in Kubernetes significa eseguire più team, progetti o clienti su un unico cluster condiviso invece che su un cluster dedicato ciascuno — e nessun isolamento avviene in automatico.
• Quattro layer fondamentali la tengono insieme: namespace, RBAC, network policy e resource quota (LimitRange inclusi), oltre ai Pod Security Standards che proteggono il livello dei workloads. Basta trascurarne uno e un tenant che dovrebbe restare isolato inizia a interferire con tutti gli altri.
• Esistono tre modelli di isolamento: soft (basato sui namespace, il più economico, isolamento solo logico), hard (cluster virtuali come vCluster o Capsule) e fisico (node pool o cluster dedicati, isolamento più forte, costi più alti). La maggior parte delle organizzazioni li combina tutti e tre invece di standardizzarsi su uno solo.
• La maggior parte dei problemi deriva dal drift, non da una configurazione iniziale sbagliata: i team configurano correttamente quote e RBAC una volta sola e poi non le rivedono più mano a mano che i workloads cambiano.

Con dieci team su un unico cluster Kubernetes, di default nulla impedisce al team A di leggere i secret del team B, di consumare la CPU del team B o di mettere fuori uso un control plane da cui dipende anche il team B. La multi-tenancy in Kubernetes colma questa lacuna attraverso quattro layer configurabili: namespace, RBAC, network policy e resource quota.

La multi-tenancy permette alle organizzazioni di smettere di pagare decine di control plane inattivi e iniziare a condividere l'infrastruttura tra team, progetti o clienti (i "tenant"). Funziona solo se ognuno di quei layer viene effettivamente configurato e resta configurato. Kubernetes non è multi-tenant di default. I namespace tracciano un confine logico, non un confine di sicurezza. Basta saltare un layer e un tenant che avrebbe dovuto restare isolato inizia a ripercuotersi su tutti gli altri nel cluster, che si tratti di una violazione del perimetro di sicurezza o semplicemente di un workload che consuma la CPU di un altro.

Perché i team scelgono di condividere un cluster

Tre motivi ricorrono in quasi tutti i casi: costi, carico operativo e velocità di sviluppo.

Gestire dieci cluster significa dieci control plane, dieci set di node pool sovradimensionati, dieci load balancer inattivi per gran parte della giornata. Consolidare in due o tre cluster condivisi riduce direttamente questo overhead. E riduce anche il carico operativo: un solo cluster da aggiornare, un solo punto in cui monitorare lo stato di etcd, un solo set di policy da mantenere coerente, invece dello stesso lavoro ripetuto su ogni cluster in esercizio.

La velocità degli sviluppatori conta altrettanto, anche se si nota meno. I team che aspettano che un platform team esegua il provisioning di un nuovo cluster aspettano giorni. I team che richiedono un namespace su un cluster multi-tenant esistente possono ottenerlo in pochi minuti, in self-service, con quote e network policy già configurate. I platform team lo chiamano "namespace-as-a-service", ed è spesso proprio questo il motivo per cui costruiscono la multi-tenancy.

I tre modelli di multi-tenancy

Non tutti i tenant hanno bisogno dello stesso isolamento. Il modello scelto è un compromesso tra blast radius, costi e complessità operativa che si decide di gestire.

La maggior parte delle organizzazioni non sceglie un solo modello e si ferma lì. Usa la multi-tenancy soft per i team interni fidati e riserva l'isolamento hard o fisico ai pochi tenant (un cliente esterno, un team ML ad alto consumo di GPU, un workload regolamentato) che ne hanno davvero bisogno. Trattare la "multi-tenancy" come un semplice interruttore on/off porta a sovradimensionare o sottodimensionare molti di questi progetti fin dall'inizio.

I layer di isolamento che sostengono la multi-tenancy soft

La maggior parte dei team parte di default dalla multi-tenancy soft. È costruita su quattro layer, e vanno configurati tutti: nessuno è attivo out of the box.

I namespace forniscono il confine a cui si aggancia tutto il resto: un punto in cui delimitare RBAC, quote e network policy. Da soli isolano i nomi, non il comportamento. Un pod nel namespace A può comunque comunicare con un pod nel namespace B, e un workload senza resource limit può comunque saturare un nodo usato anche dai pod del namespace B.

L'RBAC stabilisce chi può agire su cosa. Si parte da un approccio deny-by-default, si concedono i ruoli minimi di cui il team di ogni tenant ha realmente bisogno e si effettua il binding ai gruppi invece che ai singoli utenti, così gli accessi non si degradano quando le persone entrano ed escono dai team. Lo sprawl dell'RBAC dei tenant (decine di Role e RoleBinding quasi identici che si disallineano nel tempo) è tra le principali cause per cui i cluster multi-tenant diventano nel tempo sempre più difficili da sottoporre ad audit.

Le NetworkPolicy impediscono ai tenant di raggiungersi via rete, cosa che RBAC e namespace da soli non fanno:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: team-a

La maggior parte dei team parte con una policy default-deny per namespace, per poi aggiungere regole di allow esplicite per ciò che deve effettivamente comunicare tra namespace. Senza, qualsiasi pod del cluster può raggiungere di default qualsiasi altro pod. I namespace da soli non impongono confini di rete.

ResourceQuota e LimitRange impediscono a un singolo tenant di monopolizzare CPU, memoria o numero di oggetti a scapito del resto del cluster. Una ResourceQuota limita il consumo totale di un namespace; un LimitRange definisce al suo interno default e massimi ragionevoli per container. È qui che la multi-tenancy e il problema dei noisy neighbor si incontrano direttamente: una quota protegge il cluster solo se i team impostano correttamente le request e i limit sottostanti, vicini all'utilizzo reale. Quote troppo larghe non fermano i noisy neighbor; quote troppo strette spingono i team a gonfiare le request, vanificando i risparmi da consolidamento che la multi-tenancy aveva promesso.

I Pod Security Standards completano il quadro a livello di workload, limitando per namespace i container privilegiati, l'host networking e l'accesso root, così un attaccante che compromette un pod di un tenant non può fare escalation verso il nodo o il resto del cluster.