ping @ewindisch @diogomonica @NathanMcCauley Esto es solo un breve resumen. Siéntase libre de modificar / actualizar la descripción si cree que es necesario :)

Esta es información útil:

https://github.com/hashicorp/vault/issues/165

Como es este:

https://github.com/hashicorp/vault/issues/164

@ dreamcat4 hay algunos planes para implementar una "API de secretos" genérica, que le permitiría usar Vault, Keywiz o lo que sea con Docker, pero todo de la misma manera. Es solo un pensamiento inicial, por lo que requerirá investigación adicional.

@thaJeztah Sí Lo siento, no quiero restar valor a esos esfuerzos / discusión de ninguna manera. Estoy más pensando que tal vez también sea un ejercicio útil (como parte de ese proceso más largo y mientras estamos esperando) para ver qué tan lejos podemos llegar ahora mismo. Entonces les muestra más claramente a los demás los límites y deficiencias del proceso actual. Lo subyacente falta y es más necesario agregarlo para mejorar los secretos.

También vale la pena considerar las diferentes situaciones de secretos en tiempo de ejecución VS secretos en tiempo de compilación. Para lo cual también hay un área de superposición de áreas.

Y quizás también (para la ventana acoplable) también valga la pena considerar las limitaciones (pros / contras) entre las soluciones que proporcionan un mecanismo para manejar los secretos "en memoria". A diferencia de los métodos de secretos más basados ​​en archivos o los basados ​​en la red, por ejemplo, el servidor de secretos locales. Cuáles son los trucos actuales sobre la mesa (hasta la API de secretos adecuados). Esto puede ayudarnos a comprender parte del valor único (por ejemplo, de una seguridad más sólida) agregado por una API de secretos de Docker que de otra manera no se podría lograr mediante el uso de hacks en la parte superior del conjunto de funciones de Docker actual. Sin embargo, no soy un experto en seguridad. Por tanto, no puedo comentar esas cosas con tanta certeza.

@ dreamcat4 sí, tienes razón; a corto plazo, esos enlaces son realmente útiles.

También vale la pena considerar las diferentes situaciones de secretos en tiempo de ejecución VS secretos en tiempo de compilación. Para lo cual también hay un área de superposición de áreas.

¡Gracias! Creo que tenía eso en mi descripción original, debí haberme perdido en el proceso. Agregaré una bala

Sin embargo, no soy un experto en seguridad.

Yo tampoco, por eso hice "ping" a los mantenedores de seguridad; En mi opinión, esto debería ser algo escrito por ellos 😇

@thaJeztah gran resumen. Intentaré tocar esto cada vez que tenga tiempo.

@diogomonica aunque no está _directamente_ relacionado, existe una larga solicitud de función abierta para reenviar el agente de clave SSH durante la compilación; https://github.com/docker/docker/issues/6396 dada la cantidad de comentarios, sería bueno pensar en eso también. (Incluso si se toma una decisión sobre si puede / debe implementarse o no)

Suponiendo que pudieras montar volúmenes como un usuario que no sea root (sé que es imposible, pero hazme el favor), ¿sería ese un enfoque favorable para guardar secretos en contenedores?

Si es así, abogaría por una alternativa a -v host_dir:image_dir que espera el uso de un contenedor de solo datos y podría verse como -vc host_dir:image_dir (es decir, copia de volumen) donde el contenido de host_dir es copiado en el volumen image_dir en el contenedor de solo datos.

Entonces podríamos enfatizar un paradigma secure-data-only containers y permitir que esos volúmenes se cifren

Recientemente leí un buen artículo sobre eso de @jrslv donde él propone construir una imagen de

Entonces tienes dos Dockerfiles:

• Dockerfile.build (aquí simplemente copia todos tus secretos)
• Dockerfile.dist (este lo enviará al registro)

Ahora podemos construir nuestra distribución así:

# !/bin/sh
docker build -t hello-world-build -f Dockerfile.build .
docker run hello-world-build >build.tar.gz 
docker build -t hello-world -f Dockerfile.dist ^

Tus secretos están a salvo, ya que nunca presionas hello-world-build imagen.

Recomiendo leer el artículo de @jrslv para obtener más detalles http://resources.codeship.com/ebooks/continuous-integration-continuous-delivery-with-docker

¡Gracias por compartir @kepkin !
Acabo de terminar de leer el artículo. ¡Realmente conciso!

Me gusta la idea de exportar los archivos y cargarlos a través de un Dockerfile separado. Se siente como aplastar sin el problema de las "capas intermedias en el caché de compilación".

Sin embargo, estoy nervioso de que complicará el desarrollo y podría requerir un tercer Dockerfile por simplicidad.

@kepkin no te ADD ed a la imagen de producción, incluso si elimina el tarball, sin aplastarlo, se filtrará en alguna capa.

@TomasTomecek si entiendo el ejemplo correctamente, el tarball es _no_ las capas de imagen, sino solo el binario que se construyó dentro del contenedor de compilación. Ver por ejemplo; https://github.com/docker-library/hello-world/blob/master/update.sh (no hay secretos involucrados aquí, pero solo un ejemplo simple de un contenedor de compilación)

@TomasTomecek Estoy hablando de secretos para construir una imagen de Docker. Por ejemplo, debe pasar la clave ssh para verificar el código fuente de su repositorio privado de GitHub. Y el tarball solo contiene artefactos de compilación, pero no contiene la clave de GitHub.

@kepkin bien, ahora leo tu publicación de nuevo y puedo verla. Lo siento por eso. Desafortunadamente, no resuelve el problema cuando necesita secretos durante la implementación / construcción de la imagen de distribución (por ejemplo, buscar artefactos y autenticarse con el servicio de artefactos). Pero definitivamente es una buena solución para la separación entre el proceso de compilación y el proceso de lanzamiento.

@TomasTomecek, así es exactamente como busco artefactos.

En la imagen de Docker.build, descargo algunas dependencias binarias de la imagen de Amazon S3 que requieren clave y secreto de AWS. Después de recuperar y construir, creo un tarball con todo lo que necesito.

¿Existe un artículo canónico sobre las "mejores prácticas" (lo que se debe hacer en relación con lo que no se debe hacer) que recomendaría leer?

Vale la pena señalar (para cualquier otra persona como yo que se encuentre con esto) que Docker Compose tiene soporte para una opción env_file .

https://docs.docker.com/compose/compose-file/#env -file

@afeld docker también tiene esta característica, consulte http://docs.docker.com/engine/reference/commandline/run/#set -environment-variables-e-env-env-file pero esas env-vars todavía aparecen en los mismos lugares, así que no haga una diferencia con "fugas"

Me encontré con esta hoja de trucos: http://container-solutions.com/content/uploads/2015/06/15.06.15_DockerCheatSheet_A2.pdf

@kepkin así es como paso una clave ssh a docker build :

# serve the ssh private key once over http on a private port.
which ncat
if [ "$?" = "0" ]; then
  ncat -lp 8000 < $HOME/.ssh/id_rsa &
else
  nc -lp 8000 < $HOME/.ssh/id_rsa &
fi
nc_pid=$!
docker build --no-cache -t bob/app .
kill $nc_pid || true

y dentro del Dockerfile donde 172.17.0.1 es la IP de la puerta de enlace de la ventana acoplable:

RUN \
  mkdir -p /root/.ssh && \
  curl -s http://172.17.0.1:8000 > /root/.ssh/id_rsa && \
  chmod 600 /root/.ssh/id_rsa && chmod 700 /root/.ssh && \
  ssh-keyscan -t rsa,dsa github.com > ~/.ssh/known_hosts && \
  git clone --depth 1 --single-branch --branch prod [email protected]/app.git . && \
  npm i --production && \
  ... && \
  rm -rf /root/.npm /root/.node-gyp /root/.ssh

Si alguien tiene algo más simple, háganoslo saber.

Entonces, ¿cuál es el estado actual de esto?

Durante todo el verano hubo largas cadenas de conversaciones, lo que indica cuán extendida está esta preocupación. Esto se presentó en mayo y aún está abierto. Por ejemplo, ¿cómo puedo configurar la contraseña para Postgres?

@thaJeztah ¿Qué se puede hacer para avanzar en esto? Supongo que muchos ojos en diferentes proyectos posteriores están sobre este tema ... ej. https://github.com/rancher/rancher/issues/1269

Supongo que lo que se está haciendo aquí se mantiene _secreto_: D

Este es el mayor problema para nosotros al integrar Docker en nuestra pila de producción. ¿Existe una hoja de ruta u otro documento en algún lugar que indique algún progreso hacia esto?

Contenido relevante sobre este tema de k8s .

¿Qué piensa de esto como una forma potencial de abordar los secretos en tiempo de ejecución?
https://github.com/docker/docker/issues/19508

Siento que este problema se resolvería mejor concentrándose en algunos escenarios que deben ser compatibles y asegurándose de que haya un conjunto de instrucciones para cada uno. La forma en que se implementan es menos importante que si al final del proceso hay un conjunto coherente de características que se pueden combinar para satisfacer la necesidad.

Algunas de las que he visto referidas que parecen ser preocupaciones bastante legítimas incluyen:

Credenciales en tiempo de ejecución

• Información de usuario / contraseña coordinada entre dos contenedores que comparten un link
• La información es fácil de mantener fuera de su repositorio de git
• Es fácil mantener la información fuera de sus imágenes enviadas (¿qué pasa con los contenedores locales?)
• La información es fácil de mantener fuera de .bash_history (¿posiblemente un puente demasiado lejos?)
• Algunas aplicaciones esperan secretos como parte de un archivo de configuración que contiene otra información
• Algunas aplicaciones esperan secretos como variable de entorno
• Algunas aplicaciones permiten tanto

Cuando digo "fácil" me refiero a que existe un enfoque ergonómicamente sensato para manejar estas variables que protege al usuario de hacer algo incorrecto accidentalmente y activar un boletín de seguridad. El estrés de la experiencia a menudo se asocia con (léase: se le echa la culpa) a las herramientas involucradas en el error.

Credenciales en tiempo de construcción

• El proyecto se construye a partir de uno o más repositorios privados (por ejemplo: package.json permite git urls)
• El constructor puede estar detrás de un proxy protegido por contraseña
• El constructor puede estar usando una caché protegida con contraseña
• El usuario final solo se preocupa por una imagen funcional (es decir, usará pull o FROM, nunca docker build )
• La información es fácil de mantener fuera de sus imágenes enviadas

Primera edición:

Documentación de lo que se 'filtra' y no se 'filtra' en una imagen típica, contenedor

• ¿Qué archivos terminan en la imagen (solo COPIAR y AGREGAR? ¿Algo más?)
• ¿Qué retiene la máquina acoplable después de que se crea una imagen (especialmente boot2docker, pero qué pasa con los demás?)
• Cómo se capturan las variables de línea de comando y de entorno en la imagen y dónde se capturan
• Expectativas de los emisores de relaciones públicas con respecto a cambiar estos comportamientos

Siento que me estoy perdiendo un par de grandes aquí. ¿Alguien tiene algo que olvidé?

Claves API para cualquier servicio json.

Por ejemplo (y este es mi caso de uso real), la compilación de Docker compila un programa, la clave de API es necesaria para autenticarme y cargar los productos de compilación en Bintray.com.

@ dreamcat4 Podría estar muy lejos de lo que estás diciendo, pero aquí va:

¿Está hablando de usar imágenes de la ventana acoplable para compilaciones de implementación continua y enviar los artefactos de compilación a un archivo al final de una compilación exitosa? Personalmente, prefiero hacer esto más adelante (por ejemplo, un script posterior a la compilación en Jenkins), pero si está compilando de forma cruzada, podría ser un poco más complicado.

En mi mundo, el agente de compilación solo construye archivos binarios / archivos y los retiene como 'artefactos' del proceso de compilación, y algo más los envía a la infraestructura, etiqueta el repositorio de git, etc. Eso me da una copia de seguridad de emergencia de los artefactos si tengo un problema de producción y, digamos, mi npm, docker o repositorio de Artifactory no funciona para actualizaciones, o la red me falla.

El punto que estaba tratando de hacer era sobre el uso de claves API en general. Hay muchos servicios JSON / rest en línea diferentes y variados con los que un contenedor puede necesitar interactuar (ya sea en el tiempo de compilación o de ejecución) ... lo que requiere claves de API. No tiene que estar específicamente relacionado con la construcción.

@dreamcat oh, entonces ¿tokens de autenticación para puntos finales REST? ¿Crees que se manejan de manera sustancialmente diferente a, digamos, tu contraseña de postgres en un archivo conf, o los manejarías de manera similar?

Sí, creo que esos dos tipos deben considerarse de manera diferente en términos de evaluar su nivel mínimo básico de seguridad.

Los tokens de autenticación de API suelen ser:

• No son contraseñas
• Puede ser revocado
• Algunos (un subconjunto mucho menor) son de un solo uso, desechados. Y esencialmente invalidarlos.
• A menudo, los servicios de API tienen un alcance limitado a solo un subconjunto de funciones. (es decir, de solo lectura o solo puede desencadenar una acción específica).

Las contraseñas suelen ser / son:

• Para un acceso / control de cuenta más completo.
• Una vez comprometido, el atacante puede cambiarlo a otra cosa (bloqueo). U otra puerta trasera insertada (como la modificación de la base de datos de otras cuentas contenidas en la base de datos, en el caso de SQL).
• Al ser una contraseña, existe un riesgo sustancialmente mucho mayor de "reutilización de la misma contraseña" entre otras cuentas. Wheras, las claves de API tienden a ser siempre únicas y no se pueden usar para nada más.

Entonces eso no significa necesariamente que la solución de secretos _debe ser diferente_ para esos 2 tipos. Solo que el nivel de seguridad mínimo aceptable puede ser un poco más bajo para las claves de API.

Este nivel mínimo es importante si tener una seguridad sólida es más complejo / problemático de configurar. (lo que puede ser cierto aquí en el caso de los secretos de Docker, o no dependiendo de cuán factible / elegante sea la solución).

Y ocasionalmente, las claves API de las contraseñas pueden tener una seguridad más fuerte o más débil. Solo eso si no es posible una talla única para todos.

Por ejemplo, mi clave de API bintray: que se encuentra en el mismo repositorio .git que mi Dockerfile. Entonces, para mantenerlo seguro, se mantiene en un repositorio de git PRIVADO (al que se accede a través de SSH). Por lo tanto, obtener acceso a la clave API está relativamente bien protegido allí. Sin embargo, sin que la ventana acoplable tenga ninguna funcionalidad / protección de secretos incorporados, la imagen de la ventana acoplable integrada siempre incluye la clave API en texto sin formato. Por lo tanto, la imagen de compilación de Docker resultante debe mantenerse privada como el repositorio de git ... que tiene un efecto dominó (efecto no deseado) que nadie más puede ver públicamente / ver los registros de compilación / estado de compilación allí.

Ahora bien, eso no es ideal en muchos sentidos. Pero la solución general es bastante simple y realmente funciona (como en: ayer). Si hubiera un mecanismo mejor hecho en el futuro, consideraría cambiarlo. Pero no si ese mecanismo era significativamente más costoso / complejo de configurar que la solución actual que ya hice. Por lo tanto, la seguridad extrafuerte (aunque bienvenido) podría ser excesiva en el caso de solo 1 clave api. Lo que simplemente debe mantenerse fuera de la caché de capas de imágenes de la ventana acoplable con algún tipo de nueva opción NOCAHCE / comando Dockerfile.

Donde una contraseña necesita algo como vault o ansible-vault, y debe ser encriptada con otra contraseña u otro mecanismo de autenticación fuertemente seguro. (Lo que esperamos que no sea así, pero puede ser algo complejo de configurar).

Creo que un modelo cliente / servidor (como en la bóveda ) para administrar y simplificar (leer: auditoría, romper el vidrio) todas las cosas relacionadas con los secretos sería una buena práctica y cubriría la mayoría de los casos de uso, si la implementación se hiciera cuidadosamente. Personalmente, no soy un fanático de adoptar un enfoque no holístico, porque esta es una oportunidad para subir el listón en las mejores prácticas.

Esto implica un cliente de larga duración (responsabilidad de la persona que implementa una imagen) y / o un cliente en tiempo de construcción (responsabilidad del constructor). Quizás el primero podría transferirse al demonio de la ventana acoplable de alguna manera, que proporciona secretos autorizados en tiempo de ejecución.

De hecho, estoy totalmente de acuerdo con el comentario anterior. No es que no admire las formas creativas en las que la gente está resolviendo el problema, pero no creo que sea así como debe ser: intentemos pensar en una solución que pueda usarse tanto durante CI / D como en tiempo de ejecución. , además de tener en cuenta que los contenedores pueden ser orquestados por Mesos / Kubernetes, etc.

Bueno, creo que un poco de documentación aún sería útil aquí, ya que Docker presenta algunos problemas adicionales en el espacio del problema.

Parece que tal vez los chicos de Vault también están viendo esto desde el final. Creo que este boleto es el que hay que mirar:

https://github.com/hashicorp/vault/issues/165

Quizás esto es algo en lo que se podría colaborar.

@jdmarshall

Quizás esto es algo en lo que se podría colaborar.

+1

+1 Docker + Bóveda del Cuerpo Hashi

Lo siento, pero no me gusta cómo las soluciones se vuelven más complejas a medida que más personas colaboran. Hashi Corp Vault, por ejemplo, es una solución de servidor de cliente completa con almacenamiento de back-end cifrado. Eso agrega muchas más partes móviles. Estoy seguro de que algunos casos de uso exigen este nivel de complejidad, pero dudo que la mayoría lo haga. Si la solución de la competencia es utilizar variables de entorno de host, estoy bastante seguro de cuál acabará siendo utilizada por la mayoría de los desarrolladores.

Estoy buscando una solución que cubra el desarrollo (por ejemplo, claves de github) y la implementación (por ejemplo: claves de certificado nginx, credenciales de base de datos). No quiero contaminar el host con env vars o herramientas de compilación y, por supuesto, ningún secreto debería terminar en github (sin cifrar) o en un directorio de imágenes de Docker, incluso en uno privado.

@gittycat Estoy de acuerdo con usted en el sentido de que probablemente haya varios casos de uso distintos. Por lo que algunas de las soluciones deberían ser más sencillas que otras.

Sin embargo, ciertamente deberíamos querer evitar recurrir a las vars ENV.

Mi propia preferencia se inclina hacia la idea de que el almacenamiento de claves simple podría lograrse con algo parecido al mecianismo de "bóveda" de Ansible. Donde tiene un archivo de texto cifrado dentro del contexto de compilación (o fuentes fuera / junto al contexto de compilación). Luego, una clave de desbloqueo puede desbloquear las contraseñas de texto sin formato o claves API, etc. de ese archivo.

Solo digo eso después de usar la propia solución de "bóveda" de anisible. Lo cual es relativamente indoloro / simple. La bóveda de Hashicorp es más segura, pero también es más difícil de configurar y, en general, más compleja. Aunque no conozco ninguna razón técnica por la que no puedas usar eso debajo como backend (ocúltalo / simplifícalo detrás de una herramienta de línea de comandos orientada a la ventana acoplable).

Sugeriría el almacenamiento de archivos local porque evita la necesidad de configurar un servidor de almacenamiento de claves HTTP complejo y potencialmente poco confiable. El almacenamiento de secretos es una cuestión de seguridad, por lo que debería estar disponible para todos los usuarios, no solo para las empresas. Solo mi opinión de 2 centavos.

+1 a un backend de almacenamiento de archivos local, para casos de uso más avanzados, sin embargo, preferiría toda la potencia de una solución similar a Hashicorp Vault. Cuando hablamos de despliegue, en una organización, el argumento es que las personas que proporcionan y controlan secretos son otras personas que las que los utilizan. Esta es una medida de seguridad común para mantener el círculo de personas con poder de control limitado a ingenieros de seguridad muy confiables ...

No sé si esto es de alguna utilidad o funcionaría, pero aquí hay una sugerencia de campo izquierdo para resolver el caso en el que quiero inyectar un secreto en un contenedor en tiempo de ejecución (por ejemplo, una contraseña de postgres)

Si pudiera anular en docker run time el punto de entrada y configurarlo en un script de mi elección, por ejemplo, / sbin / get_secrets, que después de obtener secretos de un mecanismo de mi elección (por ejemplo, KMS), ejecutaría el punto de entrada original (convirtiéndose así en un simple contenedor cuyo único propósito era configurar variables de entorno con secretos DENTRO del contenedor. Dicho script podría suministrarse en tiempo de ejecución a través de un montaje de volumen. Tal mecanismo no implicaría que los secretos se escribieran nunca en el disco ( una de mis mascotas odia), o ser filtrados por docker (que no forma parte de la inspección de docker), pero garantizaría que solo existan dentro del entorno del proceso 1 dentro del contenedor, que mantiene el factor 12.

Ya puede hacer esto (creo) si el punto de entrada no se usa en los metadatos de la imagen, pero solo cmd, ya que el punto de entrada envuelve el comando. Como se mencionó, el contenedor podría montarse en tiempo de ejecución a través de un volmount. Si el punto de entrada ya se usa en los metadatos de la imagen, entonces creo que no puede lograr esto en este momento a menos que sea posible ver cuál era el punto de entrada original desde el interior del contenedor (no la anulación de la línea de cmd); no estoy seguro de si puede hacer eso o no .

Finalmente, creo que incluso sería posible proporcionar una clave cifrada de un solo uso a través de la inyección env var tradicional con la que el / sbin / get_secrets externo podría usar para solicitar los secretos reales (por ejemplo, la contraseña de postgres), agregando así una protección adicional en la ventana acoplable goteando la llave de un solo uso.

No puedo averiguar si esto es solo capas sobre capas, o si potencialmente resuelve el problema ... disculpas si solo es la primera.

@thaJeztah - Puedo confirmar que la solución que planteo arriba funciona, los secretos se manifiestan sin que los filtre la ventana acoplable, existen solo en la memoria para el proceso 1 a través de variables de entorno que son perfectamente compatibles con 12 factores, pero NO aparecen en docker api bajo docker inspect, o en cualquier otro lugar porque son específicos del proceso 1. No se requiere trabajo en la imagen para que esto funcione. En mi caso, compilé un binario estático de golang para buscar los secretos, por lo que podría montarse en volumen y anular el punto de entrada con esto, el binario emite un sys exec para transferir el control al punto de entrada definido por la imagen cuando haya terminado.

@gtmtech Interesante. Estaría interesado en saber cómo averiguó cuál era el punto de entrada original de su binario get secrets ..

Tal vez una carpeta de código de ejemplo haría que el enfoque fuera un poco más fácil de demostrar / comprender.

Código de ejemplo y escenarios de trabajo aquí @ dreamcat4 @kaos >

https://github.com/gtmtechltd/secret-squirrel

Puede que me equivoque, pero ¿por qué estos métodos complicados? Confío en los permisos de archivo estándar de Unix. Entregue todos los secretos a la ventana acoplable con -v /etc/secrets/docker1:/etc/secrets legible solo por root y luego hay un script que se ejecuta al inicio del contenedor como root, que pasa los secretos a los lugares apropiados para los programas relevantes (por ejemplo, apache config). Estos programas eliminan los permisos de root al inicio, por lo que si se piratean, no pueden leer el secreto de root más tarde. ¿Es este método que utilizo de alguna manera defectuoso?

Gracias @gtmtech :)
Desafortunadamente, no tenemos un punto de entrada estándar, ni puedo ejecutar la inspección de la ventana acoplable antes de la ejecución de la ventana acoplable de manera controlada. Pero me gusta su enfoque.

Puede que me equivoque, pero ¿por qué estos métodos complicados? Confío en los permisos de archivo estándar de Unix. Entregue todos los secretos a la ventana acoplable con -v / etc / secrets / docker1: / etc / secrets legible solo por root y luego hay un script que se ejecuta al inicio del contenedor como root, que pasa los secretos a los lugares apropiados para los programas relevantes (por ejemplo, apache config). Estos programas eliminan los permisos de root al inicio, por lo que si se piratean, no pueden leer el secreto de root más tarde. ¿Es este método que utilizo de alguna manera defectuoso?

Hola,
Estoy de acuerdo y creo que este enfoque ^^ debería recomendarse en general como la mejor forma de obtener secretos de RUNTIME. A menos que alguien más aquí tenga una fuerte objeción contra eso. Después de lo cual, posteriormente, también puede enumerar los casos de esquina restantes (en RUNTIME) que no están cubiertos por ese ^^.

Desafortunadamente, no puedo ver el despegue de la ardilla secreta porque es demasiado complicado para que la mayoría de las personas no técnicas lo aprendan y lo adopten como una estrategia popular.

Entonces eso se va (probablemente ya lo hayas adivinado) ...
¡Secretos a la hora de construir!

¡Pero creo que eso es un progreso! Dado que después de mucho tiempo sin llegar a ninguna parte, tal vez reduzca las cosas a la mitad y resuelva aproximadamente el 45-50% del problema total.

Y si todavía quedan problemas en torno a los secretos, al menos serán más específicos / enfocados y podrán seguir progresando / taklar después.

Sí, no entraré en demasiados detalles, pero estos enfoques nunca funcionarían para una situación en la que estoy trabajando actualmente, porque necesito un nivel de seguridad más alto del que brindan. Por ejemplo, no hay secretos sin cifrar en el disco, no hay claves de descifrado válidas una vez que se han descifrado en el proceso de destino, rotación de cifrado regular y depósito único para secretos cifrados (y no distribuidos entre servidores). Entonces, es más para las personas que tienen que hacer ese nivel de seguridad que he sugerido un posible enfoque.

secret_squirrel es de todos modos un truco en un espacio donde todavía no puedo ver ninguna solución viable, alrededor de Docker que aún no proporciona una API de secretos, o un controlador de secretos conectable, que con suerte lo harán en algún momento, pero tal vez sirva para ilustrar esa configuración ENV vars dentro del contenedor antes de ejecutar el proceso, pero no como parte del proceso de creación de la ventana acoplable (o metadatos) es una forma segura de cumplir con los secretos de 12 factores, y tal vez la comunidad de desarrollo de la ventana acoplable pueda usar esa idea cuando comience a construir un secrets-api / driver si creen que es bueno!

¡Feliz atraque!

Hemos estado utilizando el tipo de enfoque que describe @gtmtech , con gran éxito. Inyectamos secretos cifrados con KMS a través de variables de entorno, luego dejamos que el código dentro del contenedor se descifre según sea necesario.

Por lo general, eso implica un simple punto de entrada de ajuste, frente a la aplicación. Actualmente estamos implementando esa corrección con una combinación de shell y un pequeño binario de Golang (https://github.com/realestate-com-au/shush), pero me gusta el sonido del enfoque puro-Go.

@gtmtech @mdub Definitivamente me complacería ver más de esto.
@ dreamcat4 Creo que la definición de "complicado" podría depender de la ruta, lo que obviamente está bastante bien. Sin embargo, probablemente no puede ser un juicio abstraíble. Por lo tanto, sin embargo, una envoltura de seguridad dentro del contenedor de la ventana acoplable no me parece algo demasiado complicado a nivel de diseño. Otro aspecto son las mejores prácticas: es necesario considerarlas no desde una perspectiva exclusiva del desarrollador, sino desde una perspectiva operativa.
mis 2 centavos

Bóveda +1

Bóveda -1. Vault tiene algunas características operativas (apertura) que lo hacen realmente indeseable para muchas personas.

Tener una API conectable tendría más sentido.

También hay bóveda de Ansible. Esa es una bestia bastante diferente.

@gtmtech gracias por la sugerencia, me inspiró a escribir este punto de entrada:

#!/bin/bash

if [ -d "/var/secrets" ]; then
  tmpfile="$(mktemp)"
  for file in /var/secrets/*
  do
    if [ -f $file ]; then
      file_contents=$(cat $file)
      filename=$(basename "$file")
      underscored_filename="${filename//-/_}"
      capitalized_filename=${underscored_filename^^}
      echo "export $capitalized_filename=$file_contents" >> $tmpfile
    fi
  done

  source $tmpfile
  rm -f $tmpfile
fi

exec "$@"

Solo lo agrego al Dockerfile así (no olvides chmod + x en él):

ENTRYPOINT ["/app/docker-entrypoint.sh"]

Y voilá. Vars ENV disponibles en tiempo de ejecución. Suficientemente bueno :)

Si lo entiendo correctamente, el directorio /var/secrets debe montarse a través de los volúmenes, ¿verdad?
Además, cuando hay un comentario sobre secretos que no se escriben en el disco, ¿qué tan malo es escribirlos en el disco y luego eliminarlos?

¡Buena esa! Sin embargo, debe usar shred para eliminar el archivo de forma segura.

El jueves 3 de marzo de 2016, Juan Ignacio Donoso [email protected]
escribió:

Si entiendo correctamente, el directorio / var / secrets debe montarse a través de
volúmenes ¿verdad?
Además, cuando hay comentarios sobre secretos que no se escriben en el disco, ¿cómo
malo es escribirlos en un disco y luego borrarlos ???

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/13490#issuecomment -191887424.

Rui Marinho

Inspirado por el "secreto-ardilla" de @gtmtech , he ampliado mi herramienta de gestión de secretos "shush" para que se pueda utilizar como un punto de entrada de imágenes:

ADD shush_linux_amd64 /usr/local/bin/shush
ENTRYPOINT ["/usr/local/bin/shush", "exec", "--"]

Esto descifra cualquier KMS_ENCRYPTED_xxx envariable e inyecta los resultados de nuevo en el entorno.

https://github.com/realestate-com-au/shush#use -as-a-command-shim

Entonces el hilo comienza con NO HAGAS NINGUNA DE ESTAS COSAS .....

... pero no veo ninguna POR FAVOR HAGA ESTAS COSAS EN LUGAR ... solo varias propuestas / hacks que en su mayoría han sido rechazados / cerrados.

¿Cuál ES la mejor práctica oficial por ahora? Como usuario de la ventana acoplable, es algo frustrante ver una larga lista de cosas que no deberíamos hacer pero que luego no se ofrecen alternativas oficiales. ¿Me estoy perdiendo de algo? ¿No existe uno? Estoy seguro de que están sucediendo cosas detrás de escena y que esto es algo en lo que el equipo de Docker está trabajando, pero a partir de ahora, ¿cómo manejamos mejor la administración secreta hasta que se presente una solución canónica?

@alexkolson
Por lo que tengo entendido, si necesita secretos en tiempo de ejecución, debe usar volúmenes (secretos del sistema de archivos) o algunos servicios como HashiCorp Vault (secretos de red).

Para los secretos del tiempo de compilación, es más complicado.
Los volúmenes no son compatibles en el momento de la compilación, por lo que debe usar contenedores para ejecutar comandos que modifiquen el sistema de archivos y usar la confirmación de Docker.

Entonces, lo que falta es la capacidad de administrar secretos en el tiempo de compilación usando nada más que un Dockerfile, sin la necesidad de usar docker commit .

Algunas personas incluso dicen que usar el sistema de archivos para los secretos no es seguro, y que el demonio de la ventana acoplable debería proporcionar alguna API para proporcionar secretos de forma segura (¿utilizando red / firewall / volumen montado automáticamente?). Pero nadie tiene ni idea de cómo se vería esta API y cómo se usaría.

Cuando pienso en las deficiencias de env vars, pienso en problemas específicos que no son de Docker, como:

1. Agregar registros que capturan todas las variables de entorno o un phpinfo olvidado que queda en un servidor web de producción, así que tenga cuidado con los secretos y la configuración correctamente.
2. Quizás un troyano que expone env vars, así que no ejecute software que no sea de confianza.
3. Ataques que aprovechan las debilidades, como la inyección de sql, por lo tanto, valide la entrada y use un firewall de aplicaciones web.

Las debilidades presentadas en la parte superior de este hilo:

Accesible por cualquier proceso en el contenedor, por lo que se "filtra" fácilmente

Aplicar de forma cruzada 1 y 2 desde arriba. De fiar, pero abordado con cuidado, ¿verdad? Además, su contenedor Docker ejecuta muchos menos procesos que un servidor web de pila completa.

¿Qué pasa con la configuración en env var, pero las vars env secretas tienen valores cifrados y la aplicación tiene la clave en el código? Esto es solo una ofuscación, porque la clave está en el código, pero requeriría exploits para obtener acceso tanto a la clave como a las variables env. Tal vez use la administración de configuración para administrar la clave en el host de la ventana acoplable en lugar de en el código de la aplicación. Puede ayudar con los procesos de rouge y las fugas accidentales, pero obviamente no los ataques de inyección de alguien que tenga la clave.

Conservado en capas intermedias de una imagen y visible en la ventana acoplable inspeccionar

¿Las personas están horneando env vars en las imágenes de la ventana acoplable en lugar de configurarlas en tiempo de ejecución o estoy entendiendo mal este? Nunca guardes secretos en artefactos, ¿verdad? Sí sudo docker inspect container_name da la var env, pero si estás en mi servidor de producción, entonces iv ya se perdió. sudo docker inspect image_name no tiene acceso a mis variables env configuradas en tiempo de ejecución.

Compartido con cualquier contenedor vinculado al contenedor

¿Qué tal si no utilizas enlaces y la nueva red en su lugar?

El único problema que parece un problema de Docker y no universal son los enlaces ...

Ponme en el campo de la gente que necesita una buena manera de manejar secretos durante docker build . Usamos composer para algunos proyectos php y hacemos referencia a algunos repositorios privados de github para las dependencias. Esto significa que si queremos construir todo dentro de los contenedores, entonces necesitamos claves ssh para acceder a estos repositorios privados.

No he encontrado una manera buena y sensata de manejar esta situación sin derrotar algunas de las otras cosas que encuentro beneficiosas sobre Docker (ver: docker squash ).

Ahora tuve que retroceder en la construcción de partes de la aplicación fuera del contenedor y usar COPY para traer el producto final al contenedor. Meh.

Creo que docker build necesita alguna funcionalidad para manejar datos efímeros como secretos para que no encuentren su camino hacia el contenedor de envío final.

Creo que la compilación de Docker necesita alguna funcionalidad para manejar datos efímeros como secretos

Este es un problema filosófico más bien técnico. Estos datos efímeros vencerían el beneficio esencial de Docker: la reproducibilidad.

La filosofía de Docker es que su Dockerfile junto con un contexto es suficiente para construir una imagen.
Si necesita que un contexto esté fuera de la imagen resultante, debe buscarlo de la red y omitir la escritura en el sistema de archivos. Porque cada línea de Dockerfile da como resultado una instantánea del sistema de archivos.

Si los secretos no deben ser parte de una imagen, puede ejecutar un contenedor efímero, que reflejaría / proxy todos sus recursos protegidos en secreto y proporcionaría acceso sin secretos. Reflejar, por cierto tiene otra razón fundamental: https://developers.slashdot.org/story/16/03/23/0652204/how-one-dev-broke-node-and-thousands-of-projects-in-11-lines -of-javascript

También puede compartir la clave ssh, pero no podrá controlar su uso.

@ bhamilton-idexx si se asegura de que la autenticación de sus repositorios privados funcione con un token de corta duración, no tiene que preocuparse de que el secreto persista en la imagen de la ventana acoplable.
Hace que el sistema de compilación genere un token con un ttl de 1 hora, haga que esté disponible como una variable de entorno para la compilación de la ventana acoplable.
Tu compilación puede obtener los detalles de compilación requeridos, pero el tiempo de espera del secreto se agota poco después de que se completan las compilaciones, cerrando ese vector de ataque.

He estado leyendo un montón de estos hilos ahora y una característica que resolvería algunos casos de uso aquí y tendría casos de uso fuera de los secretos es una bandera --add para docker run que copia un archivo en el contenedor, al igual que la instrucción ADD en Dockerfiles

este artículo es A + http://elasticcompute.io/2016/01/21/runtime-secrets-with-docker-containers/

De hecho, es un gran artículo. Muy buena lectura. Y exactamente el tipo de cosas que esperábamos ver.

POR CIERTO:

También encontré un par de otras herramientas secretas que parecen haber pasado por alto en el artículo. Perdón por las repeticiones / duplicaciones. Todavía no me di cuenta de que se mencionaron aquí todavía:

Construye secretos del tiempo:

https://github.com/defunctzombie/docket

Secretos de tiempo de ejecución:

https://github.com/ehazlett/docker-volume-libsecret

¿Qué piensa la gente? Muchas gracias.

Para mi:

Estas nuevas herramientas ^^ se ven muy bien ahora. Y ciertamente no existían cuando comenzamos este boleto. PERO lo principal que ahora siento que todavía me falta más:

Tener una mejor capacidad para los secretos en tiempo de compilación en DockerHub. Lo cual es pobre allí y obliga a elegir entre una u otra. Debemos renunciar a los beneficios de una solución por los beneficios de la otra. Dependiendo del conjunto general de características que sean más importantes. Como la construcción local es definitivamente mejor para mantener seguros los secretos, pero comprensiblemente peor que Dockerhub en otros aspectos.

Hemos escrito otra herramienta, similar a Docket, que usa el nuevo formato de imagen:

https://github.com/AngryBytes/docker-surgery

Nuestra implementación primero crea una capa que contiene los secretos comentados SECRETS , luego crea una copia del Dockerfile con un FROM modificado, construye y finalmente elimina todas las capas SECRETS de la imagen resultante.

Siempre hay advertencias para piratear esto, y sería genial si la ventana acoplable tuviera incorporada una funcionalidad de rebase o empalme de capas. Eliminar las capas intermedias en este momento es lento, porque todas las soluciones tienen que hacer un baile docker save / docker load detrás de escena.

Además, el almacenamiento en caché de la compilación está roto. En este momento, usamos docker commit para crear la capa de secretos comentada, pero mantener un caché adecuado de estas capas sigue siendo un montón de trabajo, que es poco probable que hagamos. El uso de un Dockerfile para crear la capa de secretos puede resolver esto, pero no hay forma de comentar la capa, lo que dificulta identificar qué eliminar después.

@Vanuan [Dockerfile] no puede tener reproducibilidad. El comando EJECUTAR garantiza que usted y yo no podemos esperar razonablemente obtener la misma imagen exacta de dos ejecuciones. ¿Por qué? Porque la mayoría de las veces la gente usa RUN para acceder a los recursos de la red. Si quieres la misma imagen que yo, debes crear tu propia imagen 'DESDE' la mía. Ningún otro arreglo nos dará las mismas imágenes. Ningún otro arreglo puede darnos las mismas imágenes. Toda la reproducibilidad duradera proviene de Docker Hub, no de Dockerfile.

Si la única defensa de por qué no podemos tener datos efímeros es porque Docker cree que pueden eliminar todos los datos efímeros, entonces debe desaprobar la instrucción RUN.

@stephank He implementado una herramienta de compilación de

Y eso es ejecutando un "administrador de compilación" con el código del proyecto en un VOLUMEN. Luego, el administrador ejecuta cualquier cantidad de herramientas de compilación en contenedores separados que montan el código del proyecto utilizando volúmenes del administrador. Por lo tanto, los artefactos construidos y otros archivos producidos se guardan en el volumen del administrador y siguen el proceso de compilación para cada paso de compilación. Al final, el gerente puede construir una imagen de producción final utilizando el resultado de construcción producido. Todos los secretos necesarios a lo largo del camino han estado disponibles en el administrador y / o en los contenedores de compilación, pero no en la imagen final. No se utilizó la magia de la ventana acoplable y las memorias caché de compilación funcionan como se esperaba.

El aspecto de la canalización de compilación depende totalmente del proyecto utilizando un archivo de especificaciones que configura los requisitos de compilación.

De hecho, estoy bastante entusiasmado con esta herramienta, solo estoy esperando que podamos lanzarla como código abierto (a la espera de que se adopten las directrices de la política de la empresa).

@kaos Por un lado, no quería desviarme de las herramientas estándar de Docker. Por otro lado, creo que debería haber más competencia entre las herramientas de creación de imágenes. ¡Eso suena interesante! 😀

@thaJeztah para los

@alexkolson Creo que la clave de este hilo es "NO HAGA ESTO" a menos que haya mitigado X, Y, Z. Es claramente un tema de ingeniería: siempre habrá "soluciones" para problemas comunes. Dicho esto, la educación sobre qué no hacer y por qué es importante para que puedan comenzar las verdaderas soluciones. El diablo siempre está en los valores predeterminados, por lo que debemos asegurarnos de que los nuevos usuarios comprendan lo que está en riesgo.

Quizás algunos de ustedes puedan ayudarme porque todavía no tengo mucha experiencia con Docker.
Usé un Hashicorps Vault para buscar mis secretos.

Lo que hice básicamente fue pasar un token como argumento de compilación y el token se puede usar para obtener información confidencial de Vault. Esto ocurre en el momento de la compilación y solo puede tener éxito si el estado de la Bóveda está "sin sellar" (abierto para obtener datos). Después de construir, se revoca el token usado.

Pero creo que todavía me enfrento a algunos problemas comunes.

• Tengo que crear nuevas imágenes si cambian los datos confidenciales
• Si mi imagen fue robada / pirateada, entonces los datos confidenciales están dentro de la imagen.

Es posible encontrar el token usado con Docker Inspect, pero ya no se puede usar.
Tomé la decisión de sellar y abrir la bóveda de hashicorps solo en el momento de la construcción para limitar el acceso a la tienda de secretos tanto como sea posible. Tampoco vi una opción para mantener los secretos guardados al buscar datos en tiempo de ejecución.

Entonces, ¿qué tan mal lo hice (está bien decirlo si me equivoqué a lo grande;)) ¿Alguien tiene consejos y trucos para que las cosas sean más seguras?

@weemen AFAIK almacenar secretos en tu imagen tampoco es una buena idea. Tu imagen no debe tener credenciales integradas (incluidos los tokens de Vault). En su lugar, utilice el backend de autenticación de id de aplicación de Vault para que sus contenedores obtengan secretos sobre el tiempo de carga. Guárdelos en la memoria del contenedor de alguna manera, dependiendo de la pila de aplicaciones que esté usando.

Además, Vault está trabajando en un backend de autenticación de AWS que será útil en el futuro si está utilizando AWS como proveedor de nube.

@ jaredm4 ¿Puede aclarar esta afirmación ?:

"En su lugar, use el backend de autenticación de id de aplicación de Vault para que sus contenedores obtengan secretos sobre el tiempo de carga. Guárdelos en la memoria del contenedor de alguna manera, dependiendo de la pila de aplicaciones que esté usando".

Todavía no tengo claro cuándo / dónde recuperar los secretos de Vault (o Keywhiz, etc.). ¿Se hace esto antes de que la ventana acoplable se ejecute y se pase al comando de ejecución? ¿Está sucediendo esto en algún momento durante la inicialización del contenedor (si es así, algunos ejemplos)? ¿Mi aplicación debería recuperarlos cuando sea necesario? Por ejemplo, mi aplicación de rieles necesita claves de API de Google, ¿escribo algo dentro de rieles para llamar a la bóveda cuando se necesitan las claves?

Creo que tengo claro la necesidad de usar algo como Vault, y claro cómo configurarlo, simplemente no tengo claro cómo consumir el servicio y obtener mis archivos yml actualizados y listos cuando se inicie rails.

Se agradecería cualquier orientación aquí. Gracias

Claro, @mcmatthew , aunque debo

La forma en que he estado tratando de codificarlo es que la única información que pasa al contenedor es algo necesario para que su código pueda autenticarse con Vault. Si está utilizando el backend de app-id, ese sería el app-id sí mismo y la dirección de su Vault.

En el arranque del contenedor, su aplicación Rails notará que aún no tiene secretos y debe buscarlos en Vault. Tiene el app-id , y deberá generar de alguna manera su user-id . Esta generación de ID de usuario deberá ser determinada por usted, pero su documentación sugiere que "generalmente es un valor exclusivo de una máquina, como una dirección MAC o ID de instancia, o un valor hash de estos valores únicos".

Una vez que su aplicación Rails tenga listos el ID de la aplicación y el ID de usuario, puede usar la API de Vault para / iniciar sesión. Desde allí, puede realizar llamadas a la API para obtener los secretos necesarios.

Ahora, para aclarar lo que quise decir acerca de almacenarlos en la memoria, esto varía según el tipo de aplicación que esté utilizando, pero con Rails debería haber una forma de almacenar sus secretos en un caché de variables de usuario que permitirá a Rails acceder a la secretos de la memoria en cada solicitud en lugar de obtenerlos de Vault una y otra vez (lo que, como puede imaginar, sería lento). Eche un vistazo a esta guía sobre el almacenamiento en caché en Rails. Es decir, la sección 2.0, pero asegurándose de que esté usando memory_cache y no disk.

Por último, asegúrese de que, independientemente de cómo lo codifique, lo haga en Rails y no con un script de punto de entrada especial de Docker o similar. Rails debería detectar secretos en la memoria y, si no existen, buscarlos.

Espero que eso ayude. Lo sé, un poco de alto nivel, pero así es como hemos planeado abordarlo.

Lo que no está claro es qué se debe mantener en secreto, app-id, user-id o ambos.

Ok, la respuesta es https://www.vaultproject.io/docs/auth/app-id.html
Pero todavía no está claro por qué es más seguro que el simple acceso con cortafuegos.
¿Quizás es que cada secreto de host debería estar vinculado con el secreto de la aplicación (política)?
Es decir, si tiene acceso al secreto del host, ¿podría acceder a ciertas aplicaciones si conoce sus nombres secretos?

¿Ahora necesitamos almacenar 2 tokens en algún lugar?

@Vanuan Ambos deben mantenerse lo más secretos posible, sí.

El objetivo principal de la identificación de la aplicación es restringir el acceso a ciertos secretos dentro de Vault a través de Políticas. Cualquiera con acceso a la identificación de la aplicación obtiene acceso a los secretos de las políticas de esa identificación de la aplicación. La identificación de la aplicación debe ser proporcionada por su estrategia de implementación. Por ejemplo, si usa Chef, puede configurarlo en las bolsas de parámetros (o CustomJSON para OpsWorks). Sin embargo, por sí solo, no permitirá que nadie acceda a Vault. Entonces, alguien que obtuvo acceso a Chef no podría acceder a Vault.

Chef NO proporciona la identificación de usuario y debe estar vinculada a máquinas específicas. Si su aplicación se escala de forma redundante en todas las instancias, cada instancia debe tener su propio ID de usuario. Realmente no importa de dónde se origine esta identificación de usuario (aunque dan sugerencias), pero no debe provenir del mismo lugar que implementó la identificación de la aplicación (es decir, Chef). Como dijeron, se puede programar, solo por otros medios. Cualquier software que utilice para escalar instancias podría proporcionar identificadores de usuario a las instancias / contenedores de la ventana acoplable y autorizar el ID de usuario al ID de la aplicación. También se puede hacer a mano si no escala dinámicamente sus instancias. Cada vez que un humano agrega una nueva instancia, crea una nueva identificación de usuario, la autoriza a la identificación de la aplicación y la proporciona a la instancia a través de los medios que mejor se adapten a ellos.

¿Es esto mejor que las instancias de firewall? Supongo que depende. El cortafuegos no restringe el acceso a secretos en Vault (afaik), y si alguien obtiene acceso a sus instancias, podría ingresar fácilmente a su Vault.

De esta manera, es difícil para ellos conseguir todas las piezas del rompecabezas. Para ir un paso más allá, app-id también permite bloques CIDR que debes usar. Si alguien de alguna manera obtuvo la identificación de la aplicación y la identificación de usuario, aún no podría acceder a Vault sin estar en esa red.

(Nuevamente, esta es mi interpretación después de asimilar la documentación lo mejor que pude)

@Vanuan @mcmatthew ¡ Grandes preguntas! @ jaredm4 realmente gracias por esta aclaración, esto sin duda me ayudará. ¡Esto es muy útil para todos los que buscan una implementación más práctica! Si tengo tiempo en las próximas dos semanas, ¡lo intentaré de nuevo!

@thaJeztah :

Accesible por cualquier proceso en el contenedor, por lo que se "filtra" fácilmente

¿Puedes apoyar esta afirmación? Los procesos sin privilegios no pueden acceder a las variables de entorno de los procesos no principales. Consulte https://help.ubuntu.com/community/EnvironmentVariables#Process_locality.

Las variables de entorno establecidas para el contenedor (a través de --env o --env-file ) _son_ accesibles por cualquier proceso en el contenedor.

Por supuesto, ya que son hijos del proceso de punto de entrada. Es el trabajo de ese proceso, o de usted, en caso de que sea, por ejemplo, un shell, desarmar las variables secretas del entorno lo antes posible.

Lo que es más relevante es si los procesos con un ID de usuario diferente a 0 pueden acceder a estas variables de entorno dentro y / o fuera del contenedor. Este tampoco debería ser el caso, cuando el software que usa dentro del contenedor descarta correctamente los privilegios.

Sé que está fuera de tema, pero ¿alguien más ha notado que este problema ha estado activo durante casi un año completo? Mañana es su aniversario. 👏

¿Sería posible que un proceso contenedor lea las variables env en la memoria del proceso y luego las anule (en el entorno)? ¿Soluciona esto la mayoría de los problemas de seguridad en tiempo de ejecución?

@davibe, el problema con eso es que si el contenedor o su (s) proceso (s) se reinicia, esas variables de entorno desaparecen y no hay forma de recuperarlas.

Lo intenté, pero parece que env vars todavía están allí después del relanzamiento.

dade<strong i="6">@choo</strong>:~/work/grocerest(master)$ cat test.js
console.log("FOO value: " + process.env.FOO);
delete(process.env.FOO);
console.log("FOO value after delete: " + process.env.FOO);

dade<strong i="7">@choo</strong>:~/work/grocerest(master)$ docker run --name test -it -e FOO=BAR -v $(pwd):/data/ node node /data/test.js
FOO value: BAR
FOO value after delete: undefined

dade<strong i="8">@choo</strong>:~/work/grocerest(master)$ docker restart test
test

dade<strong i="9">@choo</strong>:~/work/grocerest(master)$ docker logs test
FOO value: BAR
FOO value after delete: undefined
FOO value: BAR
FOO value after delete: undefined

¿tal vez Docker-Run está ejecutando lo mío como hijo de bash? Creo que no debería ...

@davibe :

unset 'SECRET_ENV_VAR'

Creo que el principal problema / característica de todo esto es que inicias sesión en Docker como root , por lo que cualquier cosa que pongas dentro de un contenedor puede ser inspeccionada, ya sea un token, un volumen, una variable, una clave de cifrado. .. cualquier cosa.

Entonces, una idea sería eliminar sudo y su de su contenedor y agregar un comando USER antes de cualquier ENTRYPOINT o CMD . Cualquiera que ejecute su contenedor ahora no debería tener la oportunidad de ejecutarse como root (si no me equivoco) y, por lo tanto, ahora podría ocultarle algo.

Otra idea (la mejor en mi humilde opinión) sería agregar la noción de usuarios y grupos al socket de Docker y a los contenedores, de modo que pueda decirle a GROUP-A tiene acceso a contenedores con TAG-B, y USER-C pertenece a GROUP- A para que tenga acceso a esos contenedores. Incluso podría ser un permiso por operación (GROUP-A tiene acceso a iniciar / detener para TAG-B, GROUP-B tiene acceso a exec, GROUP-C tiene acceso a rm / inspect, y así sucesivamente).

Después de investigar esto durante unas horas, no puedo creer que no parezca haber una solución o solución alternativa recomendada oficialmente para los secretos del tiempo de compilación, y algo como https://github.com/dockito/vault parece ser la única opción viable para secretos del tiempo de construcción (salvo aplastar toda la imagen resultante o construirla manualmente en primer lugar). Desafortunadamente, https://github.com/dockito/vault es bastante específico para las claves ssh, así que voy a intentar adaptarlo para alojar los archivos de la tienda de credenciales git https también ...

Después de lo que parece una eternidad (originalmente escuché que estaba programado para el lanzamiento del cuarto trimestre de 2015), AWS ECS finalmente parece haber cumplido su promesa de llevar los roles de IAM a las aplicaciones de Docker . Aquí también está la publicación del

Parece que esto combinado con algunas bondades de KMS es una solución viable a corto plazo. En teoría, solo tiene que vincular los secretos a ciertos roles principales / IAM para evitar que los roles sin autorización soliciten algo que no deberían y dejar el almacenamiento seguro a KMS.

No lo he probado todavía, pero está en mi lista corta ...

Kubernetes también parece tener algunos secretos de manejo que me recuerdan mucho a las bolsas de datos cifradas de Chef.

Entiendo que esta no es la forma de OSS independiente de la plataforma que es el objetivo de este hilo,
pero quería lanzar esas dos opciones para las personas que juegan en esos espacios de infraestructura que necesitan algo _ AHORA_

Me encontré con algo que podría ayudar en este sentido: https://github.com/docker/docker/pull/13587

Parece que está disponible a partir de la ventana acoplable v1.10.0, pero no lo había notado hasta ahora. Creo que la solución hacia la que me estoy inclinando en este punto es usar https://www.vaultproject.io/ para almacenar y recuperar los secretos, almacenándolos dentro del contenedor en un sistema de archivos tmpfs montado en / secrets o algo de esa naturaleza . Con la nueva función de ECS que habilita los roles de IAM en los contenedores, creo que debería poder usar la autenticación de AWS EC2 de vault para asegurar la autorización de los secretos en sí. (Para la plataforma independiente, podría estar inclinado a ir con su autenticación de ID de aplicación).

En cualquier caso, la pieza que me faltaba era dónde guardar de forma segura los secretos una vez recuperados. La opción tmpfs me parece buena. Lo único que falta es que ECS aún no parece admitir este parámetro, por lo que envié esto hoy: https://github.com/aws/amazon-ecs-agent/issues/469

En conjunto, parece una solución bastante completa en mi humilde opinión.

@CameronGo , gracias por el puntero. Sin embargo, si entiendo correctamente, esto no se puede usar para construir bien, ¿o sí?

@NikolausDemmel lo siento, sí, tienes razón. Esta es solo una solución para los secretos del tiempo de ejecución, no el tiempo de compilación. En nuestro entorno, los secretos del tiempo de compilación solo se utilizan para recuperar código de Git. Jenkins maneja esto por nosotros y almacena las credenciales para el acceso a Git. No estoy seguro de que la misma solución satisfaga las necesidades de todos aquí, pero no tengo claro otros casos de uso para los secretos del tiempo de compilación.

Jenkins maneja esto por nosotros y almacena las credenciales para el acceso a Git.

¿Cómo funciona eso con Docker? ¿O no git clone dentro del contenedor mismo?

Después de leer este número en su totalidad, creo que se beneficiaría enormemente si se dividiera en problemas separados para los secretos de "tiempo de compilación" y "tiempo de ejecución", que tienen requisitos muy diferentes.

Si eres como yo y vienes aquí tratando de decidir qué hacer ahora mismo, entonces FWIW describiré la solución que elegí, hasta que surja algo mejor.

Para los secretos en tiempo de ejecución, decidí usar http://kubernetes.io/docs/user-guide/secrets/. Esto solo funciona si usa kubernetes. De lo contrario, la bóveda se ve bien. Cualquier cosa secreta, ya sea en la imagen generada o en la capa temporal, es una mala idea.

Con respecto a los secretos en tiempo de compilación, no puedo pensar en otros casos de uso de secretos en tiempo de compilación que no sean la distribución de código privado. En este punto, no veo mejor solución que confiar en realizar algo "secreto" en el lado del host y AGREGAR el paquete generado / jar / wheel / repo / etc. a la imagen. No vale la pena arriesgarse a exponer las claves ssh o la complejidad de ejecutar el servidor proxy al guardar un LOC que genera el paquete en el lado del host, como se sugiere en algunos comentarios.

¿Quizás agregar una bandera "-v" a la compilación de la ventana acoplable, similar a la bandera de ejecución de la ventana acoplable, podría funcionar bien? Compartiría temporalmente un directorio entre el host y la imagen, pero también se aseguraría de que apareciera vacío en la caché o en la imagen generada.

Actualmente estoy trabajando en una solución usando Vault :

1. La máquina del constructor tiene Vault instalado y tiene un token guardado localmente
2. Cuando comienza la compilación, la máquina de compilación solicita un nuevo token temporal solo válido por minutos (según la compilación, 1h incluso sería aceptable)
3. Inyecta el token como build arg
4. La imagen de Docker también tiene Vault instalado (o lo instala y lo elimina durante la compilación) y al usar este token puede recuperar los secretos reales

Es importante que los secretos se eliminen dentro del mismo comando, por lo que cuando la ventana acoplable almacena en caché la capa dada, no quedan restos. (Esto, por supuesto, solo se aplica para construir secretos de tiempo)

No lo he construido todavía, pero estoy trabajando en ello.

Algo relacionado con el comentario de @kozikow : "Con respecto a los secretos en tiempo de compilación, no puedo pensar en otros casos de uso de secretos en tiempo de compilación que no sean la distribución de código privado".

Tal vez no sea un secreto de tiempo de compilación específicamente, pero tengo una necesidad de caso de uso para (asegurar) una contraseña durante el tiempo de compilación en un Dockerfile para permitir que un artefacto ya construido se descargue a través de un comando RUN curl. La descarga en tiempo de compilación requiere credenciales de usuario para autenticarse con el fin de tomar el artefacto, por lo que pasamos la contraseña como una variable de entorno en el Dockerfile en este momento (todavía estamos en Dev). Las compilaciones ocurren detrás de escena automáticamente, ya que usamos OpenShift, y las variables de entorno en el Dockerfile se envían a los registros durante la compilación, como cualquier comando de compilación de Docker. Esto hace que la contraseña sea visible para cualquier persona que tenga acceso a los registros, incluidos nuestros desarrolladores. He estado tratando desesperadamente de encontrar una forma de enviar la contraseña para que se pueda usar durante la compilación de la ventana acoplable, pero luego no tengo la salida de la contraseña en los registros o termina en ninguna capa.

También secundo lo que dijo

Creo que podría valer la pena definir algunas pruebas para cualquier mecanismo secreto (en tiempo de ejecución) que se le ocurra a cualquiera. Porque hay muchas personas en este hilo que abogan por una seguridad muy débil.

Para empezar sugiero:

• El secreto no aparece en Docker Inspect
• Una vez iniciado el proceso 1, el secreto no está disponible en ningún archivo accesible desde el contenedor (incluidos los archivos montados en volumen)
• El secreto no está disponible en / proc / 1 / cmdline
• El secreto se transmite al contenedor de forma cifrada.

Cualquier solución sugerida anteriormente que viole uno de estos es problemática.

Si podemos acordar una definición de qué comportamiento debe seguir un secreto, entonces al menos eso eliminará un sinfín de soluciones que no son adecuadas para su propósito.

@gtmtech grandes sugerencias :)

Una vez iniciado el proceso 1, el secreto no está disponible en ningún archivo accesible desde el contenedor (incluidos los archivos montados en volumen)

No estoy seguro de estar de acuerdo con esto. Si bien estoy de acuerdo en que solo debería ser accesible desde el contenedor (idealmente en la memoria), hay varios casos en los que una aplicación necesita tiempo para "iniciarse" y no eliminar los archivos de debajo. Creo que algo en la memoria durante la ejecución del contenedor (eliminado al detenerse) es un enfoque un poco mejor.

Agregaría a la lista de requisitos de tiempo de ejecución:

• Autenticación / autorización de contenedor al arrancar el primer secreto.

Por ejemplo, Vault proporciona autorización con AppRole Backend, pero no tiene un final abierto con respecto a cómo se identifican los contenedores.

Nick Sullivan hizo una presentación sobre el proyecto PAL de Clouflare hace unas semanas, prometiendo abrirlo pronto, lo que debería proporcionar una posible respuesta a la pregunta de autenticación mediante un notario acoplable.

Desde la perspectiva de una aplicación, hay tres formas de lidiar con esto:

1. Obtenga un secreto de una variable de entorno.
2. Obtenga un secreto de un archivo.
3. Obtén un secreto de otro sistema.

1 y 2 anteriores son generalmente los más comunes porque la mayoría de las aplicaciones admiten este mecanismo. # 3 es probablemente más ideal ya que deja la menor cantidad de "migajas", pero la aplicación debe desarrollarse específicamente para esto y, a menudo, aún debe tener una credencial para obtener el secreto.

Docker tiene que ver con la versatilidad y la compatibilidad con una amplia variedad de casos de uso. Sobre esta base, 1. y 2. son más atractivos desde el punto de vista de una aplicación, a pesar de que ambos dejan "migajas" en el sistema.

Un enfoque común que ciertamente uso es inyectar secretos a través de un script de punto de entrada (por ejemplo, use una herramienta como credstash o KMS simple en AWS y combínelo con roles de IAM). En este sentido, en realidad hace el n. ° 3 anterior en el script de punto de entrada, y hace el n. ° 1 (establecer una variable de entorno) o el n. ° 2 (escribir en un archivo). Este enfoque es dinámico y, para el n. ° 1 (variables de entorno), no expone las credenciales en los registros de la ventana acoplable ni en la inspección de la ventana acoplable.

Lo bueno del enfoque de punto de entrada es que está separando las preocupaciones de la administración de secretos de la aplicación.

Esta es un área donde Docker podría agregar funcionalidad para evitar tener que usar sus propios scripts de punto de entrada. A Docker le encantan los complementos y podría proporcionar un enlace en el ciclo de vida del contenedor donde podría admitir complementos de proveedor "secretos", que esencialmente realizan la función de un script de punto de entrada manual e inyectan secretos en el contenedor (a través de una variable de entorno interno o un archivo). Por lo tanto, podría tener un proveedor de secretos de Hashicorp Vault, un proveedor de secretos de AWS KMS, etc. Docker quizás podría tener su propio proveedor basado en cifrado RSA (a través de certificados digitales). Todo este concepto es vagamente similar al concepto de secretos de Kubernetes, que presenta secretos sobre el sistema de archivos del contenedor.

Por supuesto, existe la complejidad de cómo autoriza el acceso al proveedor de secretos, que es un problema al que se enfrenta hoy en día. Con Hashicorp puede emitir y pasar un token único / por tiempo limitado para la autenticación, con AWS sus roles de IAM, con el enfoque de cifrado Docker RSA que mencioné, podría estar pasando secretos cifrados con el certificado público de Docker Engine.

Este hilo es genial. Espero que veamos más hilos como este en el que personas de la comunidad y de todos los ámbitos profesionales puedan compartir sus experiencias, pensamientos y soluciones.

El problema del "cero secreto" es complicado. ¿Tiempo de construcción o tiempo de ejecución? Ambos tienen sus pros y sus contras, y obvias medidas de seguridad y fallas (¡y trucos y soluciones!).

Dicho esto, he estado pensando mucho en cómo la administración de una contraseña / clave se reduce a la aplicación y / o servicio.

Algo en lo que trabajaremos en los próximos meses es construir un servicio de respaldo de configuración global compartido a través de pares clave / valor, distribuido por Consul y disponible como una variable de entorno (o inyectado si no se admite el uso de variables de entorno). Esto solo respalda sus valores inseguros. Para mayor seguridad, nos trasladaremos a Vault y lo trataremos como un servicio de respaldo, como una base de datos o cualquier otra dependencia.

El código, la configuración y los secretos se proporcionarán a través de los servicios de respaldo. En este caso, usamos Stash, Consul y Vault. Siempre que la dependencia esté activa, también lo estará la capacidad de extraer configuraciones y secretos según sea necesario.

No he visto esto como una solución sólida en ningún lado, por lo tanto, lo estoy publicando aquí. Pero para volver al propósito de este hilo, es un enfoque con el que vamos a experimentar para solucionar el problema Docker / secreto. Crearemos aplicaciones que admitan esto de forma nativa, en lugar de depender de los marcos y plataformas que los rodean en los que se ejecutan.

Con respecto a los secretos en tiempo de compilación, la directiva MOUNT Rocker ha demostrado ser útil para crear directorios y archivos transitorios que _sólo_ existen en el momento de la compilación. Algunas de sus funciones de plantillas también pueden ayudar en esta situación, pero aún no las he usado completamente.

¡Me encantaría ver esta funcionalidad implementada como un complemento Builder en el núcleo de Docker (así como algunas de las otras características útiles que tiene Rockerfiles)!

Veo que las 4 propuestas actualmente en OP son sobre almacenamiento secreto 🙁

Yo diría que los estibadores deberían facilitar el paso de un secreto / contraseña a una _instancia de docker_ pero que almacenar / administrar estos secretos está (y debería estar) fuera del alcance de Docker.

Cuando _pasar un secreto_, diría que un parámetro de ejecución es casi perfecto, excepto que esto generalmente se registra. Así que limitaría esto a una función de parámetro que no sea de texto sin formato . Un enfoque sería utilizar el cifrado con claves generadas por instancia de Docker.

En cuanto a _cómo administrar los secretos_, diría todo lo que el usuario quiera, desde un script bash casero hasta la integración mediante software como Kubernetes .

¿Qué hay de malo en implementar simplemente MOUNT como montajes rocker como @ agilgur5 comentó anteriormente? No puedo creer que este debate haya durado tanto que un equipo haya tenido que bifurcar efectivamente el comando docker build para satisfacer este caso de uso realmente fácil. ¿Necesitamos otro servidor HTTP en la mezcla? BESO.

Pasé tantas horas alrededor de este tema ...

Por ahora, la mejor manera que encontré para administrar secretos durante la fase de compilación es compilar en dos pasos, es decir, dos archivos de ventana acoplable. Aquí un buen ejemplo .

[Habitus] (http://www.habitus.io/) parece ser otra opción, pero en mi caso, no quiero agregar otras herramientas principalmente porque me gustaría que el proceso de compilación en el servidor CI Y en la computadora del usuario se mantenga simple / mismo.

¿Y qué pasa con el modo docker-in-docker (dind)?

Aquí un ejemplo de dos pasos construidos con dind como acabo de hablar anteriormente: https://github.com/BenoitNorrin/docker-build-with-secrets

No dudes en comentar ...

Interesante. Me recuerda un poco cómo se construye OpenShift.

Me parece que estás pasando la contraseña en la línea de comandos. ¿Hay alguna forma de evitar eso?

Tenga en cuenta que aquí hay un PR en progreso para los secretos del tiempo de compilación; https://github.com/docker/docker/pull/28079 (los secretos del tiempo de ejecución para los servicios estarán en la ventana acoplable 1.13, consulte https://github.com/docker/docker/pull/27794)

@thaJeztah :
Sobre el # 28079, soy un poco pesimista cuando vi tantas relaciones públicas fallidas sobre este tema durante los últimos dos años ...
No quiero tener un enjambre como dependencia. Parte de mis clientes utilizan otro orquestador de clústeres.

@cassiussa :
No entiendo lo que quieres decir
1 / Las contraseñas se pasaron al "constructor de contenedores", que no es la imagen final. Este constructor realiza una compilación de Docker y produce una imagen basada en Dockerfile.realease. No hay secretos almacenados en la historia de esta imagen final.
2 / Siéntase libre de usar docker-compose ( ejemplo ) si no desea pasar la contraseña a la línea de comando

@BenoitNorrin Creo que puede expandirse a no enjambre en el futuro, pero @diogomonica puede saber más sobre eso

Suena así:

Actualmente, esto es solo para el modo Swarm, ya que la tienda de respaldo es Swarm y, como tal, solo para Linux. Esta es la base para el futuro soporte secreto en Docker con posibles mejoras como el soporte de Windows, diferentes tiendas de respaldo, etc.

Sería genial si se implementara de la misma manera que el rocker, se puede
simple, no necesita ser "empresarial".

El martes 29 de noviembre de 2016 a las 15:53 ​​Michael Warkentin, [email protected]
escribió:

Suena así:

Esto es actualmente para el modo Swarm solo ya que la tienda de respaldo es Swarm y como
tal es solo para Linux. Esta es la base para el futuro apoyo secreto en
Docker con posibles mejoras, como compatibilidad con Windows, diferentes
tiendas de respaldo, etc.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/13490#issuecomment-263608915 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAZk5vlLwsBHHTTbUS_vvx-qTuwnkp6Oks5rDEpjgaJpZM4Eq021
.

Creo que una solución sería cifrar algunas partes de la información que se pasa de un archivo docker-compose .

Por ejemplo, ejecute docker inspect y la información cifrada debería mostrarse / marcarse como _encrypted_. Entonces docker inspect --encryption-key some_key_file mostraría toda la información cifrada, sin cifrar.

Por otro lado, dentro de los contenedores, las aplicaciones deberían poder implementar diferentes mecanismos para acceder y descifrar esta información encriptada para su uso.

Creo que el cifrado es la clave :)

El propósito de mi caso de uso (realmente, realmente, muy común) es construir un
proyecto de software de un servidor git que requiere autenticación, tanto para
el proyecto y sus dependencias. Rocker lo ha clavado permitiendo montar
un archivo o directorio durante la compilación (en este caso, un socket de agente SSH)

El martes, 3 de enero de 2017, 04:14 Hisa, [email protected] escribió:

Creo que una solución sería cifrar algunas partes de la información transmitida
desde un archivo docker-compose.

Por ejemplo, ejecute Docker Inspect y la información cifrada debe ser
mostrado / marcado como encriptado . Luego, la ventana acoplable inspecciona --encryption-key
some_key_file mostraría toda la información cifrada, sin cifrar.

Por otro lado, dentro de los contenedores, las aplicaciones deberían poder implementar
mecanismo diferente para acceder y descifrar esta información encriptada para su uso.

Creo que el cifrado es la clave :)

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/13490#issuecomment-270049742 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAZk5qEphZo5SR9vOWVL5dck50EPadpVks5rOcsUgaJpZM4Eq021
.

Como no vi que se mencionara, aquí hay otro buen artículo sobre el manejo de secretos en AWS ECS: https://aws.amazon.com/blogs/security/how-to-manage-secrets-for-amazon-ec2-container- aplicaciones-basadas-en-servicios-mediante-amazon-s3-and-docker /

Hay un nuevo comando "Docker secret" en Docker 1.13. Este problema debería poder cerrarse cuando la documentación de esa función sea adecuada para los casos de uso mencionados aquí.

El comando secreto de Docker parece aplicarse actualmente a Docker Swarm (es decir, servicios de Docker), por lo que actualmente no es viable para contenedores de Docker genéricos.

Además, docker secret solo administra los secretos del tiempo de ejecución, no los secretos del tiempo de compilación.

Guau. Es como si nadie en el equipo de gestión de productos hubiera considerado
el caso de uso en el que se obtiene cualquier cosa que no sea software de código abierto no autenticado
construido en un contenedor docker o en cualquier idioma además de golang, donde todos
las dependencias se copian y pegan, lo siento, 'versionadas' en el repositorio de Git.

No puedo entender cómo la gente puede ser tan increíblemente obtusa. Solamente
La explicación que se me ocurre es que el equipo de gestión de productos no
practicantes y nunca he usado el producto. A menudo veo esto
La característica se manifiesta cuando la organización contrata sobre la base
jira / habilidades ágiles.

Seguiré usando rocker hasta 2019 o cuando alguien tenga sentido en ese momento.

El domingo 22 de enero de 2017 a las 23:47, Shane StClair, [email protected] escribió:

Además, Docker Secrets solo administra los secretos del tiempo de ejecución, no los secretos del tiempo de compilación.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/13490#issuecomment-274370450 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAZk5vJVJe4OeypWd1Cwqmh8Gzyn8P-mks5rU-qqgaJpZM4Eq021
.

Retiro ese último comentario, lo siento, me estoy desahogando. Solo frustrado por eso
los casos extremos simples con frecuencia parecen una oportunidad para imponer algo
como cónsul o crear algo realmente sobre-diseñado en lugar de simplemente
implementar algo tan simple como tiempo de compilación de montaje.

El lunes 23 de enero de 2017, a las 09:31 Bryan Hunt, [email protected] escribió:

Guau. Es como si nadie en el equipo de gestión de productos hubiera considerado
el caso de uso en el que se obtiene cualquier cosa que no sea software de código abierto no autenticado
construido en un contenedor docker o en cualquier idioma además de golang, donde todos
las dependencias se copian y pegan, lo siento, 'versionadas' en el repositorio de Git.

No puedo entender cómo la gente puede ser tan increíblemente obtusa. Solamente
La explicación que se me ocurre es que el equipo de gestión de productos no
practicantes y nunca he usado el producto. A menudo veo esto
La característica se manifiesta cuando la organización contrata sobre la base
jira / habilidades ágiles.

Seguiré usando rocker hasta 2019 o cuando alguien tenga sentido
luego.

El domingo 22 de enero de 2017 a las 23:47, Shane StClair, [email protected]
escribió:

Además, Docker Secrets solo administra los secretos del tiempo de ejecución, no los secretos del tiempo de compilación.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/13490#issuecomment-274370450 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAZk5vJVJe4OeypWd1Cwqmh8Gzyn8P-mks5rU-qqgaJpZM4Eq021
.

@binarytemple Todo el mundo quiere todas las funciones ahora mismo. Si las cosas no están listas, entonces simplemente no están listas. Limitar el alcance de una nueva función definitivamente no es algo malo, ya que incluso con un alcance limitado, siempre hay margen de mejora.

Si alguien está realmente entusiasmado con la incorporación de una función, entonces debería hablar con un mantenedor sobre cómo pueden contribuir con el trabajo para eso.

Pensé lo mismo que @mixja en que el comando secret solo ayuda a los usuarios enjambres no es una solución más general (como lo hicieron al adjuntar volúmenes persistentes). La forma en que gestiona sus secretos (qué son y quién tiene acceso a ellos) depende en gran medida del sistema y depende de qué partes de pago y / o OSS improvise para crear su "plataforma". Con Docker, la compañía avanzando para proporcionar una plataforma, no me sorprende que su primera implementación esté basada en enjambres, al igual que Hashicorp está integrando Vault en Atlas, tiene sentido.

Realmente, la forma en que se transmiten los secretos queda fuera del espacio de docker run . AWS hace este tipo de cosas con roles y políticas para otorgar / denegar permisos más un SDK. Chef lo hace usando bolsas de datos encriptadas y "bootstrapping" criptográfico para la autenticación. K8S tiene su propia versión de lo que acaba de lanzarse en 1.13. Estoy seguro de que mesos agregará una implementación similar a tiempo.

Estas implementaciones parecen dividirse en dos campos.
1) pasar el secreto a través del montaje de volumen que proporciona la "plataforma" o (chef / docker secret / k8s
2) pasar credenciales para hablar con un servicio externo para obtener las cosas en el arranque (iam / credstash / etc)

Creo que esperaba ver algo más parecido a la segunda opción. En la primera opción, no creo que haya suficiente separación de preocupaciones (la cosa que hace el lanzamiento también tiene acceso a todas las claves), pero esto es preferencia, y como todo lo demás en la construcción del sistema, a todos les gusta hacerlo de manera diferente. .

Me alienta que Docker haya dado este primer paso y espero que de esto salga un mecanismo más general para docker run (para apoyar el campamento n. ° 2), lo que lamentablemente significa que no creo que este hilo sea La misión inicial se ha cumplido y aún no debería cerrarse.

¡igual que!
diseño realmente simple pero muy efectivo

@bacoboy , @mixja : un enjambre de un solo nodo y un solo servicio de contenedor no es tan malo
docker swarm init, servicio docker crear réplica = 1

para mí, es lógico que el enjambre de docker sea el predeterminado para ejecutar contenedores / servicios a partir de ahora.

¿Estoy en lo cierto al pensar que esta nueva propuesta basada en enjambres solo afecta los secretos del tiempo de ejecución? Realmente no veo ninguna necesidad de un manejo especial de los secretos en tiempo de ejecución, ya que existen muchas formas de obtener secretos en un contenedor en ejecución.

Los secretos del tiempo de

Para inyectar secretos en tiempo de compilación, ahora podemos usar docker build --squash para hacer lo siguiente de forma segura:

COPY ssh_private_key_rsa /root/.ssh/id_rsa
RUN git pull ...
RUN rm -rf /root/.ssh/id_rsa

La bandera --squash producirá una sola capa para todo el Dockerfile: no habrá rastro del secreto.

--squash está disponible en docker-1.13 como una bandera experimental.

@hmalphettes Esto significa que se pierde los beneficios de compartir capas inferiores entre compilaciones.

Definitivamente, esta no es la intención del squash. Aún tendré mucho cuidado al agregar secretos como este.

Las capas inferiores de

Estoy 100% de acuerdo con @ cpuguy83. Confiar en una marca de tiempo de construcción para mantener secretos sería bastante arriesgado. Hubo una propuesta de relaciones públicas para el tiempo de compilación (https://github.com/docker/docker/pull/30637) Trabajaré en una nueva base para obtener más comentarios.

@wpalmer Si tiene compilaciones de imágenes automatizadas, sus herramientas deben saber cómo obtener secretos en tiempo de compilación.

Por ejemplo, es posible que desee mantener sus secretos en tiempo de compilación en una bóveda cifrada de Ansible incorporada en una imagen y otorgar a los contenedores que se ejecutan desde esa imagen acceso al secreto en tiempo de ejecución que mantiene su contraseña de la bóveda.

WDYT?

¿Por qué seguimos confundiendo los secretos del tiempo de compilación con los secretos del tiempo de ejecución? Ya hay muchas buenas formas para que Docker (o herramientas relacionadas como kubernetes) proporcionen los secretos del tiempo de ejecución. Lo único que realmente falta son los secretos del tiempo de construcción. Estos secretos no se utilizan durante el tiempo de ejecución, se utilizan durante el tiempo de instalación, esto podría ser repositorios internos, por ejemplo. La única forma de trabajo que he visto en este y otros temas relacionados (pero también desaconsejado), es exponer un servidor http al contenedor durante el tiempo de compilación. El enfoque del servidor http hace que las cosas sean bastante complicadas para llegar a esos secretos.

+1 secreto de tiempo de construcción! = Secreto de tiempo de ejecución

Como señala Paul. No es deseable hornear repositorio interno
credenciales en la imagen.

¿Por qué es tan difícil de comprender?

El jueves 16 de febrero de 2017 a las 14:42 Paul van der Linden, [email protected]
escribió:

¿Por qué seguimos confundiendo los secretos del tiempo de compilación con los secretos del tiempo de ejecución? Allí
ya hay muchas buenas formas para que Docker (o herramientas relacionadas como Kubernetes)
proporcione los secretos del tiempo de ejecución. Lo único que realmente falta es el tiempo de construcción.
misterios. Estos secretos no se utilizan durante el tiempo de ejecución, se utilizan durante
tiempo de instalación, esto podría ser repositorios internos, por ejemplo. El único
forma de trabajo que he visto en este y temas relacionados (pero también aconsejé
en su contra), está exponiendo un servidor http al contenedor durante el tiempo de compilación.
El enfoque del servidor http hace que las cosas sean bastante complicadas para llegar a
esos secretos.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/13490#issuecomment-280348116 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAZk5h0Z2OGwApVnLNEFWKRdOfGxLOmRks5rdGBagaJpZM4Eq021
.

@pvanderlinden También puede hacerlo con dos pasos de construcción.
Aquí un ejemplo: https://github.com/BenoitNorrin/docker-build-with-secrets

@timka, como se mencionó, no es deseable incluir credenciales en la imagen, ya que eso representa un riesgo de seguridad. Aquí hay una propuesta para los secretos del tiempo de compilación: https://github.com/docker/docker/pull/30637

@BenoitNorrin No estoy seguro de cómo sería eso en mi (y en otros) caso de uso.
Los paquetes que deben instalarse ya están compilados cuando inicio el proceso de compilación de la ventana acoplable. Pero la compilación de la ventana acoplable necesitará instalar estos paquetes, necesitará acceso a un repositorio interno de anaconda y / o servidor pypi (python). Las ubicaciones y contraseñas son privadas, por supuesto.
Parece que el # 30637 es otro intento, ¡con suerte terminará en la ventana acoplable!

@timka, la primera mitad de su mensaje parece mencionar secretos en tiempo de compilación, pero la segunda mitad habla explícitamente sobre secretos en tiempo de ejecución. Los secretos en tiempo de ejecución son simples. Mi "solución" actual para los secretos en tiempo de compilación es ejecutar previamente, como un paso completamente separado, un contenedor que recupera datos privados utilizando un secreto en tiempo de ejecución. Otro paso luego fusiona esto en el árbol, antes de ejecutar un comando docker build regular.

La alternativa, si los secretos en tiempo de compilación fueran una característica estándar, sería ejecutar estos pasos dentro del Dockerfile.

Mis herramientas saben cómo ejecutar estos pasos automáticamente, pero necesitaba hornear esto yo mismo, lo cual es algo absurdo para un deseo tan común.

Para su información, escribí https://github.com/abourget/secrets-bridge para abordar el problema de los secretos en tiempo de compilación.

Crea una configuración desechable que puede pasar como argumentos, durante el proceso de compilación, se conectará al host y buscará los secretos, los usará y luego podrá eliminar el puente del host. Incluso si los build-args se guardan en algún lugar, se vuelven inútiles en el momento en que se mata el servidor.

El servidor admite el reenvío de agentes SSH, tunelizado a través de una comunicación TLS websocket. ¡También funciona en Windows!

Alexandre, lo que has hecho es extremadamente creativo y hábil. Es solo
Me entristece que sea necesario saltar a fondo todos estos pasos solo para
lograr lo mismo que se podría hacer si 'docker build' admitiera el 'mount'
orden en lugar de la insistencia ciega de que todo se copia en el
envase.

Soy mi caso, voy a abandonar 'docker build' y en su lugar usaré rocker o
algo si mi propia creación.

El jueves 13 de julio de 2017 a las 16:23 Alexandre Bourget, [email protected]
escribió:

Para su información, escribí https://github.com/abourget/secrets-bridge para abordar el
Problema de secretos en tiempo de construcción.

Crea una configuración desechable que puede pasar como argumentos,
durante el proceso de compilación, se conectará al host y buscará el
secretos, úselos y luego puede matar el puente de host. Incluso si el
build-args se guardan en algún lugar, se vuelven inútiles en el momento en que el servidor
es asesinado.

El servidor admite el reenvío de agentes SSH, tunelizado a través de un TLS
comunicación websocket. ¡También funciona en Windows!

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/moby/moby/issues/13490#issuecomment-315111388 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAZk5hZqTAgPBjS9cFP_IsYNa9wv-yoAks5sNjaBgaJpZM4Eq021
.

Aquí está la última propuesta de secretos: https://github.com/moby/moby/issues/33343

Creo que la nueva funcionalidad de "compilación de múltiples etapas" incluida en la última versión de Docker CE resuelve una gran parte de nuestros problemas.

https://docs.docker.com/engine/userguide/eng-image/multistage-build/

Los contenedores generados para ejecutar comandos desde Dockerfile vienen con /dev cocidos y ningún cambio realizado allí debe registrarse en una capa. ¿Puede Docker entregar secretos de usuario a través de ese punto de montaje? De manera similar, proporciona /dev/init ?

Esto sigue siendo bastante importante porque las compilaciones de varias etapas con argumentos no se filtran en la imagen, pero aún exponen sus secretos como parte de las listas de procesos en el sistema en ejecución, por lo que no está realmente resuelto.

Es agosto de 2017. Mientras tanto, "propuestas más antiguas para manejar secretos" en el número original enlazan con los números de 2014.

Todavía no existen buenas soluciones para los secretos en tiempo de compilación. El PR que ofreció la bandera --build-time-secret se cerró sin explicación. Nada presentado en "Entonces, ¿qué se necesita?" se implementa la sección.

mientras tanto

Steve Singh, director ejecutivo recientemente instalado, se centra en los clientes comerciales
Última ronda de $ 75 millones para ayudar a formar el equipo de ventas y marketing

UPD .: como @ cpuguy83 señaló correcta y legítimamente a continuación, el resumen completo de las propuestas está en # 33343

Sé que no está integrado, pero secrets-bridge funciona bastante bien por ahora.

@dmitriid Entiendo su frustración por la falta de esta función. Sin embargo, esta no es la forma de abordar una comunidad de código abierto (o cualquier comunidad).

Publiqué un enlace a una propuesta arriba y he visto exactamente 0 comentarios, excepto el mío.

Aquí está la última propuesta de secretos: # 33343

@ cpuguy83 ¡Impresionante! Me salté un poco el último tercio de esta discusión (y algunas otras) ya que hay muchas cosas para leer (mientras que al mismo tiempo busco una solución), así que realmente extrañé tu comentario, lo siento :(

Este hilo comenzó en 2015.

Es 2017.

¿Por qué no existe una solución para los secretos del tiempo de compilación que aún no sea hacker y terrible? Es muy obvio que es un gran problema para mucha gente, ¡pero todavía no existe una buena solución!

@mshappe

¿Por qué no existe una solución para los secretos del tiempo de compilación que aún no sea hacker y terrible?

Porque es un problema difícil de resolver correctamente y es algo que literalmente millones de personas utilizarán.

Por favor, vea mi comentario justo encima del suyo:

Publiqué un enlace a una propuesta arriba y he visto exactamente 0 comentarios, excepto el mío.
Aquí está la última propuesta de secretos: # 33343

Si desea ver algo implementado, tendrá que hacer algo más que quejarse de que algo no está implementado. ¡Por favor comente la propuesta!

Es tan fácil de resolver. Solo requiere algo, cualquier cosa que no sea
horneado en las imágenes. Y de hecho es muy fácil de resolver, deja de usar
'docker build' y use la API de python, rocker o cualquier otra cosa.

El miércoles 23 de agosto de 2017 a las 9:42 p.m., Brian Goff [email protected]
escribió:

@mshappe https://github.com/mshappe

¿Por qué no existe una solución para los secretos en tiempo de compilación que no sea pirateada y
terrible, todavía?

Porque es un problema difícil de resolver correctamente y es algo que
será utilizado literalmente por millones de personas.

Por favor, vea mi comentario justo encima del suyo:

Publiqué un enlace a una propuesta arriba y he visto exactamente 0 comentarios en
eso excepto el mío.
Aquí está la última propuesta de secretos: # 33343
https://github.com/moby/moby/issues/33343

Si desea ver algo implementado, deberá hacer más que
quejarse de que algo no se ha implementado. ¡Por favor comente la propuesta!

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/moby/moby/issues/13490#issuecomment-324441280 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAZk5oEpcipmfCji1mXz6MOVt0p6-OA6ks5sbIC0gaJpZM4Eq021
.

@binarytemple Empecé a considerar a Rocker como una alternativa, en realidad ... pero solo por este extraño bloqueo mental que parece tener la ventana acoplable sobre los secretos del tiempo de construcción.

Es raro. Hablo con la gente y están haciendo todo tipo de trucos estúpidos.
como usar un servicio HTTP - tirar todo (monitoreo / granular
permisos / simplicidad) que proporciona el combo POSIX / SELinux. Yo simplemente no
comprender. La negativa me parece ilógica.

El miércoles 23 de agosto de 2017 a las 23:03 Michael Scott Shappe [email protected]
escribió:

@binarytemple https://github.com/binarytemple Comencé a mirar
Rocker como alternativa, en realidad ... pero solo por este extraño
La ventana acoplable de bloqueo mental parece tener secretos en el momento de la compilación.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/moby/moby/issues/13490#issuecomment-324461257 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAZk5ppZYsOhdfvgotCUk5l41Truo_EEks5sbJOLgaJpZM4Eq021
.

Las compilaciones de Docker de múltiples etapas resuelven muchos de estos problemas.

En su forma más simple, puede inyectar secretos como build-args, y solo serán parte del historial de imágenes de las imágenes que explícitamente dicen que necesitan el argumento. Como señala neclimdul , los secretos estarán disponibles en la lista de procesos durante la compilación. En mi opinión, no es un gran problema, pero hemos adoptado otro enfoque.

Nuestro servidor de compilación se ejecuta con algunos secretos montados como volúmenes, por lo que nuestra copia de CI en f.ex. /mnt/secrets/.npmrc en el directorio de trabajo actual. Luego usamos un Dockerfile similar al siguiente.

FROM node:latest
WORKDIR /usr/src/app
COPY .npmrc .
RUN echo '{ "dependencies": [ "lodash" ] }' > package.json
RUN npm install
RUN ls -lah

FROM alpine:latest
WORKDIR /usr/src/app
COPY --from=0 /usr/src/app/node_modules ./node_modules
RUN ls -lah
CMD ["ls", "./node_modules"]

La imagen resultante tendrá las dependencias instaladas, pero no el .npmrc ni ningún rastro de su contenido.

El uso de compilaciones de varias etapas le brinda un control total sobre cómo exponer los secretos del tiempo de compilación al proceso de compilación. Puede obtener secretos de tiendas externas como Vault, a través de volúmenes (que montamos desde la tienda Secrets en Kubernetes), tenerlos encriptados con gpg en el repositorio, secretos de Travis, etc.

Cuando use compilaciones de múltiples etapas para este caso de uso, asegúrese de darse cuenta de que los datos secretos permanecerán dentro de una imagen sin etiquetar en el demonio local hasta que esa imagen se elimine para que estos datos se puedan usar para compilar la memoria caché en compilaciones posteriores. Pero no se envía al registro cuando se envía la imagen etiquetada final.

@androa Me gusta esa solución, pero no estoy seguro de cómo me siento acerca de los secretos que se copian en el directorio de trabajo. Eso probablemente esté bien en un servidor de CI privado, pero no es tan bueno para un edificio local donde estaría copiando archivos que no debería sacar de ubicaciones protegidas (sin mencionar que la copia en sí es molesta y peligrosa ya que podrían terminar accidentalmente en control de fuente). La otra opción sería usar un contexto de compilación de Docker más amplio, pero para muchos secretos comunes eso podría significar todo el volumen raíz. ¿Alguna sugerencia sobre cómo hacer que esto sea bueno para los locales y CI?

Esto es espantoso. La autoproclamada "plataforma de contenedores de software líder en el mundo" no puede molestarse en pasar de forma segura los secretos del tiempo de compilación en contenedores durante los últimos 3 años.

Con el enfoque "sabemos mejor" y "no cometemos software que permita errores" y lo que puede describirse en el mejor de los casos como una omisión desafortunada en la fase de diseño, no hay soporte ni progreso visible hacia una de las características requeridas del software DevOps. Todas las mejoras sugeridas por la comunidad y, a veces, incluso desarrolladas hasta el punto de estar listas para fusionarse, se cierran por temor a que alguien las abuse. Como resultado de este clúster ... falla, todas las formas de pasar claves privadas necesarias solo para la fase de compilación del contenedor de la ventana acoplable requieren guardar esos secretos en el historial de compilación, o estar visible en la lista de procesos con la esperanza de que, respectivamente, el historial de compilación nunca abandone el máquina de confianza o nadie que no deba ver nunca la lista de procesos. Ambos fallarán incluso en la mayoría de las auditorías de seguridad permisivas.

Este número está abierto desde hace más de 2 años para resumir lo que se sabía sobre el problema en ese momento y qué hacer al respecto. Todavía no hay solución. Con eso, no me refiero a una solución integral que admita los esquemas de administración de secretos más complejos desde el primer momento. No hay solución en absoluto, no hay variables de entorno de host, no hay secretos de carga de la ruta del archivo fuera del contexto de compilación. Nada que pueda considerarse seguro incluso en los términos menos estrictos.

@OJezu Como he dicho varias veces sobre este tema, hay una propuesta abierta con básicamente 0 comentarios al respecto.
Si desea que se sigan adelante los secretos, tómese el tiempo para comentar la propuesta.

En lugar de atacar a las personas que trabajan en esto todos los días, la próxima vez intente hacer preguntas y leer al menos los últimos comentarios sobre el tema que está comentando.

Las cosas a menudo pueden parecer estancadas cuando en realidad solo hay personas trabajando duro.
Para compilar, consulte github.com/moby/buildkit donde se lleva a cabo la mayor parte de este trabajo en la actualidad.

Gracias.

Estoy un poco borracho, porque hoy pasé 9 horas tratando de encontrar una solución a algo que no debería ser un problema, especialmente en un proyecto en el que se está trabajando a tiempo completo y que se posiciona como estándar de facto y punto de referencia. . Me esforcé mucho por no maldecir y dejar de autolesionarme mientras escribía estos comentarios.

Analicé ese problema y vi referencias a dos soluciones, una estancada desde abril y la otra ya cerrada. No puedo dejar de notar que la propuesta de 0 comentarios tiene 4 participantes, la misma cantidad de comentarios y menciona una aparente discusión interna, supongo de personas más familiarizadas con las complejidades de. Pero si desea comentarios adicionales de alguien que ni siquiera programa en marcha, puedo proporcionar más ideas sobre los problemas que mencioné en el comentario anterior.

@OJezu

Existe al menos una solución sencilla: utilice un servicio dedicado (por ejemplo, ejecutar en Jenkins) para crear artefactos.
Ese servicio proporcionará de forma segura todas las claves necesarias para acceder a los artefactos de los que depende su imagen.
Al terminar, los artefactos se colocarán en un lugar seguro (por ejemplo, Jenkins). Esos artefactos no contendrían ningún secreto, solo un directorio con binarios / fuentes / etc.
Luego, otro servicio (por ejemplo, otro trabajo de Jenkins) accederá a esos artefactos prediseñados y los convertirá en una imagen que se puede enviar de forma segura a un registro de imágenes, que a su vez está protegido de forma segura mediante rbac / keys para acceder a ellos desde las máquinas de desarrollo / producción.

Es decir, el proceso de construcción de la imagen de la ventana acoplable no es diferente a cualquier otro sistema de construcción: debe tener una canalización de construcción en su lugar.

@Vanuan no todos los idiomas son tan simples con el empaquetado y la instalación, para simplemente instalar con un artefacto.

¿Ejemplos?

Los proyectos de Python establecen sus requisitos en el tiempo de instalación, no en el tiempo de construcción. En nuestro caso, desde un repositorio pypi / conda privado (protegido por contraseña)

¿Entonces? Haga que la instalación sea parte de su proceso de compilación y luego copie los paquetes instalados en una imagen nueva.

Solo necesita asegurarse de que su imagen de compilación y su imagen de producción se basen en la misma imagen base de Python.

De hecho, puede simplemente copiar todo en una nueva imagen. Sin embargo, eso elimina todo el punto de un Dockerfile. ¿Por qué tener un Dockerfile si lo único que puede usar es para copiar un conjunto de directorios?

Por lo tanto, no puedo tener un flujo simple en el que simplemente ejecute docker build . donde sea, ya sea en la máquina de desarrollo o en CI, pero tengo que depender de CI para construir paquetes. ¿Por qué molestarse con Docker entonces? Puedo escribir un archivo travis o configurar el flujo en bambú.

¿No puedes simplemente pip install requirements.txt en tu primera etapa de compilación con secretos disponibles para extraer de tus repositorios privados? Luego, la compilación de la siguiente etapa simplemente copia los paquetes del sitio de la primera etapa.

¿Por qué tener un Dockerfile si lo único que puede usar es para copiar un conjunto de directorios?

¿Por qué no? Usar un Dockerfile para compilar es consistente.

La especificación de la imagen es más que un montón de archivos comprimidos. Hay variables de entorno, argumentos de línea de comando, volúmenes, etc.

Lea la referencia de Dockerfile:
https://docs.docker.com/engine/reference/builder/

Parece que se ha centrado principalmente en la instrucción RUN , pensando que Dockerfile es un reemplazo para su Makefile. No lo es. Dockerfile está destinado a una sola cosa: crear una imagen a partir de algún material de origen. No importa cuál sería ese material de origen, un binario descargado a través de http o un repositorio de git. No es necesario que Docker sea su sistema de CI, aunque puede usarlo como tal en determinadas condiciones.

Puedo escribir un archivo travis o configurar el flujo en bambú.

Si puede obtener el resultado de su proceso de compilación y luego ejecutarlo en otro entorno, sin imágenes ni contenedores, entonces seguro que no necesita preocuparse por la ventana acoplable. ¿Por que lo harias?

Entorno separado y estrictamente controlado que obtiene reinicios garantizados entre compilaciones, pero solo si los pasos de compilación han cambiado. Capacidad para ejecutarlo en cualquier lugar, no solo en servidores CI (como con Travis), vinculando las instrucciones de compilación con el código, lo que creo que es bueno si la compilación cambia para diferentes ramas de código (por ejemplo, cambia la versión del entorno de ejecución solo en una rama). Posibilidad de ejecutar el contenedor de compilación en las máquinas de desarrollo, lo que permite enviar todo el entorno a los desarrolladores que, de otra manera, no tienen idea de cómo actualizar su propio sistema, pero que podrán crear aplicaciones con sus cambios localmente con el mismo entorno que todos los demás.

Si no quisiera todo eso, me quedaría con lxc + ansible, entonces no hay necesidad de Docker.

No necesitas docker build para eso.

No necesitas docker build para eso.

Por supuesto, también puede proporcionar un script Makefile o build_image.sh para cada proyecto en lugar de un único Dockerfile autosuficiente, pero eso tiene múltiples desventajas:

• Compatibilidad multiplataforma: al proporcionar un Dockerfile, sé que cualquier sistema que pueda ejecutar docker build podrá crear la imagen. Al proporcionar un Makefile o build_image.sh , tengo que asegurarme manualmente de que funcionen en todas las plataformas que quiero admitir.
• Interfaz conocida para los usuarios: si conoce Docker, conoce parte del comportamiento de docker build para cualquier proyecto, incluso sin mirar el Dockerfile (por ejemplo, con respecto al almacenamiento en caché, etc.). Si tengo un Makefile o build_image.sh , para cada proyecto, primero necesito averiguar cuáles son los comandos para construir, limpiar, dónde y en qué forma está el resultado, si hay es algo de almacenamiento en caché y en qué forma, ...

Oh, Dockerfile está lejos de ser autosuficiente. Especialmente para el entorno de desarrollo.
Considera esto:

• la mayoría de los desarrolladores no conocen todas las diferentes opciones de docker build , pero casi todo el mundo sabe cómo ejecutar scripts bash
• docker build depende del directorio de contexto . Entonces, a menos que esté dispuesto a esperar a que los gigabytes de datos (su código fuente con dependencias) viajen de una ubicación a otra por cada cambio de línea de fuente, no lo usará para el desarrollo.
• a menos que construya TODO desde cero, tiene una dependencia en el registro de Docker
• es probable que dependa de los repositorios del sistema operativo (ya sea que use imágenes basadas en Debian o Alpine), a menos que inicie un contenedor directamente en el binario construido estáticamente
• a menos que confirme todo en git, tendrá algunas dependencias a nivel de proyecto, ya sea npm, índice de paquetes de Python, rubygems o cualquier otra cosa. Entonces dependerá de algún registro de paquete externo o su espejo
• como la mayoría de la gente notó aquí, dependerá de la ubicación de algún paquete secreto para sus dependencias privadas que no puede publicar en el repositorio público, por lo que dependerá de eso
• El aprovisionamiento de secretos es necesario para acceder a esa ubicación segura, por lo que dependerá de algún sistema que distribuya secretos a los desarrolladores.
• Además de Dockefile, necesitará docker-compose.yml, y no es multiplataforma: aún depende de las diferencias de barra inclinada hacia

Compatibilidad multiplataforma: al proporcionar un Dockerfile, sé que cualquier sistema que pueda ejecutar la compilación de la ventana acoplable podrá generar la imagen.

Dockerfile no garantiza la compatibilidad multiplataforma. Aún debe proporcionar múltiples Dockerfiles para múltiples plataformas. "Puede ejecutar la compilación de Docker" ya no significa "Usa Linux". Docker también admite imágenes nativas de Windows. Aún debe usar Cygwin + Linux VM si desea ejecutar algo específicamente dirigido a máquinas Linux en un host de Windows.

Ah, y ni siquiera mencioné x86 vs ARM ...

Interfaz conocida para los usuarios: si conoce la ventana acoplable, conoce parte del comportamiento de la compilación de la ventana acoplable para cualquier proyecto, incluso sin mirar el Dockerfile

A menos que no lo hagas. Todo el mundo sabe cómo ejecutar un script bash sin parámetros o un solo comando make . Pocas personas saben cómo especificar correctamente todas las diferentes opciones de línea de comando para docker build , docker run o docker-compose . Es inevitable que tenga algún script de bash o cmd de envoltura.

Con el debido respeto a lo que hizo la gente de Docker, creo que está pidiendo demasiado. Me temo que Mobyproject no tiene un alcance tan amplio como para admitir todos los flujos de trabajo de desarrollo imaginables.

No voy a refutar todos sus puntos individualmente. En primer lugar, por supuesto, siempre puede encontrar situaciones en las que el enfoque de "archivo Dockerfile único" no funciona en absoluto. Sin embargo, yo diría que para casi todos los puntos que planteó (todos válidos y relevantes), el enfoque de "script personalizado o archivo MAKE" es igual de malo o peor. Solo como ejemplo, un punto:

la mayoría de los desarrolladores no conocen todas las diferentes opciones de compilación de Docker, pero casi todo el mundo sabe cómo ejecutar scripts bash

Si estoy involucrado en 10 proyectos, y todos usan un Dockerfile, necesito aprender sobre Docker solo una vez, pero con tu sugerencia, necesito aprender 10 scripts de compilación totalmente diferentes. ¿Cómo borro el caché y empiezo desde cero para el proyecto Foo's build_image.sh nuevamente? No es claro. Si la construcción de la imagen se realiza con docker build , está claro (ofc, necesito saber cómo funciona la ventana acoplable, pero también necesito hacerlo para usar la imagen que sale de build_image.sh ).

En general, supongo que el punto que otros y yo estamos tratando de hacer es que para / muchos / escenarios el enfoque "single Dockerfile" parece funcionar muy bien para la gente (lo cual es una razón por la que Docker es tan popular), en particular en el mundo de código abierto donde normalmente todos los recursos son accesibles sin secretos. Pero si intenta aplicar el mismo patrón que ha llegado a amar en un contexto en el que parte de sus recursos necesitan credenciales para acceder, el enfoque se rompe. Ha habido una serie de sugerencias (e implementaciones) de formas tecnológicamente no demasiado complejas para hacer que funcione, pero nada ha sucedido durante mucho tiempo (esto se ha expuesto muchas veces anteriormente). De ahí la frustración.

Aprecio que la gente se esté esforzando en esto, por ejemplo, con la propuesta vinculada en # 33343. Mi publicación trata de motivar lo que algunas personas hacen y por qué siguen volviendo pidiéndolo aquí.

Con el debido respeto a lo que hizo la gente de Docker, creo que está pidiendo demasiado. Me temo que Mobyproject no tiene un alcance tan amplio como para admitir todos los flujos de trabajo de desarrollo imaginables.

Me parece que lo que la mayoría de la gente está pidiendo aquí no es nada por el estilo, sino solo una forma simple de usar secretos en docker build de una manera que no sea menos segura que usarlos en su build_image.sh personalizado

Lo siento, pero cada persona en este ticket tiene un caso de uso ligeramente diferente. Esos son casos de esquina y requieren diferentes soluciones.

1. Quiero ejecutar imágenes de producción en máquinas de desarrollo. Usar el registro de Docker
2. Quiero un sistema de CI distribuido, para que cada desarrollador tenga una compilación reproducible. Use docker run para construir su proyecto, use docker prune para limpiar
3. Quiero crear imágenes de Docker para poder distribuirlas. Utilice un servidor de CI dedicado en el que pueda ejecutar compilaciones de varias etapas.

@Vanuan , así que supongo que su enfoque es básicamente: no use la compilación de Docker, para nada más que el entorno básico. Este es un problema creado para cambiar eso. "Tienes que hacerlo de otra manera" ES el problema, no la solución.

Las personas que impulsan el problema quieren tener enfoques más simples y directos con imágenes de la ventana acoplable, sin tener que esquivar las limitaciones de la ventana acoplable.

Para cualquiera que esté interesado: había intentado explotar los argumentos de compilación "enmascarados por defecto" como FTP_PROXY para crear contextos. Es seguro con respecto al hecho de que docker-build no expone esos argumentos enmascarados a metadatos de imágenes ni capas de imágenes.

36443 fue un intento de expandirlo a un argumento de compilación llamado SECRET para que podamos alentar a los usuarios a usarlo como una solución simple para el problema de administración de secretos.

Sin embargo, el trabajo ha sido rechazado razonablemente, ya que la naturaleza enmascarada de esos argumentos de compilación no está garantizada en el futuro.

Mi mejor opción después de eso es seguir el consejo de @AkihiroSuda , usar docker build --network o una herramienta como habitus para almacenar / pasar secretos a través de un servidor tcp temporal, solo los contextos de compilación visibles viven dentro de un solo demonio docker, en el más amplio.

Comentando parcialmente, así que recibiré una notificación dentro de 5 años, cuando Docker finalmente decida darnos un pequeño paso en la dirección de una gestión adecuada de las credenciales ... y también, para dar un resumen del truco que estoy usando en este momento. , para ayudar a otros, o para que le hagan agujeros que no conozco.

Al seguir el problema de argumentos predefinidos para construir secretos.

Entonces, esencialmente, puedo usar docker-compose, con un mapeo como este:

  myProject:
    build:
      context: ../myProject/
      args: 
        - HTTPS_PROXY=${NEXUS_USERNAME}
        - NO_PROXY=${NEXUS_PASSWORD}

Y luego, en la carpeta con el archivo docker-compose.yml, cree un archivo llamado ".env" con pares clave-valor de NEXUS_USERNAME y NEXUS_PASSWORD, y los valores adecuados allí.

Finalmente, en el propio Dockerfile, especificamos nuestro comando de ejecución así:
EJECUTAR wget --usuario $ HTTPS_PROXY - contraseña $ NO_PROXY

Y NO los declare como ARG en DockerFile.

Todavía no he encontrado mis credenciales flotando en la compilación resultante ... pero no sé si estoy buscando en todas partes ... Y para el resto de los desarrolladores de mi proyecto, cada uno de ellos tiene que cree el archivo .env con los valores adecuados para ellos.

@darmbrust Probé tu solución pero no pude hacerla funcionar.
Aquí está mi composición yml:
versión: "3.3"
servicios:

  buildToolsImage:
    image: vsbuildtools2017:web-v6

    build:
      context: .
      dockerfile: ./vsbuild-web-v6-optimized.dockerfile
      args:
        - CONTAINER_USER_PWD=${CONTAINER_USER_CREDS}

Aquí está el archivo .env junto al archivo yml:

CONTAINER_USER_CREDS=secretpassword

Y aquí está mi dockerfile:

# escape=`
FROM microsoft/dotnet-framework:4.7.2-sdk
# Add non-root user
CMD ["sh", "-c", "echo ${CONTAINER_USER_PWD}"] 
RUN net user userone ${CONTAINER_USER_PWD} /add /Y

Y finalmente, el comando para iniciar esto es así:

docker-compose -f docker-compose.buildImage.yml build

Construye la imagen pero sin usar la contraseña almacenada en el archivo .env.

[Advertencia] No se consumieron uno o más argumentos de compilación [CONTAINER_USER_PWD]

¿Que me estoy perdiendo aqui?
¡Gracias!

Tienes que usar uno de los https://docs.docker.com/engine/reference/builder/#predefined -args en el archivo docker. No puede usar sus propios nombres de argumentos como CONTAINER_USER_PWD.

Así es como funciona el truco, porque Docker tiene un comportamiento especial para los argumentos predefinidos, ya que puede usarlos sin declararlos. Y al usarlos sin declararlos, no parecen estar registrados en ninguna parte.

Con el archivo docker-compose, puede asignar esos argumentos predefinidos a algo con un nombre más razonable.

@darmbrust Sí, eso funcionó.
Sin embargo, ¿no crees que huele mal? ¿Alguna recomendación mejor?
¡Gracias!

Probablemente no huele tan mal como exponer sus credenciales de agente ssh a través de tcp
a través de socat para cualquier proceso local para robar, pero de hecho, como con cualquier cosa
relacionado con los secretos, 'docker build' es bastante maloliente.

En realidad, había olvidado que Docker para Mac no puede exponer el dominio Unix
sockets en el host osx a los contenedores, por lo que se abre aún más un
lata de gusanos.

Mi solución actual, ejecutar una cuenta de usuario de máquina Centos VM, GitHub
las credenciales entran en él, compile usando la herramienta "Rocker" (obsoleta).

El jueves 26 de julio de 2018 a las 21:49, Sameer Kumar, [email protected] escribió:

@darmbrust https://github.com/darmbrust Sí, eso funcionó.
Sin embargo, ¿no crees que huele mal? ¿Alguna recomendación mejor?
¡Gracias!

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/moby/moby/issues/13490#issuecomment-408230125 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAZk5iz1kvCpZ0s65ng4TwL7LmHa9zZvks5uKitDgaJpZM4Eq021
.

Todo este error huele mal. No he encontrado una mejor manera ... hay varios otros enfoques anteriores, pero creo que todos los demás seguros requieren colocar un pequeño servidor http para alimentar la información en la imagen. quizás menos maloliente, pero más complejo, más herramientas, más piezas móviles.

No estoy seguro de que alguien haya encontrado una "buena" solución ... todos estamos atrapados esperando que la gente de la ventana acoplable haga algo al respecto ... no contenga la respiración, ya que este error se escribió en 2015, y no lo han hecho. Ni siquiera propuso todavía una hoja de ruta, y mucho menos una solución.

Es tan simple y obvio, permite el montaje de volúmenes, (archivos o
directorios) en el contenedor durante la compilación.

Esta no es una limitación técnica, es una decisión de no permitir secretos en
para preservar el comportamiento de - verificar, ejecutar compilación, mismas entradas, mismas
salida, cambie un argumento de compilación si desea invalidar el caché ...

El problema es que la abstracción se ha vuelto cada vez más permeable.
con personas que utilizan todo tipo de trucos inseguros y torpes para obtener un "secreto"
en un recipiente.

Newsflash, exponer su llavero SSH a través de TCP, incluso en localhost no es
seguro, tampoco pasar credenciales a través de variables de entorno (pista, ejecutar
ps, o echar un vistazo al sistema de archivos / proc), los argumentos de comando y las variables ambientales están ahí, desnudos, para que el mundo los vea.

Para los desarrolladores de código golang, esto tradicionalmente no ha sido un problema, ya que copian y pegan
sus dependencias en sus proyectos en lugar de utilizar una herramienta de gestión de dependencias, los desarrolladores de golang llaman a esta práctica "venta".

Para cualquiera que trabaje en otros ecosistemas donde el sistema de construcción
obtiene dependencias de Git, o repositorios que requieren autenticación, es un gran problema.

Estoy bastante seguro de que hay alguna regla de inicio en algún lugar como,
"No suponga que sabe cómo o por qué sus usuarios utilizan el producto".

El jueves 26 de julio de 2018 a las 22:00, Dan Armbrust, [email protected] escribió:

Todo este error huele mal. No he encontrado una mejor manera ... hay
varios otros enfoques anteriores, pero creo que todos los demás seguros
requiere colocar un pequeño servidor http para alimentar la información en el
imagen. tal vez menos apestoso, pero más complejo, más herramientas, más conmovedor
partes.

No estoy seguro de que alguien haya encontrado una "buena" solución ... todos estamos estancados
esperando a que la gente de la ventana acoplable haga algo al respecto ... no sostengas tu
aliento, ya que este error se escribió en 2015, y ni siquiera han propuesto
una hoja de ruta y mucho menos una solución.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/moby/moby/issues/13490#issuecomment-408233258 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAZk5nvbBTj4BAv5TtELNIHhJN8mU0Ctks5uKi38gaJpZM4Eq021
.

@binarytemple Todos los que alguna vez han trabajado en Docker / moby (como los ingenieros detrás de él) saben exactamente cuál es el problema e incluso se han enfrentado a él.

Volumes es una solución que en sí misma tiene una fuga increíble.
Hay una propuesta, mencionada un poco en el flujo de comentarios, que intenta resolver esto de una manera razonable (https://github.com/moby/moby/issues/33343)

Lo principal aquí es proporcionar la abstracción "correcta" en lugar de "cualquier abstracción que funcione" ... por supuesto, sabemos que esto es doloroso para muchos en algo más que en este caso.

Últimamente se ha realizado mucho trabajo en el constructor que no es necesariamente visible todavía, pero los frutos de este esfuerzo comenzarán a aparecer en los próximos meses.
Para empezar, Docker 18.06 se envía con una implementación de generador alternativa respaldada por https://github.com/moby/buildkit.
Puede pensar "¿en qué me ayuda esto?". Buildkit proporciona muchas primitivas de bajo nivel que nos permiten ser mucho más flexibles en el constructor de Docker. Incluso para poder proporcionar su propio analizador de compilación (que puede ser cualquier cosa, desde un analizador de Dockerfile mejorado hasta algo completamente diferente). Los analizadores se especifican en la parte superior del "Dockerfile" y son cualquier imagen que desee utilizar para analizar el archivo.

Si realmente desea ver algo en este momento, puede tomar buildkit y ejecutarlo hoy, se encuentra en la parte superior del contenedor, puede construir una integración personalizada con bastante rapidez.

Se agregó soporte para montajes secretos a buildkit en https://github.com/moby/buildkit/pull/522 . Aparecen estrictamente en tmpfs, están excluidos de la caché de compilación y pueden usar una fuente de datos configurable. Aún no hay PR que lo exponga en una sintaxis de archivo docker, pero debería ser una simple adición.

Hay 2 soluciones para construir imágenes con secretos.

Construcción de varias etapas:

FROM ubuntu as intermediate
ARG USERNAME
ARG PASSWORD
RUN git clone https://${USERNAME}:${PASSWORD}@github.com/username/repository.git

FROM ubuntu
# copy the repository form the previous image
COPY --from=intermediate /your-repo /srv/your-repo

Entonces: docker build --build-arg USERNAME=username --build-arg PASSWORD=password my-image .

Usando un generador de imágenes: docker-build-with-secrets

@BenoitNorrin lo siento, pero ha expuesto esa contraseña a todos los procesos en el sistema host. Seguridad de Unix 101: no ponga secretos como argumentos de comando.

Sí, pero hay algunos usos en los que la seguridad importa un poco menos:

• quieres construir en tu propia computadora
• se basa en su servidor de CI empresarial (como jenkins). La mayoría de las veces se trata de tener acceso a un repositorio privado (nexus, git, npm, etc.), por lo que su CI puede tener sus propias credenciales para eso.
• puede usar una máquina virtual creada a partir de docker-machine y eliminarla después.

Si ese es el único problema, @binarytemple , entonces simplemente agregar la bandera docker image build --args-file ./my-secret-file debería ser una solución bastante fácil para todo este problema, ¿no es así? :pensando:

@yajo podría ser, sí, al menos es una solución alternativa hasta que el kit de construcción se envíe con el montaje de secretos. Buena sugerencia. Gracias. B

Desafortunadamente, la mayoría de las soluciones alternativas mencionadas en estos y muchos otros tickets aún exponen los secretos de la imagen resultante, o solo funcionan con lenguajes específicos donde solo necesita dependencias durante el tiempo de compilación y no durante la instalación.

@binarytemple que nunca sucederá, los mantenedores de

El mayor punto de dolor son las rotaciones secretas para mí.

debe mantener un gráfico del secreto de las dependencias de los servicios y actualizar dos veces cada servicio (para volver al nombre secreto original)

enumerar los secretos de los servicios no parece ser fácil (me di por vencido después de algunos intentos alrededor de docker service inspect --format='{{.Spec.TaskTemplate.ContainerSpec.Secrets}}' <some_service> ), enumerar las dependencias de los servicios de docker secret inspect <secret_name> sería útil. Así que mantengo ese gráfico (aproximado) manualmente por ahora.

También debe especificar el destino secreto, cuando no es el /run/secrets/<secret_name> predeterminado en el comando de actualización del servicio docker

Solo espero una forma más sencilla de rotar secretos.

@caub aquí hay algo de ayuda CLI:

Los documentos de Docker para formatear ayudan a generar el resto del formato de inspección:

docker service inspect --format='{{range .Spec.TaskTemplate.ContainerSpec.Secrets}}{{println .SecretName}}{{end}}'

Eso enumerará todos los nombres secretos en un servicio. Si quisiera tanto el nombre como la identificación, podría:

docker service inspect --format='{{range .Spec.TaskTemplate.ContainerSpec.Secrets}}{{println .SecretName .SecretID}}{{end}}' nginx

Siempre tengo mi CI / CD (comandos de actualización de servicio) o los archivos de pila codifican la ruta para que no tenga ese problema en la rotación.

Con las etiquetas, puede hacer que la automatización de CI / CD identifique el secreto correcto si no está usando archivos de pila (sin necesitar el nombre secreto, que sería diferente cada vez).

docker build --secret finalmente está disponible en Docker 18.09 https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

@thaJeztah ¿Estamos listos para cerrar este tema?

Para las versiones anteriores de la ventana acoplable, el uso de la compilación de varias etapas con la copia de secretos antes del comando de compilación es una opción viable, ¿verdad?

''
DESDE debian como compilación
COPIA ./secret.conf / ruta / en / imagen /
EJECUTAR build.sh
...

DE debian
COPIA --desde = compilar ...

@ andriy-f sí, eso funciona, siempre que tú;

• (obviamente) no copie el secreto a la etapa final 😉, o:
• use la etapa / etapa build en la que un secreto está presente como "padre" para la imagen final
• nunca _push_ la etapa de compilación a un registro
• confíe en el host en el que se ejecuta su demonio; es decir, teniendo en cuenta que su etapa de "construcción" se conserva como una imagen; alguien con acceso a esa imagen podría tener acceso a tu secreto.

los secretos del tiempo de construcción ahora son posibles cuando se usa buildkit como constructor; vea la publicación del blog aquí https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

y la documentación; https://docs.docker.com/develop/develop-images/build_enhancements/

la opción RUN --mount utilizada para los secretos pronto pasará a la sintaxis predeterminada (estable) de Dockerfile

Gracias @thaJeztah .

Frio. Eso cierra la cuestión de los secretos del tiempo de construcción. ¿Algo para runtime / devtime (ssh en OS X)?