Contenedores Docker, variables de entorno y bases de datos

Navega tus respuestas
6

Las variables de entorno (establecidas con -e ) en los contenedores de Docker están disponibles para cada contenedor vinculado.

Considere un caso de uso típico, una base de datos. La imagen de MySQL oficial da este comando de ejemplo: 

docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag

Acabo de poner mi contraseña como texto sin formato dentro de una variable de entorno. Para estar seguro, necesita docker inspect para verlo, y si puede hacerlo, eso significa que tiene acceso de root al sistema operativo host, que es el juego final de todos modos ... Así que sigamos adelante.

Ahora quiero configurar un wiki también. Vamos a usar esta imagen de MediaWiki . También necesitamos vincular la base de datos: 

docker run --name some-mediawiki --link some-mysql:mysql -d synctree/mediawiki

¡Vaya! Cuando vinculé some-mysql , las variables de entorno se propagaron y ahora some-mediawiki también puede ver MYSQL_ROOT_PASSWORD . Esto significa que si alguien comprometiera la wiki, también podría encontrar la contraseña de root y luego ingresar a la base de datos a través del enlace.

Los desarrolladores de Docker han discutido sobre esto, y la conclusión es que las variables de entorno nunca fueron diseñadas para compartir secretos de manera segura, y es un error usarlas de esta manera. Sin embargo, todo el tiempo veo imágenes que pasan la contraseña como una variable de entorno, incluso muchas imágenes de bases de datos oficiales hacen esto. ¿Por qué?

    
pregunta Superbest 12.08.2015 - 23:27
fuente

2 respuestas

2

Una respuesta clara a su pregunta solo puede provenir de los mantenedores de las imágenes individuales que están "mal" al usar esta función, sin embargo, algunas explicaciones posibles son

  • No son conscientes de los riesgos. Docker es una tecnología relativamente nueva para mucha gente y la "mejor práctica" no siempre es clara para todos, aunque los desarrolladores de docker han hecho un gran esfuerzo en este sentido con cosas como la guía CIS
  • Son conscientes de los riesgos, pero han decidido que no es un problema grave para su arquitectura particular. Este puede ser el caso, por ejemplo, cuando otros aspectos del sistema significan que los contenedores vinculados deben confiar el uno en el otro, por lo que el compromiso de un contenedor conduce fácilmente al compromiso del otro, independientemente de la distribución de variables del entorno.
  • Son conscientes de los riesgos, pero carecen de una mejor alternativa. En última instancia, la administración de contraseñas de servicio es un problema difícil de resolver bien y, dependiendo del software que se use en los contenedores, puede que no haya una opción que los mantenedores consideren que funcionaría tan bien como usar variables de entorno.
respondido por el Rоry McCune 13.08.2015 - 10:09
fuente
0

Si no está en una máquina multitenant, esto no debería ser un problema. Por otro lado, el compromiso de un servicio significa que ambos se ven afectados. Esta es la razón principal para las configuraciones de múltiples máquinas, ya sea con una vm separada o microservicios en otro lugar.

    
respondido por el m2kin2 11.12.2015 - 15:09
fuente

Lea otras preguntas en las etiquetas

Malware: ¿extraer claves privadas de una tarjeta inteligente? Información de identificación personal en el parámetro de consulta para el servicio REST de Tomcat