Il mondo dell’IT sta cambiando rapidamente e container e Kubernetes (K8s) stanno diventano sempre più diffusi. In soli sette anni, siamo passati da una macchina virtuale ai container, quindi a una piattaforma di orchestrazione dei container (la prima versione di Docker è stata lanciata nel 2013). Mentre alcune startup stanno ancora apprendendo come sfruttare queste nuove risorse, alcune aziende più longeve stanno cercando di migrare i loro sistemi di vecchia generazione su infrastrutture più efficienti.

Se da un lato la rapida adozione di container e Kubernetes dimostra quanto queste tecnologie siano state rivoluzionarie, dall’altro porta a nuovi problemi di sicurezza. L’ampia diffusione di queste tecnologie e il fatto che siano state adottate da numerose organizzazioni prive di misure di sicurezza adeguate hanno reso la containerizzazione e Kubernetes due bersagli ideali per gli hacker.

Un cluster K8s è un insieme di macchine gestite da un nodo primario e dalle sue repliche. Può includere migliaia di macchine e servizi e questa caratteristica lo rende un potenziale vettore di attacco molto interessante. L’adozione di rigorose pratiche di sicurezza è pertanto fondamentale.

Proteggere il cluster

I cluster Kubernetes includono numerose parti mobili che devono essere adeguatamente protette. La sicurezza dei cluster non può essere ottenuta mediante un unico processo, ma richiede una serie di best practice e un team responsabile della sicurezza competente.

In questo articolo illustreremo diversi vettori di attacco che prendeono di mira Kubernetes e le best practice per mantenere il vostro cluster K8s sicuro.

Mantenere aggiornati Kubernetes e i suoi nodi

K8s è un sistema open source che viene costantemente aggiornato. Il suo repository GitHub è uno dei più attivi della piattaforma e include costantemente nuove funzionalità, ottimizzazioni e aggiornamenti di sicurezza.

Ogni quattro mesi viene rilasciata una nuova versione principale di Kubernetes, che include nuove funzionalità per migliorare il servizio. Tali aggiornamenti, tuttavia, possono introdurre nuovi problemi di sicurezza o bug, un fatto questo che può interessare tutti i software, soprattutto quelli aggiornati frequentemente.

Anche le versioni meno recenti di un software, tuttavia, possono essere soggette a violazioni della sicurezza. È quindi fondamentale comprendere in che modo il team di Kubernetes gestisce gli aggiornamenti di sicurezza nelle versioni precedenti. A differenza di Linux o di altre piattaforme, Kubernetes non ha una versione LTS, ma cerca di eseguire il backport dei problemi di sicurezza alle tre versioni principali lanciate più di recente.

È quindi di vitale importanza che il vostro cluster si trovi in una delle tre versioni principali più recenti, in modo che possiate tenere sotto controllo le patch di sicurezza e pianificare gli aggiornamenti all’ultima versione principale almeno ogni dodici mesi.

Oltre i suoi componenti principali, Kubernetes gestisce nodi che eseguono il carico di lavoro assegnato al cluster. Questi nodi possono essere macchine fisiche o virtuali su cui viene eseguito un sistema operativo. Ogni nodo è un potenziale vettore di attacco e deve essere aggiornato per poter gestire eventuali problemi di sicurezza. I nodi devono pertanto essere il più possibile puliti per ridurre la superficie di attacco.

Limitare l’accesso degli utenti

Il controllo degli accessi in base al ruolo (RBAC) è uno dei modi migliori per controllare quali utenti hanno accesso al cluster e in che modo possono accedervi. Offre impostazioni dettagliate per definire le autorizzazioni di ciascun utente. Le regole sono sempre additive, per cui ogni autorizzazione deve essere concessa in modo esplicito. Il controllo degli accessi in base al ruolo consente di limitare l’accesso (visualizzazione, lettura o scrittura) per ogni oggetto di Kubernetes, dai pod (l’unità di calcolo K8s più piccola) agli spazi dei nomi.

Il controllo degli accessi in base al ruolo può anche essere associato a un altro servizio di directory utilizzando i token di OpenID Connect. Ciò consente di definire la gestione degli utenti e dei gruppi in modo centralizzato e di utilizzarla in modo più ampio all’interno dell’organizzazione.

Le autorizzazioni di accesso non sono limitate solo a Kubernetes. Ad esempio, a volte gli utenti potrebbero avere bisogno di accedere a un nodo del cluster per identificare i problemi. In questi casi, è consigliabile creare utenti temporanei per risolvere questi problemi ed eliminarli in un secondo momento.

Best practice per i container

Docker, la principale tecnologia di containerizzazione, è costituita da strati: lo strato più interno corrisponde alla struttura più primitiva, mentre quello esterno è lo strato più specifico. Pertanto, al momento della creazione, tutte le immagini di Docker includono il supporto di una distribuzione o di un linguaggio, dopodiché ogni nuovo strato aggiunge o modifica le funzionalità precedenti fino all’ultimo strato. Il container dovrebbe pertanto includere tutto il necessario per eseguire l’applicazione.

Questi strati (detti anche immagini) possono essere disponibili pubblicamente nel Docker Hub o privatamente in un altro registro di immagini. L’immagine può essere identificata in due modi: mediante un nome e un’etichetta (ad esempio, nodo:ultimo) o con il suo identificatore SHA invariabile (ad esempio, sha256:d64072a554283e64e1bfeb1bb457b7b293b6cd5bb61504afaa3bdd5da2a7bc4b per la stessa immagine al momento della scrittura).

L’immagine associata all’etichetta può essere modificata in qualsiasi momento dal proprietario del repository; pertanto, l’ultimo tag indica la versione più recente disponibile. Ciò significa anche che quando si crea una nuova immagine o si esegue un’immagine con un tag, lo strato interno può subire modifiche improvvise senza alcun preavviso.

Questa strategia ovviamente pone alcuni problemi: (1) Si perde il controllo di ciò che è in esecuzione nell’istanza Kubernetes, in quanto dall’aggiornamento di uno strato superiore può derivare un conflitto; oppure, (2) l’immagine può essere modificata intenzionalmente per introdurre una violazione della sicurezza.

Per evitare il primo problema, cercate di non utilizzare l’ultimo tag, ma optate invece per un tag più specifico per la versione (ad esempio, nodo:14.5.0). Per evitare il secondo problema, invece, scegliete immagini ufficiali, clonate l’immagine nel vostro repository privato o utilizzate il valore SHA.

Un altro approccio consiste nell’utilizzare uno strumento di rilevamento delle vulnerabilità che analizza continuamente le immagini scelte. Questi strumenti possono essere eseguiti insieme alle pipeline di integrazione continua e sono in grado di monitorare il repository delle immagini per identificare problemi non rilevati in precedenza.

Quando si crea una nuova immagine, è importante ricordare che ogni immagine deve contenere un solo servizio. Dovrebbe inoltre includere solo le dipendenze necessarie per una determinata applicazione. Ciò riduce la superficie di attacco ai soli componenti essenziali per il servizio. Inoltre, la presenza di una sola applicazione per immagine semplifica l’aggiornamento a una nuova versione e l’allocazione delle risorse nell’agente di orchestrazione.

Sicurezza di rete

La necessità di ridurre la superficie di attacco, illustrata nella sezione precedente, si applica anche alle reti. Kubernetes include reti virtuali all’interno del cluster che possono limitare l’accesso tra i pod e consentire l’accesso esterno, in modo che sia possibile accedere solo ai servizi per i quali si dispone dell’autorizzazione. Si tratta di una soluzione semplice adatta per i cluster di piccole dimensioni.

Ma i cluster più grandi che includono diversi servizi sviluppati da vari team sono molto più complessi e un approccio centralizzato può essere impossibile da gestire. In questi casi, il metodo più indicato è quello delle mesh di servizi. Una mesh di servizi crea un livello di crittografia sulla rete che consente la comunicazione sicura tra i servizi. Di solito svolge la funzione di un agente sidecar che è incluso in ciascun pod e consente la comunicazione tra i servizi. Le mesh di servizi non riguardano solo la sicurezza, ma consentono anche il svolgere attività di rilevamento e di monitoraggio/tracciamento/registrazione dei servizi ed evitano l’interruzione dei servizi mediante l’applicazione, ad esempio, di un pattern di interruzione del circuito.

Definire quote di risorse

Poiché le applicazioni vengono aggiornate costantemente, la sola implementazione delle modalità di protezione illustrate sopra non è sufficiente a garantire la sicurezza del cluster, dal momento che continua a sussistere il rischio di una violazione della sicurezza.

Le quote di risorse di Kubernetes, che consentono di gestire la copertura delle interruzioni in base a vincoli prestabiliti, rappresentano un ulteriore passo in avanti. Se i vincoli sono ben progettati, impediranno che tutti i servizi del cluster non siano disponibili a causa dell’esaurimento delle risorse.

Possono anche evitarvi una fattura per i servizi cloud eccessivamente salata alla fine del mese.

Monitoraggio e registrazione

Il monitoraggio del cluster fino ai pod è essenziale per rilevare le interruzioni e individuarne la causa. Il fattore più importante è individuare eventuali comportamenti anomali. Se il traffico di rete aumenta o la CPU dei nodi si comporta in modo diverso dal solito, è necessario eseguire ulteriori indagini per escludere la presenza di problemi. Mentre il monitoraggio riguarda principalmente metriche come la CPU, la memoria e la rete, la registrazione può fornire informazioni aggiuntive (di carattere cronologico) utili per rilevare pattern insoliti o per identificare rapidamente la causa del problema.

Utilizzati insieme, Prometheus e Graphana sono strumenti efficaci per il monitoraggio di Kubernetes. Prometheus è un database di serie temporali ad alte prestazioni, mentre Graphana è un dashboard grafico che consente di visualizzare in modo semplice i dati di Prometheus.

ElasticSearch è un altro strumento utile, e anche uno dei più popolari, per eseguire registrazioni centralizzate quasi in tempo reale dell’applicazione, dei nodi e di Kubernetes.

Installazione on-premise o sul cloud: il punto di vista della sicurezza

L’installazione di Kubernetes può essere effettuata on-premise oppure utilizzando un servizio di gestione basato sul cloud. Nello scenario on-premise, ogni configurazione, che prevede l’esecuzione di nuove macchine, l’impostazione della rete e la messa in sicurezza dell’applicazione, deve essere eseguita manualmente. I servizi gestiti basati sul cloud, come Google GKE, AWS EKS o Azure AKS, consentono invece l’installazione di K8s con una configurazione minima e sono compatibili con altri servizi del provider di cloud.

Dal punto di vista della sicurezza, le soluzioni on-premise richiedono molta più attenzione. Come già detto in precedenza, ogni nuovo aggiornamento deve essere scaricato e configurato dal sistema e anche i nodi devono essere aggiornati. È pertanto consigliabile affidare l’implementazione on-premise di Kubernetes solo a un team esperto.

Utilizzando servizi di gestione basati sul cloud, invece, il processo è molto più semplice, in quanto Kubernetes è già installato e il provider di servizi cloud mantiene tutti i nodi aggiornati con le funzionalità di sicurezza più recenti. Dal punto di vista del cluster, la maggior parte dei provider di servizi cloud consente all’utente di scegliere tra diverse versioni di K8s e offre anche la possibilità di eseguire l’aggiornamento a una nuova versione. Se da un lato questa opzione è più semplice, dall’altro però offre minore flessibilità.

Considerazioni finali

Visti i continui aggiornamenti e l’elevato numero di nuovi strumenti disponibili sul mercato, restare aggiornati e tenere sotto controllo le vulnerabilità può essere difficile. Le violazioni sono inevitabili. Kubernetes pone una sfida persino maggiore, in quanto non è un semplice strumento, ma piuttosto un insieme di strumenti per la gestione di macchine, reti e altri strumenti, pertanto è fondamentale che sia protetto.

Ma visto l’elevato numero di parti mobili, mantenere Kubernetes al sicuro non è un’impresa semplice, per cui assicuratevi di seguire queste linee guida:

• Analizzate le applicazioni in esecuzione su K8s per rilevare eventuali problemi di sicurezza.
• Limitate e controllate gli accessi.
• Assicuratevi di aver applicato patch con gli ultimi aggiornamenti di sicurezza e monitorate continuamente il cluster per risolvere immediatamente le interruzioni e mitigare i danni.

Le implementazioni on-premise rappresentano una sfida persino maggiore, in quanto richiedono hardware da gestire, automazioni da creare e un maggior numero di software da tenere aggiornati. Seguire le best practice discusse in questo articolo, tuttavia, può offrirvi un notevole vantaggio in termini di sicurezza e può aiutarvi a mantenere il vostro ambiente Kubernetes sicuro e attivo.

La piattaforma SentinelOne supporta macchine fisiche e virtuali, Docker, Kubernetes autogestito e Kubernetes gestito da provider di servizi cloud come AWS EKS. Per maggiori informazioni, richiedete una demo gratuita oggi stesso.