Container Security

La container security è la disciplina che si occupa di proteggere i container software — unità di esecuzione basate su Linux namespaces e cgroups, tipicamente gestiti tramite Docker e orchestrati con Kubernetes — lungo l’intero ciclo di vita: costruzione dell’immagine, distribuzione nel registry, deployment e runtime. I container hanno una superficie di attacco propria che differisce dalla sicurezza tradizionale delle VM: condividono il kernel dell’host (a differenza delle VM che hanno kernel separati), e la loro velocità di build/deploy incoraggia pratiche che introducono vulnerabilità se non gestite sistematicamente.

Il modello di sicurezza dei container

I container Linux si basano su tre meccanismi del kernel:

• Namespaces: isolano le risorse visibili al processo (PID, rete, filesystem, utenti). Un container vede solo i propri processi e la propria rete virtuale.
• cgroups: limitano le risorse usabili (CPU, memoria, I/O). Prevengono il DoS per esaurimento risorse.
• Seccomp / AppArmor / SELinux: filtrano le syscall permesse e le capability Linux del container.

L’isolamento è reale ma non equivalente a una VM: tutti i container sullo stesso host condividono il kernel. Una vulnerabilità di container escape (fuga dal container) porta all’host fisico con potenziale accesso a tutti gli altri container.

Vulnerabilità delle immagini

Le immagini Docker sono costruite su layer sovrapposti, spesso a partire da immagini base pubbliche che possono contenere pacchetti con CVE note. Un’immagine basata su ubuntu:20.04 di sei mesi fa porta con sé tutte le vulnerabilità non patchate di quei pacchetti.

Image scanning: strumenti come Trivy, Grype, Snyk Container e AWS ECR scanning analizzano le immagini alla ricerca di CVE nei pacchetti installati, prima del deployment. Integrati nella pipeline CI/CD, bloccano il deployment di immagini con vulnerabilità critiche.

Immagini minimali: usare immagini base distroless o Alpine riduce drasticamente la superficie — meno pacchetti, meno CVE potenziali, meno strumenti disponibili all’attaccante in caso di compromissione.

Segreti nelle immagini: non incorporare mai credenziali, chiavi API o certificati negli strati dell’immagine Docker. Anche se rimossi in un layer successivo, rimangono nel layer originale e sono estraibili con docker history. Usare secret management esterni (Kubernetes Secrets cifrati, Vault, AWS Secrets Manager).

Container escape

Un container escape è lo sfruttamento di una vulnerabilità che permette a un processo nel container di uscire dall’isolamento e operare con i privilegi dell’host. Vettori documentati:

• Container privilegiato (--privileged): disabilita praticamente tutto l’isolamento. Un container privilegiato ha accesso all’intero filesystem dell’host e può montare cgroups e dispositivi del kernel — equivale a root sull’host.
• Montaggio del socket Docker (-v /var/run/docker.sock:/var/run/docker.sock): permette al container di comunicare con il daemon Docker dell’host e lanciare nuovi container privilegiati.
• CVE kernel: vulnerabilità del kernel Linux sfruttabili dai namespace utente (es. runc CVE-2019-5736, che permetteva la sovrascrittura del binario runc dell’host).

Sicurezza in Kubernetes

In ambienti Kubernetes, la superficie si amplia ulteriormente:

RBAC mal configurato: l’API server di Kubernetes è il punto di controllo centrale. Account di servizio con permessi eccessivi (es. cluster-admin) permettono a un container compromesso di leggere secrets di altri namespace, creare pod privilegiati o esfiltrare configurazioni.

Pod Security Standards: definiscono tre profili (Privileged, Baseline, Restricted) che limitano le configurazioni pericolose nei pod. Il profilo Restricted vieta container privilegiati, root, capability aggiuntive e montaggio di path sensibili dell’host.

Network Policies: per default in Kubernetes ogni pod può comunicare con ogni altro pod del cluster. Le Network Policy (simili a firewall L3/L4) limitano il traffico est-ovest tra pod — il principio di segmentazione di rete applicato al cluster.

Secrets encryption at rest: i Kubernetes Secrets sono codificati in Base64 per default, non cifrati. Abilitare l’encryption at rest con KMS (AWS KMS, GCP Cloud KMS) cifra i secret nel database etcd.

Runtime security

Strumenti come Falco (CNCF) monitorano le syscall a runtime e generano alert quando un container esegue operazioni anomale — shell interattive in container che non dovrebbero averle, lettura di file sensibili, modifica dei binary di sistema. È l’equivalente di un IDS per il runtime dei container.