Sicurezza dei container: hardening delle immagini e protezione a runtime

I container includono il codice dell'applicazione e le relative dipendenze in unità isolate che condividono il kernel del sistema operativo host, a differenza delle VM, che includono un sistema operativo guest completo. Questa condivisione rende i container leggeri e veloci, ma introduce un modello di sicurezza diverso: una vulnerabilità di container escape potrebbe consentire a un attaccante di evadere dal container e accedere direttamente al kernel dell'host, compromettendo tutti gli altri container. La sicurezza dei container si concentra su tre livelli: l'image (ciò che contiene), il runtime (ciò che il container può fare durante l'esecuzione) e la piattaforma di orchestrazione (il modo in cui i container vengono gestiti).

Ogni pacchetto installato in un'immagine container rappresenta una potenziale superficie di attacco. Il principio delle immagini di base minimali consiste nel partire dalla base più piccola possibile: Alpine Linux (5 MB, con un numero minimo di pacchetti), immagini distroless (immagini di Google che contengono solo il runtime e l'applicazione, senza shell né gestore di pacchetti) oppure scratch (completamente vuota, per binari compilati staticamente). Un container privo di shell impedisce a un attaccante che abbia ottenuto l'esecuzione di codice di eseguire facilmente wget, curl o altri strumenti per ampliare l'attacco: un principio chiamato difesa tramite esposizione minima.

Per impostazione predefinita, i container Docker vengono eseguiti come root (UID 0). Se un attaccante sfrutta una vulnerabilità nell'applicazione containerizzata, ottiene privilegi root all'interno del container. Se il container condivide un volume o dispone di mount dell'host, root all'interno del container può equivalere a root sull'host. La soluzione è semplice: creare un utente dedicato nel Dockerfile e passare a tale utente con la direttiva USER prima del CMD/ENTRYPOINT finale. Molti strumenti di scansione della sicurezza dei container segnalano come finding qualsiasi immagine priva di un utente non-root.

I container immutabili sono container il cui filesystem non può essere modificato durante l'esecuzione. Abilitare --read-only in Docker (o readOnlyRootFilesystem: true in Kubernetes) impedisce agli attaccanti di scrivere malware sul disco, modificare file di configurazione o installare strumenti all'interno di un container in esecuzione. Le applicazioni che hanno realmente bisogno di scrivere dati (log, file temporanei) possono montare specifici volumi tmpfs per scritture effimere. I container immutabili applicano il principio secondo cui lo stato durante l'esecuzione dovrebbe provenire esclusivamente dall'immagine e dalla configurazione, non da modifiche apportate all'interno del container che aggirano la pipeline di sicurezza CI/CD.

Gli strumenti di scansione delle immagini dei container analizzano i pacchetti installati in un'immagine Docker confrontandoli con i database delle vulnerabilità (NVD, CVE) e segnalano le CVE note. Tra gli scanner più diffusi vi sono Trivy (Aqua Security, veloce e gratuito), Grype (Anchore), Snyk Container e AWS ECR image scanning. La scansione deve essere integrata nella pipeline CI/CD, in modo che qualsiasi immagine con CVE critiche o ad alta gravità interrompa la pipeline prima del push in un registry. Gli scanner dovrebbero inoltre verificare la presenza di segreti (chiavi API, password) inseriti accidentalmente nei layer dell'immagine.

Un errore comune e pericoloso consiste nell'inserire segreti (chiavi API, password del database, certificati TLS) nelle immagini Docker, ad esempio tramite variabili d'ambiente incorporate nell'immagine o file aggiunti con COPY. Questi segreti sono visibili a chiunque abbia accesso all'immagine, tramite docker history o estraendo i layer dell'immagine. Anche se un layer successivo elimina il file, questo rimane nella cronologia dell'immagine. I segreti devono essere iniettati a runtime tramite variabili d'ambiente provenienti da un secrets manager, Docker secrets o Kubernetes Secrets montati come volumi.

Gli strumenti di sicurezza a runtime monitorano il comportamento dei container mentre sono in esecuzione e segnalano o bloccano le attività anomale. Falco (progetto CNCF) si integra con il kernel Linux tramite eBPF o moduli del kernel per intercettare le chiamate di sistema e confrontarle con apposite regole. Ad esempio, una regola può generare un avviso se un container avvia una shell (execve('/bin/sh')), apre una connessione di rete su una porta imprevista o legge /etc/shadow. Questi indicatori comportamentali segnalano spesso un attacco in corso, anche se non è stata sfruttata alcuna CVE nota. Sysdig Secure e Aqua Security offrono piattaforme commerciali per la protezione a runtime.

Per impostazione predefinita, i container Docker eliminano molte capabilities Linux, ma ne conservano comunque più di quante la maggior parte delle applicazioni necessiti. Le capabilities suddividono i privilegi di root in unità distinte (ad esempio CAP_NET_ADMIN, CAP_SYS_ADMIN). La best practice consiste nell'eliminare tutte le capabilities e riaggiungere solo quelle necessarie con --cap-drop=ALL --cap-add=NET_BIND_SERVICE. I profili Seccomp (Secure Computing Mode) definiscono una whitelist delle chiamate di sistema che un container può effettuare: Docker include un profilo seccomp predefinito che blocca circa 44 syscall pericolose. I profili seccomp personalizzati per applicazioni specifiche possono limitare ulteriormente l'accesso, bloccando tutte le syscall che l'applicazione non utilizza legittimamente.

I registry di container (Docker Hub, AWS ECR, Google Artifact Registry) archiviano e distribuiscono le immagini. La protezione del registry comprende: abilitare la scansione delle vulnerabilità al push, limitare l'accesso in scrittura ai soli account di servizio CI/CD, abilitare la firma delle immagini tramite Sigstore/Cosign o Docker Content Trust (Notary), in modo che gli ambienti di runtime eseguano il pull solo di immagini firmate crittograficamente e provenienti da fonti attendibili, e configurare l'immutabilità delle immagini affinché i tag non possano essere sovrascritti. In questo modo si eliminano gli attacchi di mutazione dei tag, in cui un attaccante sostituisce un tag :latest attendibile con un'immagine dannosa.

Gli attaccanti che ottengono l'esecuzione di codice all'interno di un container possono tentare un container escape per raggiungere l'host. Le tecniche comuni includono: sfruttare i container privilegiati vulnerabili (--privileged garantisce un accesso quasi illimitato all'host), abusare dei socket Docker esposti (/var/run/docker.sock montato in un container garantisce l'accesso completo all'API Docker, inclusa la possibilità di creare container privilegiati) e sfruttare le vulnerabilità del kernel tramite capabilities non protette. Le difese consistono nel non utilizzare la modalità privilegiata salvo assoluta necessità, non montare mai il socket Docker nei container applicativi, mantenere aggiornato il kernel dell'host e usare gVisor o Kata Containers per i workload che richiedono un isolamento elevato.

Il Center for Internet Security (CIS) Docker Benchmark fornisce linee guida dettagliate per la configurazione sicura degli host e dei container Docker, riguardanti la configurazione del daemon, l'igiene delle immagini, le impostazioni del runtime dei container e i controlli di rete. Strumenti come Docker Bench for Security automatizzano i controlli di conformità rispetto al benchmark CIS, producendo un report con il punteggio degli elementi superati o non superati. Eseguire periodicamente questo benchmark e integrarlo nella CI/CD garantisce il rilevamento rapido delle deviazioni dalla configurazione di sicurezza prevista. Chi sostiene Security+ dovrebbe sapere che i CIS Benchmarks sono un riferimento primario per l'hardening dei sistemi operativi e delle piattaforme nel contesto dell'esame.

In questa lezione ha imparato che le immagini di base minimali e gli utenti non root riducono la superficie di attacco e il livello di privilegi dei workload containerizzati, che gli strumenti di protezione a runtime come Falco rilevano pattern anomali nelle syscall indicativi di attacchi in corso all'interno dei container e che è necessario non usare mai container privilegiati né montare il socket Docker nei container applicativi, poiché queste configurazioni consentono il container escape. Nel prossimo argomento esploreremo la sicurezza di Kubernetes, inclusi RBAC, policy di rete e standard di sicurezza dei pod.