Il mercato della tecnologia dei container e degli orchestratori è estremamente interessante, spinto certamente da un maggiore interesse per il cloud, dai vantaggi di gestione delle infrastrutture e da una maggiore facilità di segregazione dei servizi con i relativi vantaggi anche in termini di sicurezza.
Un mercato globale che, tra l’altro, nel 2018 era di 270 milioni di dollari e si prevede che entro la fine del 2025 sarà di 2.980 milioni di dollari, crescendo ad un CAGR del 35% tra il 2019 e il 2025.
Partendo da una breve definizione di cosa sono i container e gli orchestratori, analizziamo dunque gli impatti e i vantaggi nell’impiego di questa tecnologia.
Indice degli argomenti
Cosa sono i container
L’idea alla base di questa tecnologia è apparsa per la prima volta nel 2000: questa consentiva la partizione di un sistema FreeBSD in sottosistemi, denominati jail, per arrivare poi all’introduzione dei Docker nel 2008.
I container li possiamo vedere oggi come un’immagine che consente di gestire ed eseguire dei processi in modo separato dal resto dell’infrastruttura-servizi, con un elevato beneficio in termini di standardizzazione e portabilità.
L’immagine di un container è quindi un pacchetto software che contiene tutto ciò che serve per eseguire l’applicazione desiderata.
Questo approccio ovviamente porta a disaccoppiare le dipendenze rispetto all’host, questo a vantaggio anche dei processi che intervengono nel rilascio dei prodotti nelle diverse catene tecnologiche e differenti ambienti (es. sviluppo, collaudo, produzione ecc.).
Iniziamo quindi a intuire i vantaggi di questa tecnologia, che possiamo individuare oltre a quanto già indicato, anche in termini di efficienza/performance (hanno necessità di meno risorse rispetto alle VM), scalabilità, sono difatti facilmente replicabili e molto veloci più veloci in avvio rispetto alle VM.
Cosa sono gli orchestratori di container
L’adozione crescente dei container porta con sé la necessità di avere una corretta ed efficace gestione di questi oggetti, si parla dunque di orchestratori. Questi consentono in generale la gestione ed una operatività efficace di questi oggetti a partire dalla delivery degli stessi, alla gestione del bilanciamento ed ottimizzazione dei carichi, rollout e rollback dei container, gestione degli aspetti di sicurezza (password, token, chiavi SSH).
In questo approfondimento punteremo la nostra attenzione su Kubernetes, spesso abbreviato in “K8s”. Questo è uno dei sistemi open-source di orchestrazione dei container più diffusi, pertanto diviene importante, per il suo ruolo strategico all’interno delle infrastrutture, mettere in sicurezza questa piattaforma.
L’utilizzo di queste tecnologie porta con sé un impatto (positivo) nel fornire benefici significativi in termini di livelli di segregazione tra le applicazioni, continuità dei servizi rispetto a processi di change (pianificati o meno), una maggiore flessibilità di rapidità di intervento. Al tempo stesso rappresentano anche un ulteriore livello di complessità tecnologica da conoscere, da gestire e da mettere in sicurezza.
Affrontiamo ora l’analisi di un documento della National Security Agency che illustra delle Linee Guida per la messa in sicurezza di K8s.
Container e orchestratori: messa in sicurezza di Kubernetes
L’interesse e la diffusione di queste soluzioni ha portato la National Security Agency a pubblicare ad Agosto 2021 un documento relativo Kubernetes Hardening Guidance.
Kubernetes consente la gestione tutti gli elementi che compongono un cluster, sia a livello di micro servizio che a livello di cluster. K8s, con il suo ruolo centrale di orchestratore, può diventare un elemento significativo in termini di interesse per azioni “malevoli”, si in termini di “furto di risorse”, informazioni o risorse computazionali utilizzate dai sistemi sottostanti, piuttosto che infine sottomettere l’ambiente stesso a servizio di attacchi verso altri ambienti proprio tramite il riuso delle risorse gestite.
Le principali minacce possono arrivare da:
- Supply Chain Risk: in generale tutti I rischi rappresentati dalla catena di persone e sistemi che possono interagire con il sistema o con i sistemi sottostanti (Livello Container/Application).
- Malicious Threat Actor: si sfruttano le vulnerabilità della piattaforma per ottenere una posizione privilegiata sfruttabile per fini malevoli. K8s utilizza per il colloquio con i diversi moduli delle API che un attore malevolo potrebbe sfruttare. In generale le componenti di K8s Control Plane possono essere sfruttabili in modo malevolo se non si proteggono adeguatamente gli accessi a questi oggetti.
- Insider Threat: siamo nel noto scenario delle minacce interne, chi opera sui sistemi e ha privilegi e conoscenze tali da poter costituire una minaccia.
Il documento della NSA definisce le linee guida ed indicazioni su come agire rispetto ai diversi ambiti del servizio al fine di aumentarne i livelli di sicurezza, a partire da quella dei Pod:
- Root: impedire l’esecuzione come Root dei container e delle applicazioni.
- Immutable container file systems: i container possono utilizzare in modo totale le risorse che hanno a disposizione. k8s può bloccare il File System di un container impedendo così molte attività post-exploitation (opzione da valutare ovviamente tenendo conto degli impatti sull’applicazione).
- Building secure container images: gestire adeguatamente il processo di inserimento e distribuzione di nuovi container, facendo in modo che le richieste siano “autorizzare” ed “autenticate”, pertanto coerenti con le politiche di sicurezza definite per l’ambiente.
- Pod Security Policies (PSP): consentono di definire le misure (minime) di sicurezza da adottare che tutti i Pod devono rispettare. Intervengono dunque nella creazione dei Pod supportando il blocco del processo se non conformi.
In generale vediamo come gli elementi essenziali da dover gestire per aumentare i livelli di sicurezza di una infrastruttura K8s sono:
- L’utilizzo di policy di separazione e segregazione della rete (i “namespace” sono uno degli strumenti che possono utilizzare in questo processo se impostati correttamente).
- Policy di utilizzo: oltre alle Netowork policy è possibile agire attraverso delle policy che limitano l’utilizzo delle risorse basate sempre su “namespace” o “nodo”.
- Hardening del Control Plane: abilitazione della cifratura TLS, strong authentication, disabilitare accessi a reti non sicure o necessarie, utilizzo delle policy RBAC (Role-based access control), proteggere i file di K8s da modifiche non autorizzare.
- Autenticazione ed Autorizzazione (di accesso): questi sono elementi essenziali per definire e controllare che ci siano solo accessi autorizzati alle risorse.
- Logging: la gestione corretta dei log è un elemento critico che consente di monitorare i servizi rilasciati e di governarne gli aspetti di sicurezza, K8s consente di abilitare un numeroso set di log: API request history, Performance metrics, Deployments, Resource consumption, Operating system calls, Protocols, permission changes, Network traffic, Pod scaling.
Cloud nazionale, tra tecnologie e obiettivi: le perplessità in tema di sicurezza dei dati
Conclusioni
Esiste ormai un’abbondante letteratura anche rispetto alla sicurezza dei container che, ovviamente, rappresentano l’oggetto in qualche misura da “proteggere” in ultimo per la continuità dei servizi e la sicurezza delle informazioni. Secondo Gartner (fonte: Docker Container Security 101: Risks and 33 Best Practices) dal 2020 oltre il 50% delle aziende gestirà container in produzione.
Secondo il Report Kubernetes adoption, security, and market trends report 2021 (Last Updated: July 14, 2021), circa il 94% del campione intervistato ha avuto un incidente di sicurezza nei precedenti 12 mesi relativo agli ambienti K8s.
La causa principale è da ricercarsi negli errori di configurazione (errore umano), questo in parte dovuto alla complessità che può avere l’implementazione di questa tecnologia.
