Kubernetes Security 101: nozioni di base e migliori prassi

Proteggere Kubernetes potrebbe sembrare un compito dalla difficoltà sconcertante. Essendo un sistema altamente complesso che consiste di diversi componenti, Kubernetes non può essere protetto semplicemente attivando un modulo di sicurezza o installando uno strumento.

Al contrario, i team devono occuparsi di ogni singolo componente che potrebbe avere un impatto sulla sicurezza dei diversi livelli e servizi presenti all’interno di un cluster Kubernetes. I team, ad esempio, devono sapere in che modo si proteggono nodi, reti, pod, dati, eccetera.

Inoltre, gli amministratori di Kubernetes devono conoscere quali sono gli strumenti nativi che consentono di affrontare i problemi relativi alla sicurezza e quali tipi di strumenti terzi dovranno integrare nei cluster per colmare le lacune. Anche questo è un argomento complesso poiché, sebbene Kubernetes non sia una piattaforma di sicurezza, fornisce alcuni strumenti nativi quali il Role-Based Access Control (RBAC).

Tutto questo può sembrare una montagna insuperabile per chi si approccia a Kubernetes per la prima volta e sta ancora cercando di capire come funzioni il sistema (ed è quindi ben lontano dall’occuparsi della sua protezione). Ma, in realtà, i concetti di base sono piuttosto semplici da capire se si suddividono in piccoli bocconi digeribili. E dunque, questo articolo presenta le varie sfaccettature della sicurezza di Kubernetes e spiega le nozioni fondamentali di ciascuna, oltre a indicare le migliori prassi per ogni livello e ogni servizio.

La sicurezza di Kubernetes, elemento per elemento

Forse, il modo più semplice per avvicinarsi alla sicurezza di Kubernetes è pensare ai tipi di rischi che hanno conseguenze su ognuno dei suoi stack e individuare gli strumenti e le risorse disponibili per scongiurarli.

Sicurezza dei nodi

I nodi sono i server che compongono i cluster di Kubernetes. In molti casi, eseguono una qualche versione di Linux, anche se i nodi worker possono anche eseguire Windows. Possono essere macchine virtuali o server bare metal, ma non vi è alcuna differenza in termini di sicurezza.

Per proteggere i nodi, bisognerebbe adottare le stesse strategie di sicurezza impiegate per proteggere un qualunque tipo di server. Tali strategie includono:

• Rimuovere le applicazioni, le librerie e altri componenti estranei al sistema operativo per minimizzare la superficie di attacco. Dotare i nodi di distribuzioni minimaliste di Linux, ad esempio Alpine Linux, una prassi consigliata.
• Eliminare gli account utente non necessari.
• Assicurare che a livello di root siano eseguiti solo i componenti strettamente necessari.
• Ove disponibili, utilizzare strumenti di rinforzo dell’OS quali AppArmor o SELinux.
• Raccogliere e analizzare i registri dell’OS per rilevare eventuali violazioni.

Se si ha esperienza nella protezione dei server a livello di sistema operativo in qualunque tipo di ambiente, dunque, gestire la sicurezza dei nodi in Kubernetes non rappresenterà un problema. In effetti, gli elementi da considerare per gestire la sicurezza a livello di nodi in ambiente Kubernetes non sono molto diversi dalla gestione dei nodi in qualunque altro tipo di server.

Non esistono differenze fondamentali tra la protezione di un nodo master e la protezione di un nodo worker. La protezione dei nodi master è per certi versi più importante, perché la sua violazione potrebbe causare danni maggiori al cluster, ma le procedure per proteggere il sistema operativo o un nodo master sono le stesse da adottare per i nodi worker.

Sicurezza dell’API di Kubernetes

L’API di Kubernetes è ciò che tiene insieme i vari componenti di un cluster. Per questo, rappresenta una delle risorse fondamentali da proteggere.

L’API di Kubernetes è sicura per definizione. È progettata per rispondere solo alle richieste che può adeguatamente autenticare e autorizzare.

Detto questo, l’autenticazione e l’autorizzazione di un’API sono gestite da policy RBAC configurate. Pertanto, l’API è sicura solo tanto quanto lo sono le policy RBAC. Creare policy RBAC sicure che applichino il principio dei privilegi minimi e assegnino autorizzazioni su base granulare è pertanto una migliore prassi per garantire la sicurezza dell’API di Kubernetes.

Inoltre, è possibile migliorare ulteriormente la protezione dell’API sfruttando i controller di ammissione. I controller di ammissione valutano le richieste dopo che il server API le ha già autenticate e autorizzate. In questo modo, i controller di ammissione rappresentano un livello di difesa secondario opzionale contro le richieste che non dovrebbero essere consentite. Abilitando e configurando i controller di ammissione, è possibile applicare diverse regole di sicurezza legate alle richieste API. Le regole disponibili sono documentate qui. 

Infine, le richieste API possono essere protette a livello di rete configurando certificati di sicurezza e richiedendo al server API di gestire le richieste su una porta sicura e non sul localhost.

Sicurezza della rete in Kubernetes

La sicurezza della rete in Kubernetes è simile alla sicurezza dei pod, in quanto inizia sempre dal rispetto delle migliori prassi adottate per proteggere una qualsiasi rete.

Bisogna, per quanto possibile, accertarsi di creare un’architettura di rete in grado di isolare i workload dall’Internet pubblico a meno che non debbano interfacciarsi con esso. È necessario predisporre firewall a livello di gateway per bloccare il traffico dagli host danneggiati. Si deve monitorare il traffico di rete alla ricerca di segnali che indichino una violazione. È possibile svolgere tutti questi passaggi utilizzando strumenti esterni a Kubernetes, ad esempio le service mesh.

Tuttavia, Kubernetes offre anche qualche strumento nativo che aiuta a proteggere le risorse di rete. Si tratta delle policy di rete. Sebbene le policy di rete non siano di per sé una funzionalità di sicurezza, gli amministratori possono utilizzarle per controllare i flussi di traffico all’interno di un cluster Kubernetes.

Pertanto, è possibile creare policy di rete per isolare i pod a livello di rete o per filtrare il traffico in entrata.

Le policy di rete non sostituiscono le configurazioni di sicurezza esterne a Kubernetes; al contrario, bisogna pensare a loro come a una risorsa aggiuntiva che completa le regole di sicurezza elaborate per tutta l’architettura di rete.

Sicurezza dei pod di Kubernetes

In Kubernetes, un pod è un container o un set di container utilizzato per eseguire un’applicazione. Per proteggere l’applicazione, quindi, è necessario proteggere i pod.

Alcuni aspetti della sicurezza dei pod devono essere gestiti tramite pratiche esterne a Kubernetes. Bisognerebbe effettuare test di sicurezza sull’applicazione prima di distribuirla e scansionare le immagini dei container prima di eseguirli. Bisognerebbe inoltre raccogliere i registri dei pod e analizzarli per rilevare eventuali violazioni o abusi.

Tuttavia, Kubernetes offre alcuni strumenti nativi che possono rafforzare la protezione dei pod quando sono in esecuzione. Essi includono:

• Policy RBAC, che possono essere utilizzate per gestire gli accessi ai pod da parte di utenti e servizi all’interno del cluster.
• Contesti di protezione, che definiscono il livello di privilegi con cui vengono eseguiti i pod.
• Policy di rete, le quali (come già sottolineato) possono essere utilizzate per isolare i pod a livello di rete.
• Controller di ammissione, che possono applicare regole aggiuntive che, in pratica, estendono le regole stabilite in base all’RBAC.

I tipi di strumenti per la sicurezza dei pod e il modo in cui si configurano dipendono dalla natura dei workload. Non esiste un approccio univoco alla sicurezza dei pod. Alcuni di essi possono essere completamente isolati dagli altri a livello di rete, per esempio, mentre altri devono essere in grado di comunicare.

Qualunque siano i requisiti specifici, tuttavia, bisognerebbe valutare le risorse disponibili per proteggere i pod Kubernetes e assicurarsi di trarre il massimo dalle loro funzionalità.

Sicurezza dei dati in Kubernetes

Kubernetes non archivia alcun dato tranne quelli non permanenti che risiedono nei pod in esecuzione e i dati dei registri archiviati sui nodi. Tipicamente, i dati che i cluster creano e/o a cui accedono vengono archiviati su qualche sistema di archiviazione esterno che si interfaccia con Kubernetes attraverso un plugin di archiviazione.

Per archiviare i dati associati a Kubernetes, quindi, bisogna rispettare le migliori prassi che vengono adottate per proteggere i dati in un sistema di archiviazione su larga scala. Crittografare i dati in tutti i casi in cui è possibile farlo. Utilizzare strumenti per il controllo degli accessi per limitare chi può accedere ai dati. Assicurarsi che i server che gestiscono i pool di archiviazione siano propriamente bloccati. Effettuare il backup dei dati per proteggersi da furti o attacchi ransomware.

Per le piccole quantità di dati che risiedono nativamente all’interno dei pod e dei nodi di Kubernetes, quest’ultimo non offre strumenti speciali di protezione. Tuttavia, è possibile proteggerli ricorrendo alle migliori prassi descritte sopra.

Ulteriori risorse di sicurezza di Kubernetes

Oltre le prassi di sicurezza specifiche descritte per ciascun componente, gli amministratori dovrebbero conoscere le ulteriori risorse di sicurezza disponibili per Kubernetes.

Registri di controllo

Kubernetes può, in opzione, mantenere registri granulari delle azioni svolte in un cluster, di chi le ha effettuate e dei loro risultati. Utilizzando questi registri di controllo, è possibile verificare in modo completo tutti i cluster al fine di rilevare possibili problemi di sicurezza in tempo reale e ricercare i segnali di incidenti già avvenuti.

Per utilizzare i registri di controllo, è prima necessario creare una policy che definisce il modo in cui Kubernetes registrerà gli eventi. La documentazione Kubernetes descrive nel dettaglio come si stabiliscono le policy di controllo.

Inoltre, dal momento che Kubernetes non fornisce strumenti per l’analisi su scala dei registri di controllo, è consigliabile trasferire questi ultimi a uno strumento di monitoraggio esterno o a una piattaforma di osservabilità, i quali aiuteranno a rilevare eventuali anomalie e avviseranno in caso di violazione. Altrimenti, è possibile monitorare i registri di controllo manualmente, ma questa operazione non è praticabile su larga scala.

Namespace

In Kubernetes, i namespace possono essere utilizzati per isolare diversi workload l’uno dall’altro.

Anche se è possibile eseguire tutto all’interno di un unico namespace, in termini di sicurezza è consigliabile creare diversi namespace per ciascun team e/o tipo di workload nel cluster. Si potrebbero ad esempio separare gli ambienti dev/test dalla produzione utilizzando diversi namespace.

Gestire più namespace aumenta la complessità di amministrazione di Kubernetes, poiché è necessario creare diverse policy RBAC per ciascun namespace in molti casi (ma non in tutti). Tuttavia, vale la pena compiere questo ulteriore sforzo per minimizzare il potenziale impatto di una violazione.

Utilizzare strumenti di sicurezza esterni con Kubernetes

Sebbene Kubernetes offra alcuni strumenti per rafforzare la protezione delle risorse in esecuzione nel cluster, non è appositamente pensato per rilevare o gestire gli incidenti di sicurezza.

Per gestire la sicurezza di Kubernetes su scala più ampia, sarà necessario appoggiarsi a strumenti esterni. Questi strumenti possono svolgere diverse funzioni di sicurezza importanti, tra cui:

• Scansione delle policy, dei contesti di protezione e di altri dati di configurazione per individuare errori di configurazione che potrebbero determinare problemi per la sicurezza.
• Funzionalità di scansione di applicazioni e immagini dei container, che possono aiutare a creare una pipeline di sicurezza automatizzata da inserire nei cluster Kubernetes.
• Raccogliere, aggregare e analizzare i registri delle applicazioni e di controllo per rilevare anomalie che potrebbero indicare una violazione.

Esistono molti strumenti di sicurezza esterni per Kubernetes, compreso ovviamente Sysdig, appositamente progettato per aiutare i team DevOps a proteggere a tutti i livelli Kubernetes e gli altri ambienti cloud nativi.