Un container breakout (o escape) è l'incubo dei container: un processo evade dall'isolamento e ottiene accesso all'host kernel sottostante – e quindi, potenzialmente, a tutti gli altri container e ai dati dell'host. È possibile perché i container, a differenza delle VM, condividono il kernel dell'host: "isolato" ha un asterisco.
Le cause tipiche:
- container privilegiato (
--privileged) o con capabilities eccessive – di fatto già mezzo fuori: è il caso più comune e più evitabile - mount pericolosi – montare il socket Docker,
/, o dispositivi dell'host dentro il container (il socket Docker montato = controllo dell'host, un errore diffusissimo) - vulnerabilità del runtime o del kernel – CVE in runc/containerd che permettono l'escape
- root nel container che, sfruttando una falla, diventa root sull'host
Le difese, a strati: non girare come root e niente privileged, container unprivileged (il default giusto), seccomp/gVisor per filtrare le syscall, kernel e runtime aggiornati (le CVE di escape si patchano), eBPF/Falco per rilevare i tentativi a runtime, e per i carichi non fidati il salto a un isolamento vero (micro-VM Kata o VM piene). La regola d'oro: più il carico è non fidato, più forte deve essere l'isolamento – un container va benissimo per il tuo codice, molto meno per eseguire quello di sconosciuti.