In questo articolo affronteremo i seguenti temi:
Kubernetes Multi-tenancy: quale strada prendere?
Kubernetes è uno strumento di orchestrazione per containers che permette di creare, distribuire e gestire applicazioni containerizzate in modo efficace e scalabile. Tuttavia, in un ambiente multi-tenancy, è importante garantire che ogni tenant abbia accesso solo alle risorse a cui ha diritto e che la sua applicazione sia isolata dalle altre.
Multi-tenancy: cos’è?
La multi-tenancy è un concetto utilizzato nell’ambito dell’informatica e del cloud computing. Si riferisce a un’architettura in cui un’unica istanza di un’applicazione o di un sistema viene condivisa da più utenti o organizzazioni, chiamati inquilini o tenant, in modo che ognuno di essi abbia un ambiente isolato e separato dagli altri. Ciò consente a diversi utenti di utilizzare lo stesso sistema o servizio, pur mantenendo i propri dati, le proprie configurazioni e le proprie personalizzazioni in modo indipendente. L’obiettivo principale della multi-tenancy è ottimizzare l’efficienza delle risorse, consentendo di condividere infrastrutture e costi tra più utenti senza compromettere la sicurezza e l’isolamento dei dati.
Cos'è la multi-tenancy in Kubernetes?
In Kubernetes, la multi-tenancy è un concetto che consente di ospitare e gestire più applicazioni o carichi di lavoro in un singolo cluster. Questo viene realizzato tramite l’isolamento e la separazione delle risorse, consentendo a diversi utenti, team o inquilini di condividere la stessa infrastruttura senza interferire l’uno con l’altro. Kubernetes fornisce strumenti come i namespace, che consentono di creare spazi di lavoro virtuali all’interno del cluster, in modo che ogni inquilino abbia il proprio ambiente isolato e possa gestire le proprie risorse, come i pod, i servizi e le politiche di accesso. Ciò consente una gestione più efficiente delle risorse e la possibilità di eseguire applicazioni diverse senza interferenze tra di loro. In sintesi, la multi-tenancy in Kubernetes permette di supportare più utenti o team, mantenendo l’isolamento, la scalabilità e l’efficienza delle risorse all’interno del cluster.
Ecco alcuni esempi di tenant o inquilini in un ambiente Kubernetes:
- Azienda A e azienda B: un cluster Kubernetes può ospitare applicazioni di diverse aziende, ad esempio Azienda A e Azienda B, consentendo loro di gestire i propri servizi, applicazioni e risorse in modo isolato. Ogni azienda avrà il proprio namespace dedicato all’interno del cluster.
- Team di sviluppo e team di operazioni: un’organizzazione può avere diversi team, come un team di sviluppo e un team di operazioni. Utilizzando Kubernetes, ogni team può avere il proprio namespace e gestire le proprie applicazioni e risorse, mantenendo i loro ambienti separati e isolati.
- Ambienti di sviluppo, test e produzione: nell’ambito dello sviluppo software, è comune avere ambienti separati per lo sviluppo, il test e la produzione. Utilizzando Kubernetes, è possibile creare namespace dedicati per ogni ambiente, consentendo ai team di sviluppo di lavorare in modo indipendente senza interferenze con gli altri ambienti.
- Applicazioni di terze parti: un cluster Kubernetes può ospitare anche applicazioni di terze parti o servizi esterni forniti da fornitori diversi. Ogni fornitore o applicazione può essere gestito all’interno di un namespace separato, garantendo l’isolamento e la separazione dei dati e delle risorse.
Come si costruisce la multi-tenancy in Kuberntes?
Implementare un ambiente multi-tenant in Kubernetes non è una cosa semplicissima. Kubernetes offre nativamente diverse funzioni per costruire un isolamento tra i vari tenant, tuttavia sarà cura dell’amministratore del cluster assicurarsi di configurare il cluster correttamente e garanti un alto livello di isolamento.
Le principali funzioni offerte da Kubernetes per costruire un ambiente multi-tenant sono le seguenti:
- Namespaces
- Network Policies
- ResourceQuotas
- RBAC
Namespace
Un namespace è un’astrazione logica che consente di creare più spazi virtuali all’interno di un unico cluster fisico. I namespace permettono di separare le risorse tra più utenti, in modo che ogni utente possa creare le proprie risorse all’interno del proprio namespace.
L’uso di namespace è il metodo più semplice e comune per implementare la multi-tenancy in Kubernetes, ma non è sufficiente per garantire l’isolamento completo tra le risorse di diversi utenti.
Network Policies
Le network policy (NP) consentono di definire regole di sicurezza per il traffico di rete tra i pod all’interno del cluster. Ciò significa che è possibile limitare il traffico di rete tra i pod di diversi utenti, consentendo solo le comunicazioni necessarie tra le applicazioni.
In poche parole, le network policy sono delle regole di firewall che permettodo di filtrare il traffico di rete all’interno del traffico.
ResourceQuotas
ResourceQuota (RQ) è un meccanismo in Kubernetes utilizzato per limitare le risorse consumate da namespace all’interno di un cluster. Consente di impostare limiti specifici per la quantità di CPU, memoria, storage e altri tipi di risorse che un tenant può utilizzare. In altre parole, ResourceQuota definisce dei vincoli sui consumi delle risorse per evitare che un tenant o un namespace monopolizzi o esaurisca tutte le risorse disponibili nel cluster. Questo permette di mantenere un equilibrio e una distribuzione equa delle risorse tra diversi utenti, applicazioni o team all’interno del cluster Kubernetes. Quando un ResourceQuota viene raggiunto, Kubernetes può impedire la creazione di nuove risorse o limitarne le operazioni, evitando sovrasaturazione o congestionamento del sistema. Pertanto, ResourceQuota è uno strumento utile per la gestione e il controllo delle risorse all’interno di un ambiente Kubernetes.
RBAC
RBAC, acronimo di Role-Based Access Control (Controllo degli Accessi Basato sui Ruoli), è un meccanismo di gestione degli accessi in Kubernetes. Consente di definire e controllare in modo granulare i privilegi di accesso degli utenti o dei servizi all’interno del cluster. Utilizzando RBAC, è possibile assegnare ruoli specifici agli utenti o ai gruppi e definire le autorizzazioni per le operazioni che possono eseguire sui diversi oggetti di Kubernetes, come i pod, i servizi o i volumi. Questo approccio permette di garantire la sicurezza e l’isolamento all’interno del cluster, consentendo solo a utenti autorizzati di accedere e manipolare le risorse in base ai ruoli loro assegnati. In sostanza, RBAC in Kubernetes fornisce un controllo fine-grained sugli accessi per gestire e proteggere le risorse del cluster.
Tutto qua? Basta solo questo?
Magari. In realtà la multi tenancy in Kubernetes è uno di quei temi tanti discussi e che a volte spaventano. In primis, bisognerebbe capire che livello di multi-tenancy vogliamo implementare: Soft o Hard.
Soft è quando ci possiamo fidare dei vari tenant che lavorano nello stesso cluster e quindi facendo leva su Namespace, RQ, RBAC e NP già possiamo ottenere un buon livello di isolamento. Un scanario soft potrebbe essere rappresentato da diversi team della stessa azienda che lavorano nello stesso cluster.
Hard è quando non ci possiamo assolutamente fidare dei tenant che lavorano nello stesso cluster, e quindi bisogna massimizzare il livello di isolamento e sicurezza. Per questo, nelle vesti di amministratori del cluster kubernetes, non possiamo affidarci esclusivamente a quello che Kubernetes nativamente offre, bensì bisogna considerare l’integrazione di tool di terze parti che possano potenziare il livello di isolamento e di security all’interno di tutto il cluster.
Il consiglio generale è sicuramente quello di capire in quale contesto ci troviamo, che livello di isolamento vogliamo raggiungere, che livello di sicurezza vogliamo avere e soprattutto come intendiamo gestire la multi-tenancy e il relativo effort in termini di operations che vogliamo investire. Molto spesso la soluzione ideale è quella di affidarsi ad un tool di terze parte che si concentra sulla risoluzione di questo problema, ovvero la gestione della multi-tenancy.
Probabilmente hai bisogno di Capsule
Capsule è un progetto open source tutto italiano sviluppato dai nostri amici di Clastix che si propone di semplificare la gestione della sicurezza e della conformità nei cluster Kubernetes multitenancy. Il progetto prevede l’uso di un controller personalizzato che si integra con Kubernetes per fornire una serie di funzionalità di sicurezza avanzate.
In particolare, Capsule introduce seriamente il concetto di “tenancy” in Kubernetes, permettendo di creare ambienti isolati all’interno di un unico cluster. Ogni tenancy ha il proprio set di regole di sicurezza, policy di rete e di autorizzazione, garantendo una gestione più facile e sicura delle risorse del cluster.
Capsule supporta anche l’integrazione con strumenti di sicurezza di terze parti, come ad esempio gli strumenti di analisi delle vulnerabilità, le soluzioni di identità e accesso, e gli strumenti di auditing e monitoring.
In sintesi, Capsule è un progetto interessante per le organizzazioni che intendono utilizzare Kubernetes in modalità multitenancy e che desiderano semplificare la gestione della sicurezza e della conformità nei propri cluster.
Conclusione
Come sempre nulla è tutto rosa e fiori, ma sicuramente dopo un’attenta analisi del proprio contesto diventa più semplice capire quale strada intraprendere e come risolvere la tematica della multi-tenancy in Kubernetes.
Scopri tutto ciò che c’è da sapere su Kubernetes partecipando ai corsi Kubernetes DSK proposti da Desotech!
Condividi l’articolo!!
Scopri i nostri corsi!
Francesco Grimaldi
VMware Certified Instructor | Kubernetes Instructor | DAI | LFAI | SCI | CKA + CKAD
Team Leader, docente e consulente IT su tecnologie verticalizzate al mondo datacenter e Cloud-Native, attento ai dettagli, cerco di essere il più preciso possibile e non mi fermo finché non risolvo il problema.
Nel 2022 ho ricevuto da VMware il premio come “VMware Instructor of Excellence” in tutta EMEA. Quando spiego mi piace essere chiaro e diretto, senza dare nulla per scontato. Adoro trasmettere le mie conoscenze ad altri!
