Sysdig
Learn Cloud Native

Sign up to receive our newsletter

Progettare l’architettura Kubernetes più sicura di sempre

Gli ambienti Kubernetes assumono molte forme e dimensioni diverse. Alcuni sono intrinsecamente più sicuri di altri.

In altre parole, l’architettura di Kubernetes (cioè la strategia che si sceglie quando si progetta un ambiente Kubernetes) può avere implicazioni importanti sulla sicurezza in generale. Un ambiente multi cluster potrebbe essere per certi versi più sicuro di un ambiente in cui tutto viene eseguito su un cluster unico (sebbene più cluster comportino un aumento della complessità, il che rappresenta un problema dal punto di vista della sicurezza). Allo stesso modo, anche gli strumenti di terze parti hanno conseguenze sulla sicurezza, come accade per agenti di monitoraggio e service mesh che si potrebbe scegliere di includere in un’architettura Kubernetes.

E allora, quali strategie consentono di ottenere il massimo profilo di sicurezza in un’architettura Kubernetes? Il nostro articolo risponde a questa domanda analizzando le importanti scelte che gli amministratori devono compiere durante la progettazione di un ambiente Kubernetes e valutando l’impatto di ciascun elemento sulla sicurezza.

Servizio Kubernetes gestito vs. Kubernetes autogestito

Forse la prima domanda che molti team si pongono nel progettare un ambiente Kubernetes è se utilizzare un servizio gestito (come Amazon AKS, Azure Kubernetes Service o un’altra piattaforma Kubernetes su un cloud pubblico) o adottare e gestire Kubernetes in autonomia su un’infrastruttura che possono controllare.

Un servizio Kubernetes gestito è quasi sempre più facile da configurare e mantenere perché il provider Kubernetes gestisce almeno in parte la messa in servizio e la manutenzione richieste per mantenere attivi i cluster. (Si noti che la quantità di servizi di gestione offerta dai provider può variare notevolmente da un servizio Kubernetes “gestito” all’altro, ma questo argomento non è pertinente al nostro discorso.)

Le architetture Kubernetes gestite possono inoltre rivelarsi più sicure da due punti di vista:

  • L’infrastruttura dell’host è gestita e monitorata a livello professionale per combattere le minacce alla sicurezza. Con Kubernetes gestito, in altre parole, non è necessario preoccuparsi troppo delle questioni di sicurezza a livello di OS nei nodi.
  • Il provider di Kubernetes gestito potrebbe fornire impostazioni preconfigurate o strumenti che (almeno nella maggior parte dei casi) rispettano le migliori prassi dal punto di vista della sicurezza.

D’altro canto, poiché l’architettura Kubernetes gestita comporta l’utilizzo di strumenti e, in molti casi, di infrastrutture di proprietà di un fornitore, pone intrinsecamente un rischio poiché limita il controllo e la privacy degli utenti. Non è possibile utilizzare un servizio Kubernetes gestito se, ad esempio, si desidera “isolare” i cluster da Internet. E sebbene alcuni tipi di piattaforme Kubernetes gestite (come Platform9) siano compatibili con le infrastrutture on-premise, molte altre richiedono l’utilizzo di infrastrutture ospitate su un cloud pubblico, più esposto alle minacce per la sicurezza.

Infine: per i principianti di Kubernetes che non conoscono bene i suoi principi di sicurezza, un servizio gestito sarà probabilmente un ambiente più sicuro rispetto a un sistema configurato autonomamente. Ma se si necessita di un’architettura avanzata in termini di sicurezza e con funzioni quali l’air gapping, sarà necessario configurare e gestire l’ambiente in modo autonomo.

Architettura Kubernetes a singolo cluster vs multi cluster

Un’altra decisione chiave per l’architettura di un sistema Kubernetes è se configurare un unico cluster o un insieme di più cluster.

Tradizionalmente, quasi tutti i team hanno sempre utilizzato un singolo cluster. Tuttavia, gli ambienti multi cluster diventano sempre più popolari, secondo la CNCF, in parte perché consentono di ottenere un maggiore grado di isolamento tra i workload. È possibile utilizzare workload diversi in cluster diversi, il che riduce notevolmente il rischio che un problema di sicurezza in un workload si estenda a tutti gli altri. Maggiori informazioni sulla protezione dei cluster di Kubernetes.

Ciò detto, i team devono soppesare i vantaggi per la sicurezza rispetto al principale svantaggio posto da Kubernetes multi cloud: una maggiore complessità. Più cluster significano più registri di controllo da tracciare, più policy RBAC da creare, applicare e monitorare, più reti da configurare e isolare, eccetera.

Se si dispone di solide automazioni per la gestione e il monitoraggio dei cluster, questa maggiore complessità potrebbe non rappresentare un grande problema. In questo caso, un’architettura multi cluster può essere la soluzione da scegliere. Tuttavia, se si fatica a tenere traccia di tutti gli elementi in una configurazione di questo tipo, è meglio scegliere un singolo cluster per facilitare la gestione di attività quali il rilevamento degli eventi di sicurezza e il continuo aggiornamento delle policy RBAC.

Namespace singolo vs namespace multipli

Anche se non si scelgono più cluster, è possibile ottenere un isolamento adeguato dei workload creando namespace multipli. I namespace sono, essenzialmente, cluster virtuali ospitati all’interno di un unico cluster fisico.

Tipicamente, si crea un namespace diverso per ogni applicazione in esecuzione su Kubernetes. Bisognerebbe inoltre creare diversi namespace per sviluppo/test e produzione.

È tuttavia necessario ricordare che l’isolamento garantito dai namespace è limitato. Tutte le autorizzazioni assegnate in ClusterRoles verranno infatti applicate a tutti i namespace. In questo senso, prevedere più namespace è un vantaggio solo se si creano policy RBAC che consentono di isolare utenti e account all’interno di ciascun namespace. Per fare questo, è necessario assegnare le autorizzazioni utilizzando Roles al posto di ClusterRoles quando possibile.

Service mesh

Le service mesh, che gestiscono il rilevamento dei servizi e la connettività per le risorse eseguite all’interno di un cluster Kubernetes, sono uno strumento fondamentale per qualunque ambiente Kubernetes che includa più di qualche servizio.

In generale, le service mesh sono un vantaggio dal punto di vista della sicurezza di Kubernetes. Oltre ad aiutare nella gestione della connettività, forniscono anche funzioni di monitoraggio e avviso che consentono di rilevare le minacce alla sicurezza. Dal momento che Kubernetes da solo non registra gli incidenti di sicurezza legati alla rete (gli eventi registrati da Kubernetes non coprono la rete ma solo le API), le service mesh colmano un’importante lacuna nella visibilità.

Di contro, però, aumentano la superficie di attacco generale e la complessità di Kubernetes. Un hacker che riesce a violare una service mesh può usarla come punto di partenza per violare l’intero cluster (o tutti i cluster).

Ciò detto, se le service mesh vengono utilizzate in modo sicuro, è possibile mitigare i rischi associati. Se si utilizzano software per service mesh attraverso container sidecar che vengono eseguiti accanto ai pod dell’applicazione, è necessario accertarsi di isolare i sidecar e di bloccare l’accesso mediante policy RBAC e di rete.

Monitoraggio esterno e software di sicurezza

Oltre alle service mesh, è comune per i team impiegare software di monitoraggio delle prestazioni e della sicurezza di terze parti per facilitare la gestione dei cluster.

Anche questi strumenti ampliano la superficie di attacco. Ma se vengono utilizzati in sicurezza, i loro vantaggi sono di gran lunga superiori ai rischi che pongono.

È possibile ottimizzare la sicurezza degli strumenti esterni seguendo prassi quali:

  • Come già menzionato, applicare il principio dei privilegi minimi agli agenti che eseguono i container sidecar.
  • Quando possibile, utilizzare webhook per trasferire i dati da Kubernetes agli strumenti esterni. In questo modo, si evita la necessità di eseguire direttamente lo strumento all’interno del cluster, il che pone un maggiore rischio per la sicurezza rispetto all’esecuzione isolata dello strumento.
  • Accertarsi di proteggere tutti i dati generati o archiviati in modo permanente dagli strumenti esterni. Informazioni quali quelle che si trovano sui registri di controllo di Kubernetes potrebbero aiutare gli autori di un attacco ad accedere ai cluster, quindi è necessario prestare la massima attenzione al modo in cui vengono gestiti.

Progettare l’architettura Kubernetes più sicura di sempre

In definitiva, non esiste un approccio univoco alla progettazione di un’architettura Kubernetes sicura. Da questo punto di vista, le decisioni riflettono solitamente le dimensioni dell’ambiente, i tipi di workload eseguiti e il numero di utenti o team che condividono l’ambiente. Ambienti più piccoli saranno probabilmente più semplici da progettare e richiedono minori strumenti esterni, il che si traduce in un profilo di sicurezza più forte per definizione.

Tuttavia, gli ambienti complessi, ovvero quelli composti da più cluster e da molte integrazioni di terze parti, possono essere tanto sicuri quanto le configurazioni dall’architettura più semplice.

Per questo, la chiave per progettare un ambiente Kubernetes sicuro non è evitare un certo tipo di configurazione o non includere un determinato strumento. Si tratta piuttosto di assicurare che, tutte le volte in cui si aumenta la complessità dell’architettura di Kubernetes, si individuino e si risolvano le implicazioni che ogni decisione ha sulla sicurezza.