La sicurezza dei container software e dell’orchestratore Kubernetes non sono oggi delle opzioni nella conduzione dei moderni ambienti IT ibridi e distribuiti. Secondo Gartner, entro il 2025 ben l’85% delle imprese avrà in produzione software in container per almeno il 15% del proprio parco applicativo; installazioni dove Kubernetes farà da supporto alle esigenze di rapido deploy e di automazione della gestione. Benché Kubernetes non sia una novità, la rapida diffusione, concentrata in pochi anni, non ha aiutato il mercato a sviluppare componenti di sicurezza end-to-end complete, sfruttabili all’interno dei moderni processi DevSecOps. La frammentazione dei tool, unitamente alle lacune nella preparazione e nell’esperienza dei team, possono costituire una miscela esplosiva laddove si stanno frettolosamente modernizzando lo sviluppo e il deploy del software in chiave cloud-native.
Chi avvia nuovi sviluppi software in modalità cloud-native e a microservizi ha bisogno di team multidisciplinari per gestire lo sviluppo e le operation nella logica DevSecOps. “Team che uniscano competenze esistenti e nuove – spiega Paolo Marco Salvatore, CTO di Sinthera. A cominciare dagli skill per fare deploy in modo sicuro del codice sotto forma di collezioni d’immagini in container”. I moderni ambienti a container sono una costruzione a strati: “Dove la security va garantita a ogni livello, anche laddove non vi è controllo da parte del team aziendale”, precisa Salvatore. Per essere sicuri, i deploy in container devono rispettare le best practice dell’open container initiative (OCI). Vediamo di seguito i punti più importanti.
I controlli sul codice e la creazione d’immagini container sicure
Prima di compilare il codice e tradurlo in eseguibile serve il controllo della qualità del sorgente e delle vulnerabilità. “Questo si fa con gli strumenti SAST (Static Application Security Testing, ndr) e con i check sulle librerie richiamate”, spiega Salvatore. Segue quindi la fase di build, in cui il codice viene compilato per creare le unità di rilascio su Kubernetes. “Per questa fase non si parte mai da zero, ma si usano le immagini di base reperite da registri pubblici – precisa Salvatore –. Va da sé che queste immagini debbano essere prese dai repository di vendor affidabili, quindi, certificate e analizzate sotto il profilo della security”.
Le analisi di sicurezza sulle immagini vanno ripetute nel tempo e aggiornate man mano che si scoprono nuove minacce. “Per questo è necessario prevedere uno scanning periodico delle immagini presenti nel registro aziendale, usando appositi scanner di vulnerabilità aggiornati – precisa Salvatore –. Se il punteggio assegnato dallo scanner è alto, l’immagine offre un buon livello di sicurezza. Può essere quindi firmata per l’ulteriore protezione da alterazioni fraudolente”.
Garantire la sicurezza dei deploy dichiarativi su Kubernetes
Il momento del deploy richiede ulteriori cautele. Poiché Kubernetes fa deploy in modo dichiarativo (as-a-code, con linguaggi come YAML e il package manager Helm), è necessario estendere l’analisi anche a questa componente. “Le dichiarazioni vanno analizzate rispetto alle best practices – spiega Salvatore –. Questo per evitare, per esempio, che i container richiedano i privilegi di root o utilizzino ambienti d’esecuzione fragili rispetto alle esigenze”. Prima di sottoporre a Kubernetes le richieste di risorse per il deploy, serve quindi ricercare, in modo statico, queste specifiche vulnerabilità. Successivamente, al momento del deploy in test o in produzione si possono eseguire i controlli sulle vulnerabilità dinamiche. “Si tratta del Dynamic Application Security Testing (DAST) – continua Salvatore – realizzato, come farebbe un hacker, a partire dalla URL d’accesso all’applicazione, oppure dalle credenziali d’utente per sondare la sicurezza nei contesti d’uso”.
L’analisi dinamica integra l’analisi statica, tenendo conto delle caratteristiche dell’ambiente d’esecuzione. “L’analisi dinamica evidenzia i componenti che presentano vulnerabilità nel runtime – prosegue Salvatore –. Vulnerabilità affrontabili in vario modo: con il ritorno del codice alle fasi di correzione/ricodifica, modificando le policy dell’ambiente d’esecuzione, oppure inserendo un agente specifico che catturi e gestisca l’evento indesiderato”.
Come predisporre l’ambiente d’esecuzione sicuro per i container
La sicurezza del software in container richiede l’impiego di ambienti d’esecuzione protetti. Con Kubernetes sono critici i master-node, il database ETCD che consolida lo stato del cluster, gli admission controller che validano le richieste all’API server e lo schedulatore delle componenti applicative. “Per la sicurezza dell’insieme dei servizi Kubernetes serve rifarsi alle best practice – spiega Salvatore – Servono tool che, con scadenza periodica, controllino il cluster Kubernetes rispetto alle raccomandazioni del CIS (Center for Internet Security)”. Per una execution senza sorprese, serve inoltre la protezione dello strato di sistema operativo. L’ambiente runtime dev’essere conforme con le best practice del NIST, “indicate nel documento SP800-190, specifico per la compliance dei workload in ambienti containerizzati”, precisa Salvatore. Per i runtime si usano appositi ambienti leggeri, certificati dai vendor per supportare container come processi Linux: “Per l’isolamento e la sicurezza è quindi necessario applicare le best practices di Linux – continua Salvatore –, attraverso security policy su processi e applicazioni”. Di norma è impedito ad un container di accedere alle risorse del kernel (già ridotte negli ambienti ottimizzati), ma alcune, come il Security Computing Mode (seecomp) restano necessarie. “Si rimedia attraverso controlli più granulari a queste risorse, grazie a strumenti integrati nativamente nelle implementazioni di Kubernetes. “Resta in ogni caso importante installare funzioni antimalware sulle macchine Linux – precisa Salvatore -. Per esempio, strumenti EDR, progettati specificamente per il deploy come applicazioni Kubernetes, anche se si tratta di tool ancora poco maturi, che richiedono accesso a tutti i processi e privilegi di root”.
Come garantire la sicurezza dell’applicazione in container
La sicurezza delle applicazioni in container, al pari di quelle tradizionali, richiede validi controlli d’accesso degli utenti, realizzate con sistemi di sign-on standard, sfruttando gli eventuali backend LDAP e SAML per il single sign-on alle risorse. Allo stesso modo, serve gestire in modo controllato l’accesso alle risorse applicative realizzato da altri software via API. “Questo si realizza efficacemente attraverso l’utilizzo di un API gateway – spiega Salvatore –. Strumento che non solo aiuta a ottimizzare e mascherare gli accessi al software legacy, ma ne rende più solida la protezione”. L’API gateway aiuta quindi a controllare il traffico applicativo scambiato all’interno del cluster e, attraverso delle service-mesh, anche quello scambiato in entrata e in uscita dal cluster.
La checklist per la sicurezza di Kubernetes e dei container
La sicurezza dei container gestiti con Kubernetes dipende in larga misura dall’impiego delle best practices e da strumenti di monitoraggio specificamente progettati, molti dei quali reperibili in open source attraverso il progetto Kubernetes Prometheus. “Chi vuole implementare Kubernetes in modo sicuro ha bisogno di tool di auditing, di benchmarking CIS, di scanning per host e runtime secondo gli standard del NIST”, spiega Salvatore. Un lavoro che può essere semplificato con l’utilizzo di piattaforme d’automazione: “Come SCAP, uno strumento per vunerability assessment & response che aiuta a evidenziare le vulnerabilità e a verificare le compliance rispetto alle policy”, precisa Salvatore. Negli ambienti Kubernetes l’automazione aiuta moltissimo: “serve a inoltrare log ed eventi sui sistemi SIEM, per evidenziare le correlazioni significative in tema di security e a scatenare le azioni di remediation più efficaci”, conclude Salvatore.
