Progettare un’orchestrazione sicura dei container e una strategia per architetture containerizzate

Chi lavora con i container sa certamente che la loro orchestrazione è fondamentale per gestire workload containerizzati complessi.

Tuttavia, l’orchestrazione dei container non riguarda solo la loro gestione. Ha anche implicazioni vitali sulla sicurezza dei container. Aiutando a definire l’architettura basata su container e il modo in cui questi possono interagire tra loro, un buon approccio all’orchestrazione dei container consente di determinare quanto è sicuro l’ambiente in linea di principio e quando è probabile che una violazione si diffonda da un container all’intero cluster.

Ecco perché pianificare una strategia di orchestrazione sicura dei container e garantire la sicurezza delle architetture basate su container è fondamentale per la sicurezza dei container in generale. Questo articolo spiega come rendere sicuri i container a livello di orchestrazione e di architettura.

Orchestrazione dei container: una definizione

L’orchestrazione dei container è l’uso di strumenti automatici che consentono di gestire le operazioni richieste per eseguire i container.

Le piattaforme di orchestrazione dei container quali Kubernetes, Amazon ECS e Docker Swarm gestiscono in modo automatico azioni come decidere quali nodi in un cluster di server devono ospitare un dato container o riavviare i container in caso di arresto improvviso o mancata risposta. Dal momento che, se fosse svolto manualmente, questo lavoro richiederebbe moltissimo tempo, l’orchestrazione dei container sfrutta ambienti containerizzati su larga scala che includono decine, centinaia o addirittura migliaia di container diffusi in un grande numero di nodi.

Orchestrazione dei container e sicurezza

Lo scopo principale dell’orchestrazione dei container non è proteggere questi ultimi, e le piattaforme di orchestrazione non sono piattaforme di sicurezza. Molti dei requisiti di sicurezza degli ambienti basati su container sono gestiti da strumenti esterni che possono monitorare, rilevare e porre rimedio alle minacce.

Ciononostante, l’approccio che si adotta verso l’orchestrazione e la piattaforma scelta possono contribuire a definire l’intero profilo di sicurezza dei container.

Questo avviene perché la strategia di orchestrazione dei container svolge un ruolo fondamentale nel definire in che modo viene configurato l’ambiente containerizzato e quali tipi di architetture vengono utilizzate per inviare, utilizzare e gestire i container. Alcune strategie di orchestrazione e architetture basate su container sono più sicure di altre, e ciò dipende da fattori quali l’isolamento dei container e gli strumenti adottati per applicare i requisiti di sicurezza e governance nella gestione delle operazioni.

Progettare un’architettura sicura basata su container

Ci sono diverse considerazioni sulla sicurezza da soppesare quando si pianifica una strategia di orchestrazione e si progetta l’architettura di un ambiente.

Isolamento dei container

Il fattore in assoluto più importante da valutare è fino a che punto l’architettura e l’orchestrazione possano isolare i singoli container.

In generale, bisognerà trovare un equilibrio tra un isolamento eccessivo ed un isolamento scarso. Se i container sono completamente incapaci di condividere i dati con altri container sulla rete, di accedere agli stessi archivi di dati e di interagire in qualunque altro modo, sarà molto difficile utilizzare un’applicazione basata su di essi. Questo caso si verifica in particolare se l’applicazione utilizza un’architettura di microservizi in cui ogni microservizio viene eseguito nel proprio set di container e deve comunicare con altri container per far si che l’applicazione stessa funzioni.

Quando l’architettura dei container prevede un isolamento eccessivo, potrebbe essere difficile svolgere anche le attività di monitoraggio. In molti casi, gli strumenti di monitoraggio per ambienti containerizzati si basano su un’architettura detta “sidecar” nella quale un container che ospita un agente di monitoraggio viene eseguito accanto ai container dell’applicazione che deve monitorare. Se l’agente di monitoraggio non riesce a comunicare con gli altri container, non potrà raccogliere i registri e le metriche necessari per il monitoraggio.

D’altro canto, un isolamento scarso tra i container è un invito a nozze per i problemi di sicurezza. Sebbene assegnare permessi eccessivi a ciascun container non sarà la causa principale di una violazione della sicurezza, può aggravare seriamente le violazioni che avvengono per cause quali le vulnerabilità delle immagini dei container o un runtime o OS host non sicuri. È possibile prevenire questi rischi ricorrendo a controlli quali i contesti di protezione di Kubernetes, che limitano le azioni che i container sono autorizzati a svolgere.

Per trovare un equilibrio tra un isolamento eccessivo e un isolamento scarso, è bene applicare ai container il principio dei privilegi minimi. Bisogna assicurarsi che ciascun container abbia la possibilità di accedere alle risorse esterne di cui ha bisogno per svolgere i propri compiti e nulla più. Bisogna inoltre essere sicuri che i permessi vengano definiti in modo granulare e resistere alla tentazione di applicare contesti di protezione generici a un interno namespace o, ancora peggio, un intero cluster. I permessi granulari richiedono un maggiore sforzo di impostazione e di gestione, ma aumentano la sicurezza generale.

Runtime del container

Un runtime del container è il software che esegue i singoli container. Ne esistono molti, ad esempio containerd e runC. Adempiono tutti alla stessa funzione, ovvero eseguono i container, ma lo fanno in modi leggermente diversi.

Poiché non tutti gli strumenti di orchestrazione supportano tutti i runtime, la soluzione scelta definirà quali runtime del container potranno essere utilizzati. Per esempio, Kubernetes supporta la maggior parte dei runtime principali, mentre Amazon ECS supporta solo il runtime proprietario di Amazon.

In generale, nessun runtime è fondamentalmente più sicuro degli altri. Tutti i runtime di container più popolari hanno avuto la loro dose di vulnerabilità significative.

Tuttavia esistono alcuni progetti, ad esempio Kata Containers, che lavorano alla creazione di runtime intrinsecamente più sicuri apportando modifiche all’architettura di runtime stessa. Nel caso di Kata, ad esempio, i container non condividono un kernel, il che riduce notevolmente il rischio di attacchi con escalation dei privilegi e controlli degli accessi non sicuri. 

Scegliendo una strategia di orchestrazione dei container e una generale architettura containerizzata che consente di sfruttare al meglio i runtime più sicuri, si potranno ottenere alcuni vantaggi per la sicurezza non ancora disponibili nei runtime standard.

Supporto del sistema operativo

Oggi la maggior parte dei container gira su Linux, e di solito non importa quale sia la distribuzione Linux utilizzata per ospitarli. I container sono rimasti sempre gli stessi indipendentemente dall’OS Linux specifico o dalla configurazione che li ospita.

Detto questo, esistono anche container Windows per i team che vogliono utilizzare applicazioni containerizzate su Windows.

Il grado in cui le diverse soluzioni di orchestrazione supportano Windows è variabile. Kubernetes può gestire macchine Windows come nodi worker, ma non come nodi master. Ciò significa che è possibile orchestrare container Windows con Kubernetes, ma è necessario utilizzare strumenti basati su Linux per gestirli. Al contrario, Docker Swarm offre un supporto piuttosto completo ai container Windows.

Ma cosa ha a che fare il supporto dei sistemi operativi con la sicurezza dei container? In effetti non molto, ma è necessario sottolineare che utilizzare container Windows potrebbe essere più sicuro che utilizzare container Linux. La ragione sta nel fatto che i container Windows sono molto meno popolari, quindi sono un obiettivo molto meno comune per gli hacker. (È ironico che avvenga quasi il contrario parlando di desktop software, perché Linux in questo caso è un obiettivo molto meno frequente di Windows, ma molti container sono progettati per ospitare workload lato server e non applicazioni desktop.)

Dunque, se si desidera adottare una strategia di sicurezza pronta all’uso, è meglio considerare la creazione di un’architettura nella quale sia possibile utilizzare i container Windows.

Plugin di terze parti

Una considerazione chiave per progettare un’architettura di container sicura è quanto grande sarà la necessità di affidarsi a plugin di terze parti per creare l’ambiente nella sua totalità.

Alcune soluzioni di orchestrazione, come Kubernetes, sono progettate per essere estremamente modulari. Kubernetes sfrutta tipicamente plugin di progetti terzi per consentire la gestione dei dati, la gestione della rete e così via.

Altre soluzioni di orchestrazione, ad esempio Amazon ECS, adottano un’architettura molto meno modulare. Offrono alcuni strumenti predefiniti e poca possibilità di passare a soluzioni alternative.

Dal punto di vista della sicurezza, i plugin di terze parti sono croce e delizia. Da una parte, dei buoni plugin di terze parti possono consentire un migliore monitoraggio della sicurezza e una migliore visibilità rispetto agli strumenti nativi a disposizione.

D’altro canto, fare eccessivo affidamento su moduli di terzi si traduce in una maggiore potenziale esposizione a violazioni della sicurezza e a maggiori vulnerabilità da tracciare e gestire. Se si utilizzano solo gli strumenti nativi offerti dalla soluzione di orchestrazione, ci si espone solo alle vulnerabilità associate a tali strumenti. Se si utilizza Kubernetes con un lungo elenco di plugin esterni, è necessario gestire i rischi posti da ciascun plugin, oltre a dover proteggere Kubernetes.

In generale, i vantaggi di un’architettura modulare probabilmente superano i rischi. Ma se si preferisce la semplicità, è necessario affidarsi a una soluzione di orchestrazione meno modulare.

Progettare un’architettura containerizzata e una strategia di orchestrazione sicure per definizione non renderà nessuno immune alle minacce. Molti rischi potrebbero ancora mettere a repentaglio la sicurezza dell’ambiente attraverso immagini corrotte, violazioni a livello di OS e altre minacce simili. Tuttavia, un’architettura ed un’orchestrazione sicure consentiranno di isolare e correggere efficacemente le minacce quando si presentano.