Container escape e sicurezza Docker: la vulnerabilità che molti team ignorano
Molti team trattano il container come una sandbox di sicurezza, ma per default non lo è. I vettori di escape su Docker: privileged mode, socket Docker montato, capability eccessive, namespace condivisi. Come un attaccante esce dal container verso l'host e l'hardening che lo previene: user namespace, capability minime, seccomp, read-only filesystem. Dalla prospettiva offensiva, per capire cosa difendere davvero in una infrastruttura containerizzata. Continua a leggere
Ultima modifica:
Un setup Docker per Laravel che funziona uguale in sviluppo e in produzione elimina la classe di bug che si manifestano solo sul server. Come containerizzare un'applicazione Laravel in modo pulito: ambiente di sviluppo riproducibile, Dockerfile multi-stage per la produzione, gestione separata di code, cache e asset, e i punti dove la configurazione dev e prod deve divergere. Pattern concreti, non un docker-compose copiato. 
Kubernetes è potente e, per la maggior parte delle PMI, prematuro. Quando ha davvero senso adottarlo (più team, scaling imprevedibile, deploy multipli al giorno) e quando è over-engineering che brucia budget e tempo. Se la decisione è sì, come iniziare in modo graduale: managed contro self-hosted, il percorso da Docker Compose a un cluster minimo, e i costi nascosti operativi da mettere in conto prima di partire. 
Containerizzare per la produzione è diverso dal farlo per lo sviluppo. Architettura Docker reale su Hetzner per un'applicazione PHP: Dockerfile multi-stage ottimizzato, gestione dei segreti, reverse proxy con TLS, e la transizione dalla singola VPS al piccolo cluster quando il carico cresce. Pattern operativi da campo, non teoria, con i tradeoff di costo e complessità dichiarati. 
Anthropic ha rilasciato in public beta il 1 aprile 2026 Claude Managed Agents - harness fully-managed con container configurabili, SSE streaming, zero DIY su E2B/Modal/Firecracker. Ma ha senso dismettere l'harness self-hosted con gVisor + seccomp + cap-drop che ho descritto nell'articolo sul sandboxing? Diagnosi punto per punto: TCO su scala PMI, superficie di attacco comparativa, vendor lock-in, compliance data sovereignty. Spoiler: la risposta è 'dipende da quattro variabili'. 
La build Docker di un'applicazione Laravel richiedeva 8 minuti ogni volta. Con l'ottimizzazione del layer caching (dipendenze Composer separate dal codice applicativo), multi-stage build e l'immagine finale Alpine, siamo scesi a 90 secondi. Il CI è diventato abbastanza veloce da aspettare il feedback. 
Datadog costa 30€ per host al mese. Per un'architettura con 8 microservizi PHP su Kubernetes, il costo era insostenibile. Ho migrato verso OpenTelemetry con collector auto-hosted e Jaeger come backend: zero costi aggiuntivi, stessa visibilità sulle trace distribuite tra i servizi. 
Quando hai dieci microservizi che si parlano tra loro, la gestione della sicurezza e dell'osservabilità a livello applicativo diventa insostenibile. Con Istio, mutual TLS tra tutti i servizi, distributed tracing con Jaeger e circuit breaker configurabili via YAML - senza cambiare una riga di codice PHP. 
I test con SQLite in memoria non trovano i bug che nascono dalle differenze tra SQLite e MySQL. Con Testcontainers per PHP, ogni test di integrazione ottiene un'istanza MySQL reale in un container Docker, azzerata tra le esecuzioni. Ho adottato questo approccio per un cliente e-commerce: i bug in staging sono scesi del 60%. 
Il 60% degli incidenti di sicurezza che gestisco derivano da software non aggiornato. Ho implementato un sistema di aggiornamento automatico dei container Docker con Watchtower configurato in modalità monitor, validazione tramite test di smoke test prima del deploy e rollback automatico in caso di health check fallito.