Pasar las claves secretas de forma segura a los contenedores de la ventana acoplable

32

Quiero pasar un valor secreto que necesita una aplicación que se ejecuta en un contenedor Docker. Este contenedor en particular es de corta duración: se inicia, ejecuta un comando y luego termina.

Método 1: pase el valor como una variable de entorno a través de la línea de comandos al iniciar el contenedor (Docker lo admite como un argumento de línea de comandos para iniciar un contenedor). Siento que esto es malo ya que el comando aparecerá en las listas de proceso (con la clave y todas) en la máquina host que inició el contenedor de la ventana acoplable.

Método 2: Pase el valor como una variable env a través de un archivo de variable env. Esto resuelve el problema de la lista de procesos, pero la ejecución de docker info en el contenedor en ejecución desde el host muestra una lista de todas las variables de entorno establecidas para ese contenedor. Esto me hace creer que Docker está almacenando estos en algún lugar del disco en el host que no es seguro (ya que agregar una nueva variable de entorno en el contenedor en ejecución no actualiza esta lista, no debe estar leyendo directamente en tiempo real).

En general, siento que las variables de entorno no son adecuadas para almacenar datos secretos de forma segura (aunque solo sea temporalmente), pero no tengo el conocimiento suficiente para respaldar este pensamiento.

¿Qué es un método seguro para pasar datos secretos a un contenedor?

    
pregunta Anthony Kraft 16.10.2014 - 04:11
fuente

2 respuestas

9

Las variables de entorno son la mejor manera de hacer esto, específicamente el método 2. Docker, de forma predeterminada, no permite que lo ejecuten otros usuarios que no sean root. El acceso al zócalo está prohibido. Yo diría que el método 2 es razonablemente seguro, ya que fuera de la caja si un atacante tiene acceso de root (y puede hurgar en los contenedores de su docker) ya está en malas condiciones.

Dos notas de seguridad de Docker en general. Tenga mucho cuidado al habilitar la API, ya que por defecto no hay encriptación ni autenticación. Tienen una forma de usar certificados y TLS que documentaron, pero proceden con precaución.

Además, si es posible, habilite SELinux en su servidor. Las versiones más nuevas pueden ver los contenedores de la ventana acoplable y crear automáticamente contextos de seguridad para cada uno. Esto evita que un compromiso del contenedor se mueva fácilmente hacia el host. De forma predeterminada, la ventana acoplable se ejecuta como usuario root, e incluso con la directiva USER, sigue interactuando directamente con el kernel a diferencia de una VM. Esto expone al host a cualquier vulnerabilidad de privilegio local tan pronto como se comprometa un contenedor docker.

    
respondido por el theterribletrivium 16.10.2014 - 22:36
fuente
5

Los chicos de Docker han introducido recientemente su solución nativa para esto: enlace

El patrón de uso es:

$ echo "This is a secret" | docker secret create my_secret_data -
$ docker service  create --name="redis" --secret="my_secret_data" redis:alpine

El secreto sin cifrar se monta en el contenedor en un sistema de archivos en memoria en /run/secrets/<secret_name> .

Aunque esto solo es accesible dentro de swarm

Puede encontrar la documentación completa aquí: enlace

    
respondido por el grandrew 27.04.2017 - 13:21
fuente

Lea otras preguntas en las etiquetas