È buona prassi eseguire il proxy delle applicazioni Web dai contenitori Docker?

Are there any drawbacks to this model?

Non vedo alcun inconveniente immediato, ad eccezione dei costi generali e dell'utilizzo dello spazio su disco se si distribuiscono le applicazioni su base continuativa senza tenere sotto controllo i volumi. Tieni presente che "Un volume di dati del Docker persiste dopo che un contenitore è stato eliminato." consulta la documentazione del Docker .

Tuttavia, potrebbero esserci alcuni svantaggi a lungo termine. Ad esempio: dal momento che viene eseguito in produzione, con che frequenza si applicano gli aggiornamenti di sicurezza ai contenitori? Dato che le immagini del docker sono un passo rimosso dall'upstream, le patch di sicurezza potrebbero non essere distribuite abbastanza velocemente. Con quale frequenza controlli gli aggiornamenti dei tuoi contenitori e li ridistribuisci?

Inoltre, se uno dei tuoi contenitori ottiene 0wn, filtri le connessioni in uscita? Cosa succede se un exploit banale nella tua app lo rende parte di una botnet?

How would it be more secure?

Dipende. Montate l'host / proc o / sys in qualsiasi contenitore? In tal caso, fai attenzione a questo tipo di attacchi (e cerca 'docker escape' per una lettura divertente)

How exposed are the application-containers to attacks?

Per gli attacchi provenienti dal perimetro della rete, sono esposti come se le applicazioni fossero eseguite come normali processi UNIX su un sistema.

Stranamente, per gli attacchi provenienti da altri container, in realtà aumenta le superfici di attacco : supponendo che alcuni contenitori possano vederne altri (ad esempio, il server Web può vedere il server db o un server di registro e così via ) devi assicurarti che ciascun contenitore non esegua servizi extra e, soprattutto, mantenerli aggiornati .

Are there any security considerations regarding Docker?

Sì, ma la domanda è troppo ampia. Ci sono fughe di docker a causa della cattiva gestione del contenitore (ad esempio, il montaggio di /proc ). Esistono potenziali exploit di docker. Esiste l'occasionale configurazione errata che consente agli utenti locali di attaccarlo. Se stai cercando un proiettile d'argento da schierare e dimenticare, rimarrai deluso ...

L'esecuzione di un proxy leggero di fronte a un web / appserver è una buona idea e, sebbene io sia un grande fan dell'apache httpd, penso che sia una scelta sbagliata come proxy; è tutt'altro che leggero, quindi la tua architettura non farà fronte a volumi di traffico elevati. Consiglierei nginx o ATS o possibilmente vernice. Ma non c'è un ATS né una porta di modsecurity per la vernice e la versione di nginx non è stabile come il modulo apache. Ci sono WAF alternativi per tutti e tre - se sono appropriati per te dipende da cosa stai facendo con il tuo WAF.

Come lorenzog dice che le immagini docker tendono a non rilasciare patch. Non hai menzionato come ti proponi di affrontare la configurazione, la distribuzione e l'applicazione di patch dei server.

Tutti i tuoi demoni dovrebbero essere eseguiti come utenti non privilegiati e tutte le applicazioni standard sulle distribuzioni di Linux eseguono esegui come utente non root, ma la maggior parte dei daemon inizieranno come root per porta con numero basso. È possibile avviarlo come non root su una porta con un numero elevato e utilizzare iptables per eseguire la conversione delle porte o utilizzare le funzionalità di Linux per delegare l'autorizzazione a collegare una porta con un numero basso o eseguire il mapping delle porte altrove. Ma fai attenzione che questo possa comportare armeggiare con i file di configurazione che possono portare a conflitti con le patch di distribuzione.

La tua configurazione isola sufficientemente i diversi ambienti in modo che una violazione in un contenitore non dia accesso ad un altro contenitore.

Una cosa che dovresti controllare è che le applicazioni web non vengono eseguite come root all'interno dei container. Il codice dell'applicazione web deve essere eseguito come utente normale.