Container Security: che cos’è e come ottenerla

Le containerized applications sono sempre più diffuse, così aumenta la necessità di assicurare un'adeguata container security e la resilienza della supply chain software. In questo articolo elenchiamo i principali problemi di sicurezza dei container, per poi scoprire  quali sono le best practice utili per migliorarla.

Container security: il contesto

Il modo in cui le organizzazioni progettano e sviluppano il software è cambiato drasticamente negli ultimi anni. L’avvento delle architetture Cloud Native basate su microservizi e container ha cambiato la carte in tavola nel panorama IT. Oggi le applicazioni non sono più realizzate in maniera monolitica. Vengono bensì progettate basandosi su architetture a microservizi, secondo metodologie DevOps che non lascino la gestione operativa e la sicurezza a carico dei team di Operations a valle del ciclo di sviluppo.

Secondo Gartner il business delle piattaforme di container management raggiungerà i 944 milioni di dollari entro il 2024, partendo dalla cifra di 466 milioni stimata nel 2020. Questa crescita a doppia cifra evidenzia come la tecnologia dei container stia diventando man mano più capillare all’interno delle organizzazioni di qualsiasi dimensione (ecco ad esempio tre aziende che usano i container con successo). 

E con i containerized environments sempre più diffusi, la ricerca di soluzioni per migliorare la container security è passata in cima alla lista delle priorità dei team di sicurezza e devsecops. 

POTREBBE INTERESSARTI ANCHE 

l’articolo DevSecOps: Cybersecurity for Cloud Native Applications

Il white paper gratuito Guida alla Cloud Native Security 

Quali sono i problemi di sicurezza dei container

Quando si parla di sicurezza dei container è necessario ragionare con uno spettro che spazia dal semplice workload containerizzato, all’host che permette l’esecuzione di tale applicazione o microservizio. Con questa idea in mente, possiamo individuare i problemi di sicurezza principali a cui ogni organizzazione deve prestare attenzione, vediamoli uno per uno. 

Exploit del kernel

La condivisione del kernel della macchina host espone, in caso di un attacco che sfrutti un exploit del sistema operativo, tutti i container in esecuzione su di essa. Questo rischio è fortemente mitigato dalla classica virtualizzazione basata su hypervisor. Questa pratica infatti aggiunge un ulteriore livello prima di raggiungere gli applicativi in esecuzione. Per questo motivo, negli ambienti container è di fondamentale importanza il patching e l’hardening del sistema operativo host.

Attacchi Denial of Service (DoS)

Mettiamo il caso che un container abbia la possibilità di accedere a risorse illimitate in termini di capacità computazionale sul sistema host. Lo sfruttamento di una vulnerabilità o di un errore di programmazione dell’applicazione potrebbe monopolizzare le risorse computazionali disponibili, impedendo l’accesso di altri container a CPU e RAM e causando un attacco DoS. 

Per fortuna questo scenario può essere prevenuto configurando opportunamente l’allocazione di risorse dedicate ad ogni container e i principali parametri per abilitare una scalabilità orizzontale e verticale efficiente.

Container breakout

In caso di un bug presente all’interno di un’applicazione, un utente potrebbe scalare la piramide di privilegi sino al livello di root e ottenere accesso all'host. Malgrado la remota possibilità che questo evento accada, è necessario pianificare controlli periodici per validare la robustezza e la sicurezza dei container  in produzione.

Immagini infette

Le immagini standard dei container (build) possono essere infettate con malware o presentare vulnerabilità conosciute. È fondamentale mantenere sempre le immagini dei container aggiornate all’ultima versione disponibile. Inoltre, è bene effettuare dei controlli periodici sulla sicurezza di queste attraverso opportune scansioni.

Secrets compromessi

Durante l’esecuzione delle applicazioni il container accede periodicamente ad informazioni sensibili, chiavi API e credenziali. L’accesso indesiderato a queste informazioni comprometterebbe l’intera sicurezza dei servizi in esecuzione. 

Le conseguenze possono essere anche molto serie, per questo è utile conoscere le best practice di sicurezza, come quelle che vedremo tra un attimo. Prima però, c’è un altro concetto che è bene affrontare, quello di supply chain software.

Supply Chain Security Management 

La diffusione delle architetture Cloud Native ha determinato indirettamente una positiva crescita nell’adozione da parte di organizzazioni di ogni dimensione di software definito “open”. Il software open source (OSS)  lascia nelle mani della community la gestione, manutenzione ed evoluzione del software stesso,  prediligendo la collaborazione e gli spunti di miglioramento derivanti da feedback sul campo. 

L’utilizzo del software OSS da parte di aziende private è regolamentato e tutelato dalle tradizionali licenze (es: MIT, GNU GPL, ecc..). Tuttavia, la gestione dei pericoli che derivano dall’utilizzo di software open è demandata all’organizzazione. 

In questo contesto il concetto di Supply Chain Security Management è fondamentale, poiché in un ambiente “non governato” non è possibile controllare e supervisionare l’utilizzo di SDK, librerie o strumenti di terze parti. Diventa quindi necessario mettere in piedi un processo che garantisca l’immutabilità di una dipendenza o del software stesso, al fine di proteggere da una terza parte malintenzionata il perimetro della nostra infrastruttura.

Il metodo tradizionale di verifica dell’integrità del software è stato quello di verificare la firma digitale delle componenti dell’applicazione stessa. Lo stesso concetto è applicabile anche ai container, ma purtroppo non è sufficiente.

Secondo lo standard Supply Chain Level for Software Artifacts (SLSA), per raggiungere un livello di sicurezza della supply chain software adeguato, è necessario ragionare seguendo un approccio strutturato. Le quattro aree che caratterizzano questo approccio sono: Artifacts, Metadata e Attestation and Policies. Di cosa si tratta? Le abbiamo descritte di seguito.

• Artifacts: è il punto di partenza dell’analisi, ovvero l’output che il processo di Build produce, che può essere in diversi formati e di diverso tipo.
• Metadata: si tratta di dati strutturati e non, che descrivono gli artefatti software. Alcuni tipi di metadati devono essere considerati e verificati per validare la supply chain:
• Provenance Data; ovvero informazioni riguardanti il sistema di build che ha prodotto tale artefatto (machine identity, versione del compilatore, tool di CI/CD). Al momento non esiste uno standard per la documentazione di queste informazioni. Tuttavia, lo strumento in-toto della CNCF fornisce una serie di soluzioni  tecnologiche atte alla documentazione e verifica di queste informazioni. 
• Software Bill of Material (SBOM); ovvero la lista degli ingredienti (come framework, librerie, ecc.) utilizzate dall’applicazione. 
• Vulnerability Scan Report del codice containerizzato generati tramite sistemi di static code analysis.
• Attestations: sono i metadati prodotti, ma firmati digitalmente da una trusted identity. Strumenti come sigstore Cosign sono in grado di integrarsi con in-toto per associare le attestation ai container.
• Policies: meccanismi di verifica delle attestation per arrivare alla verifica finale della supply chain. Kubernetes, ad esempio, offre la capability di admission control che permette la verifica di un componente prima che questo venga installato all’interno del cluster. Strumenti come Kyverno sfruttano questa feature di Kubernetes per fornire un policy engine flessibile e configurabile.

6 best practice per la container security

Una volta descritte le principali sfide in termini di Container Security, arriviamo finalmente alle security best practice. Sono le raccomandazioni che, aggiunte ad un processo di verifica della supply chain software, permettono di tenere sotto controllo i nostri workload containerizzati e ridurre la superficie di attacco. Ne abbiamo individuate 6.

1. Sicurezza delle immagini

Una base image vulnerabile o compromessa è in grado di creare dei problemi a tutti i workload che la utilizzano come base. Per questo motivo, è sempre opportuno personalizzare il meno possibile la base image del container (ad esempio aggiungendo package esterni o librerie SDK). È bene utilizzare solamente immagini provenienti da fonti certificate e affidabili.

2. Sicurezza dei registry delle immagini

I registry sono i repository delle immagini del software containerizzato. Per mantenere questa tipologia di repository in sicurezza (sia da accessi indesiderati sia da contenuti vulnerabili) è possibile:

• Utilizzare policy di access control per limitare gli accessi/azioni.
• Usare la firma delle immagini dei container.
• Infine, servirsi della scansione continua delle immagini tramite plugin built-in al servizio di registry, per individuare vulnerabilità note all’interno delle base image utilizzate.

3. Messa in sicurezza della fase di deployment

Considerando un ambiente di produzione come target del nostro processo di deployment, questa fase può essere messa in sicurezza in diversi modi:

• Proteggendo fisicamente l’ambiente con firewall dedicati o con network security rules/groups.
• Utilizzando una piattaforma di orchestration che solitamente fornisce endpoint API sicuri e che supportano una security role-based.
• Con deployment "immutabili", ovvero reinizializzati in caso di cambiamenti.

4. Messa in sicurezza del runtime applicativo

È bene seguire le best practice tradizionali nel contesto di architetture Cloud Native, quali:

• Creare reti virtuali separate per workload di diversa natura e scollegate tra loro.
• Applicare il principio di least privilege sui canali di comunicazione/porte che ogni container può utilizzare, quindi la sola esposizione di porte strettamente necessarie.
• Utilizzare connessioni sicure (TLS based) per garantira la cifratura del traffico.

5. Utilizzo di container minimali e con un ciclo di vita breve

I container non sono fatti per essere utilizzati come “server”. La loro personalizzazione e i file contenuti al loro interno devono essere ridotti al minimo, mantenendo la natura effimera di ciascuna istanza di un container.

6. Monitoraggio dell’attività dei container

Quest'ultimo obiettivo si ottiene implementando meccanismi che garantiscono un approfondito livello di osservabilità sui seguenti componenti dell’infrastruttura containerizzata:

• Master nodes (nel caso di orchestration Kubernetes based);
• Container engines;
• Workloads running in containers;
• Containerized middleware and networking.

In breve

Per non incappare in problemi di sicurezza e garantire la container security, ogni organizzazione deve rivedere i propri processi di application lifecycle management. È necessario infondere all’interno di essi tutti i meccanismi di verifica, remediation e monitoraggio. 

Al fine di ridurre al minimo la potenziale superficie di attacco (attack surface), bisogna essere consapevoli dei principali problemi di sicurezza dei container, seguire un approccio strutturato per assicurare un livello di sicurezza adeguato alla supply chain software e applicare le best practice che abbiamo elencato in questo articolo.  

Infine, è indispensabile mettere in pratica il famoso shift-left, anticipare quindi le pratiche di sicurezza a partire dalle fasi iniziali del software development lifecycle. È un processo cardine della filosofia DevSecOps, che ti consigliamo di approfondire se non l’hai ancora fatto. Ne parliamo anche nell’ebook gratuito che abbiamo dedicato alla Cloud Native Security.