Attualità

Kubernetes: la sicurezza va a rilento e potrebbe diventare un problema

I microservizi sono considerati il futuro (e il presente) della modernizzazione a livello di applicazioni. Concentrandosi sulle prestazioni, però, si rischia di trascurare l’aspetto della sicurezza. Un errore che non ci possiamo permettere

Pubblicato il 31 Mag 2023

cybersecurity

Se l’uso della containerizzazione sta avendo così tanto riscontro, senza dubbio il merito è anche di Kubernetes. Questa piattaforma Open Source di orchestrazione, infatti, sta conoscendo una crescita considerevole, attestandosi in pochi anni fra le soluzioni più importanti per questo settore. Tuttavia, c’è un problema di fondo, che in qualche modo replica un copione già visto in numerosi altri contesti. Il tasso di adozione esplosivo non è seguito da altrettante cautele in termini di sicurezza.

La sicurezza su Kubernetes secondo Red Hat

Fra le aziende più attive nel seguire lo sviluppo di questa piattaforma c’è senza dubbio Red Hat, che nel suo recente rapporto The State of Kubernetes Security for 2023 mostra numeri non proprio rassicuranti. Fra quelli in evidenza scopriamo che il 38% degli operatori ritengono inadeguati gli investimenti in sicurezza della containerizzazione e che addirittura il 67% ha visto rallentarne l’adozione a causa di dubbi legati alla sicurezza. Per parlare di questo fenomeno, e delle possibili vie di uscita per il futuro, abbiamo raggiunto Natale Vinto, Head of Developer Advocacy in Red Hat, al quale abbiamo chiesto prima di tutto se nella gestione della sicurezza in Kubernetes ci sia qualche segnale di maturità.

“Sicuramente era possibile usare meglio i processi per la gestione della sicurezza fin dall’inizio. Kubernetes ha una grandissima community, per esempio su GitHub, e ha il merito di avere reso omogeneo il luogo dove far atterrare le applicazioni. Ora provider e vendor si stanno industriando per la sicurezza, anche se non tutti la prendono in considerazione” ricorda in apertura Vinto. “I processi, per esempio quelli legati alla sicurezza, sono indipendenti dalla tecnologia e oggi abbiamo abbastanza conoscenze pregresse per applicarli anche a nuovi contesti”. Spesso però nel mondo reale le logiche sono più complesse e l’adozione di buone pratiche, viene considerata (a torto) residuale.

Implementare la sicurezza dalle fondamenta

Non ci sono dubbi sul fatto che gestire la sicurezza nel contesto dei container sia un lavoro complesso, in virtù dei numerosi layer in gioco. Esattamente come nella virtualizzazione più tradizionale, infatti, sussiste il problema di dover gestire la sicurezza fra macchina host e i diversi guest (i container, in questo caso).

“Red Hat, nella sua soluzione OpenShift – ci spiega Vinto – lo fa in modo strutturale, a partire dal kernel, che prevede la funzionalità SELinux attivata di default”. Questo modulo di sicurezza permette di monitorare il controllo degli accessi a basso livello con una serie di policy aggiuntive. In alcuni casi permette una mitigazione degli attacchi zero day perché disabilita alcune funzioni critiche. Red Hat, ci ricorda, lo abilita e lo evangelizza, permettendone l’abilitazione anche nei container. In questo modo è possibile combinare le funzionalità di SELinux di host e guest, orchestrandole per migliorare la sicurezza.

Insomma, è necessario che l’approccio alla sicurezza sia esteso a tutta la catena, quindi non solo agli host e non solo al livello più alto, cioè alle App. Per dare seguito a questa filosofia, Red Hat ha creato, per esempio, le Universal Base Image, immagini da utilizzare come base per la creazione di container caratterizzate da un elevato livello di sicurezza e che permettono una migliore simbiosi con l’host per gestirla.

Insomma, secondo Red Hat la sicurezza parte dalla progettazione: lo testimoniano funzionalità di OpenShift come il Security Context Constraints.

La sicurezza fra bisogni e budget

Quando si parta di sicurezza IT, anche in termini generali, il problema degli investimenti inadeguati emerge sempre. Ma investimenti inadeguati conducono a incidenti di sicurezza, che tolgono risorse alla pianificazione. Abbiamo provato a chiedere a Vinto quale potrebbe essere una strategia per uscire da questo circolo vizioso.

“Prima di tutto è necessario fare investimenti più mirati, capire dove investire per non disperdere le risorse. Per esempio, l’automazione può aiutare a migliorare la sicurezza e a ridurre i costi. Aumentare la ripetibilità delle operazioni, per esempio, è un buon modo per liberare risorse. Un buon punto di partenza può essere quello di collegare i tool interni di Kubernetes che permettono di automatizzare una parte della sicurezza”.

Usare meglio le funzionalità già previste è un buon punto di partenza, che però si scontra con una caratteristica del contesto di Kubernetes, a livello di community. “Kubernetes è un ambiente molto aperto, a volte mancano le piste opinionate, qualcuno che guidi le buone pratiche. Manca un manifesto unitario sulla sicurezza: pur essendoci un gruppo molto attivo che se ne occupa, i documenti esistenti sono tutti community based”. La scelta per chi voglia seguire un percorso di buone pratiche può essere quello di seguire la blue print di un vendor. Red Hat, per esempio, ha creato la propria.

Proteggere la filiera

Nel rapporto The State of Kubernetes Security for 2023 c’è un riferimento che merita una riflessione importante, al fatto che i problemi di sicurezza su Kubernetes si possono trasferire all’intera filiera. Abbiamo chiesto a Vinto di spiegarne meglio i motivi.

“Il tema è molto legato al Software development lifecycle: per creare una filiera sicura, bisogna sapere, per esempio, che tipo di software si usa, quali sono le dipendenze utilizzate e come queste sono organizzate, a loro volta, per la sicurezza”. Serve una visione olistica ma soprattutto, ancora una volta, una pianificazione. Oggi è possibile partire dal codice e arrivare all’inserimento in una immagine per container avendo tutto firmato attraverso chiavi pubbliche, che garantiscono un maggiore livello di sicurezza. Così come è possibile arrivare ad effettuare una scansione delle vulnerabilità a tutti i livelli e su tutti gli ambienti, dallo sviluppo alla produzione.

Red Hat ha un nome per questo: secure software supply chain, per la quale mette a disposizione i suoi strumenti di controllo, check sulle firme e sulle vulnerabilità, in un contesto aperto. OpenShift, per esempio, valida tool di terze parti per poter estendere il processo di messa in sicurezza della filiera a tutti gli attori del mercato.

Un cambiamento culturale

In conclusione, torna un tema importantissimo: le aziende hanno senza dubbio bisogno di cambiare approccio culturale. Un progetto complesso come quello dell’adozione di sistemi di containerizzazione funziona se le persone sono ben formate. La formazione svolge un ruolo fondamentale, anche in contesto di contingenza. Ricorrere ad acceleratori come i Red Hat Open Innovation Lab, che permettano di mettere in piedi il progetto, con una guidance, in tempi rapidi, possono aiutare le aziende a ottenere risultati migliori e avviare processi virtuosi.

Vinto aggiunge: “Integrare la sicurezza nei flussi di lavoro di sviluppo è fondamentale per supportare la sicurezza end-to-end e automatizzata, e siamo lieti di constatare che quasi la metà degli intervistati ha già un’iniziativa DevSecOps in fase avanzata”.

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Articoli correlati

Articolo 1 di 4