¿Es una buena práctica hacer proxy de aplicaciones web desde contenedores de Docker?

1

La configuración actual es la siguiente:

  • Un servidor de producción (host) tiene solo unos pocos puertos abiertos, a saber, HTTP, HTTPS y puertos seguros para correo electrónico.
  • En el host hay un usuario sin privilegios que ejecuta un motor y contenedores de Docker.
  • Varias aplicaciones web se ejecutan en contenedores Docker, cada una se ejecuta en una red virtual con puente proporcionada por el tiempo de ejecución de Docker. Tienen puertos abiertos HTTP y HTTPS. Las aplicaciones se ejecutan en tecnología de servidor web arbitrario, como Apache 2.? o AKKA-HTTP.
  • Solo un contenedor "http-proxy" expone sus puertos (80, 443) al host. En este contenedor, un usuario sin privilegios está ejecutando un servidor Apache 2 protegido por mod que solo reenvía las solicitudes en función del dominio solicitado y las reenvía a uno de los contenedores de aplicaciones.
  • El servidor de correo se ejecuta en un contenedor Docker con un usuario sin privilegios que expone sus puertos al host.

Las preguntas son:

  1. ¿Hay algún inconveniente en este modelo?
  2. ¿Cómo sería más seguro?
  3. ¿Qué tan expuestos están los contenedores de aplicaciones a los ataques?
  4. ¿Existen consideraciones de seguridad con respecto a Docker?

¡Gracias!

    
pregunta Dyin 24.01.2017 - 18:13
fuente

3 respuestas

2
  

¿Hay algún inconveniente en este modelo?

No veo ningún inconveniente inmediato, a excepción de los gastos generales y el uso del espacio en disco si implementa sus aplicaciones de forma continuada sin mantener controlados los volúmenes. Tenga en cuenta que "Un volumen de datos de Docker persiste después de eliminar un contenedor". vea la documentación de Docker .

Sin embargo, puede haber algunos inconvenientes a largo plazo. Por ejemplo: ya que ejecuta esto en producción, ¿con qué frecuencia aplica actualizaciones de seguridad a sus contenedores? Dado que las imágenes de la ventana acoplable se han retirado un paso del flujo ascendente, es posible que los parches de seguridad no se implementen lo suficientemente rápido. ¿Con qué frecuencia comprueba las actualizaciones de sus contenedores y los vuelve a implementar?

Además, si uno de sus contenedores se genera, ¿filtra las conexiones salientes? ¿Qué pasa si un exploit trivial en tu aplicación lo hace parte de una botnet?

  

¿Cómo sería más seguro?

Depende. ¿Monta el / proc o / sys del host en algún contenedor? Si es así, tenga cuidado con este tipo de ataques (y busque 'Escaparate' para una lectura entretenida)

  

¿Qué tan expuestos están los contenedores de aplicaciones a los ataques?

Para los ataques que vienen de fuera del perímetro de su red, están tan expuestos como si las aplicaciones se estuvieran ejecutando como procesos UNIX normales en un sistema.

Curiosamente, para los ataques que vienen de otros contenedores, en realidad está aumentando sus superficies de ataque : asumiendo que algunos contenedores pueden ver otros (por ejemplo, el servidor web puede ver el servidor db, o un servidor de registro, etc.) ) debe asegurarse de que cada contenedor no ejecute servicios adicionales y lo más importante es mantenerlos actualizados .

  

¿Hay alguna consideración de seguridad con respecto a Docker?

Sí, pero la pregunta es demasiado amplia. Hay escapes de la ventana acoplable debido a una mala gestión del contenedor (por ejemplo, montaje /proc ). Hay potenciales explotaciones portuarias. Existe la configuración errónea ocasional que permite a los usuarios locales atacarla. Si está buscando una bala de plata para desplegar y olvidar, se sentirá decepcionado ...

    
respondido por el lorenzog 24.01.2017 - 23:34
fuente
1

Ejecutar un proxy ligero frente a un servidor web / de aplicaciones es una buena idea, y aunque soy un gran fan de apache httpd, creo que es una mala elección como proxy; está lejos de ser liviano, por lo que su arquitectura no soportará grandes volúmenes de tráfico. Yo recomendaría nginx o ATS o posiblemente barniz. Pero no hay un puerto ATS ni de barniz de modsecurity y la versión nginx no es tan estable como el módulo apache. Existen WAF alternativos para los tres; si son apropiados para usted, depende de lo que esté haciendo con su WAF.

Como lorenzog dice que las imágenes de la ventana acoplable tienden a demorarse en la publicación de parches. No ha mencionado cómo se propone abordar la configuración, la implementación y la aplicación de parches a los servidores.

Todos sus demonios deben ejecutarse como usuarios sin privilegios, y todas las aplicaciones estándar en las distribuciones de Linux ejecutan como un usuario no root, pero la mayoría de los demonios comenzarán como root para capturar un puerto de bajo número. Puede iniciarlo como no root en un puerto de número alto y usar iptables para realizar la traducción de puertos o usar capacidades de linux para delegar permisos para vincular un puerto de número bajo o hacer la asignación de puertos en otro lugar. Pero tenga en cuenta que esto puede implicar retoques con los archivos de configuración, lo que puede generar conflictos con los parches de distribución.

    
respondido por el symcbean 25.01.2017 - 01:08
fuente
0

Su configuración aísla suficientemente los diferentes entornos para que una infracción en un contenedor no permita el acceso a otro contenedor.

Una cosa que debe comprobar es que las aplicaciones web no se ejecutan como root en los contenedores de la ventana acoplable. El código de la aplicación web debe ejecutarse como un usuario normal.

    
respondido por el Sjoerd 24.01.2017 - 20:44
fuente

Lea otras preguntas en las etiquetas