Container Security in produzione: Docker hardening che funziona

Gestisco oltre 50 container Docker in produzione attraverso i miei progetti - 17 per Valta, 12 per il Media Server, 11 per Mirage, 4 per il SOAR, piu tutti gli altri servizi. La sicurezza dei container in produzione e una preoccupazione quotidiana, non teorica. Le best practice di Docker security hardening che applico sono nate da problemi reali incontrati in produzione, non da checklist generiche.

Le regole non negoziabili

Mai root nei container. Ogni Dockerfile include un utente non privilegiato, e il container gira con quell'utente. Sembra banale, ma il 60% delle immagini Docker su Docker Hub gira come root. Un container compromesso che gira come root e un passo dal compromettere l'host. Uso user namespace remapping dove possibile per un ulteriore livello di isolamento.

Network isolation e secrets management

Ogni stack Docker ha la propria network bridge isolata. I container comunicano solo con chi devono comunicare - non c'e una rete flat dove tutti possono raggiungere tutti. Valta ha una rete per i collector, una per il backend, una per il frontend. I secret non vanno mai in variabili d'ambiente nel docker-compose (sono visibili con docker inspect). Uso Docker secrets o file montati in tmpfs con permessi restrittivi.

Altre regole che applico sistematicamente: immagini base minimali (alpine o distroless quando possibile), scan delle vulnerabilita sulle immagini prima del deploy (Trivy e il mio scanner di riferimento), resource limit su CPU e memoria per ogni container (un container che consuma tutta la RAM dell'host e un DoS), read-only filesystem dove possibile con mount specifici per le directory che richiedono scrittura. La sicurezza dei container e un processo continuo, non una configurazione one-time.