Vogliamo evitare di includere "yum update" all'interno del dockerfiile, in quanto potrebbe generare un contenitore diverso in base a quando vengono create le immagini docker, ma ovviamente questo potrebbe comportare alcuni problemi di sicurezza se è necessario aggiornare un sistema di base. L'opzione migliore è davvero quella di avere un'immagine di sistema di base a livello di organizzazione e aggiornarla? Il problema sarebbe che richiedesse la ricostruzione e l'implementazione di tutte le applicazioni nell'intera organizzazione ogni volta che viene applicato un aggiornamento di sicurezza.Come posso gestire gli aggiornamenti di sicurezza nei miei contenitori docker?
Un alterativo che sembra un po 'fuori per me, sarebbe semplicemente ignorare gli aggiornamenti di sicurezza all'interno del contenitore e preoccuparsi solo di loro sul computer host. Qui il processo di pensiero sarebbe che per un attaccante entrare in un contenitore, ci sarebbe bisogno di una vulnerabilità sul computer host, un'altra vulnerabilità all'interno del motore di docker per entrare nel contenitore e quindi un'ulteriore vulnerabilità per sfruttare qualcosa all'interno del contenitore, che sembra una serie incredibilmente improbabile di eventi. Con l'introduzione di namespacing utente e profili seccomp, questo sembra ridurre ulteriormente il rischio.
In ogni caso, come posso gestire gli aggiornamenti di sicurezza all'interno dei container, con un impatto minimo sulla pipeline CI/CD o, idealmente, non dover ridistribuire l'intera infrastruttura ogni tanto?
dovresti leggere https://jpetazzo.github.io/2015/05/27/docker-images-vulnerabilities/ – user2915097
Questa è una risorsa fantastica! Grazie per l'articolo – jaumann
Un collaboratore mi ha inviato questo articolo questa mattina che sembra anche affrontare questo problema specifico, senza dover ridistribuire l'intera infrastruttura: https://www.hastexo.com/blogs/florian/2016/02/ 21/containers-just-because-everyone-else/#. VsmK2oUo_qD – jaumann