subir - tutorial docker file

¿Por qué ARG en un DOCKERFILE no se recomienda para pasar secretos? (4)

En http://docs.docker.com/engine/reference/builder/#arg , se recomienda que los secretos no se pasen a través de ARGS.

Nota: no se recomienda usar variables de tiempo de compilación para pasar secretos como claves de github, credenciales de usuario, etc.

¿En qué momento los secretos que pasan a través de las variables de tiempo de construcción están en peligro?

Actualización de agosto de 2018:

Ahora tiene la build --secret id=mysecret,src=/secret/file docker build --secret id=mysecret,src=/secret/file .
Consulte " .com/a/51921954/6309 ".

Actualización enero 2017:

Docker (enjambre) 1.13 tiene un docker secret .

Sin embargo, como commented Steve Hoffman ( bacoboy ) :

[...] El comando secreto solo ayuda a los usuarios de enjambres, no es una solución más general (como lo hicieron al adjuntar volúmenes persistentes).
La forma en que administre sus secretos (qué son y quién tiene acceso a ellos) depende mucho del sistema y depende de los bits de pago y / o OSS que se improvisan para crear su "plataforma".
Con Docker, la compañía se está moviendo 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 cómo se pasan los secretos cae fuera del espacio de docker run de la 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 datos encriptados y criptografía "bootstrapping" 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 en el tiempo.
Estas implementaciones parecen caer en 2 campos.
Pase el secreto a través del montaje de volumen que proporciona la "plataforma" o (chef / docker secret / k8s
pase credenciales para hablar con un servicio externo para obtener información al inicio (iam / credstash / etc)

Respuesta original: noviembre de 2015.

Esto se introdujo en commit 54240f8 (docker 1.9, noviembre de 2015), de PR 15182 ,

El entorno de compilación se añade a la cadena de comandos del continuador intermedio para ayudar a las búsquedas de caché.
También ayuda a construir trazabilidad. Pero esto también hace que la característica sea menos segura desde el punto de vista de pasar secretos de tiempo de construcción.

el número 13490 reitera:

Variables de entorno de tiempo de construcción: las variables de entorno de tiempo de construcción no fueron diseñadas para manejar secretos. Por falta de otras opciones, la gente planea usarlas para esto. Para evitar dar la impresión de que son adecuados para los secretos, se ha decidido no cifrar deliberadamente esas variables en el proceso.

Como se menciona en 9176 comments :

Las variables env son la forma incorrecta de pasar secretos. No deberíamos intentar reinventar la rueda y proporcionar un mecanismo de distribución de seguridad paralizado desde el primer momento.
Cuando almacena sus claves secretas en el entorno, es propenso a exponerlas accidentalmente, exactamente lo que queremos evitar:
Dado que el entorno está implícitamente disponible para el proceso, es increíblemente difícil, si no imposible, rastrear el acceso y cómo se exponen los contenidos.
Es increíblemente común que las aplicaciones capturen todo el entorno y lo impriman, ya que puede ser útil para la depuración o incluso enviarlo como parte de un informe de errores. Se filtraron tantos secretos a PagerDuty que tienen un proceso interno bien engrasado para eliminarlos de su infraestructura.
Las variables de entorno se transfieren a procesos secundarios, lo que permite un acceso no deseado y rompe el principio de privilegio mínimo. Imagine que, como parte de su aplicación, llama a la herramienta de terceros para realizar alguna acción, de repente esa herramienta de terceros tiene acceso a su entorno, y Dios sabe qué hará con ella.
Es muy común que las aplicaciones que fallan almacenen las variables de entorno en archivos de registro para su posterior depuración. Esto significa secretos en texto plano en el disco.
Poner secretos en variables env se convierte rápidamente en conocimiento tribal. Los nuevos ingenieros no saben que están allí y no son conscientes de que deben tener cuidado al manejar las variables de entorno (filtrarlas a subprocesos, etc.).
En general, los secretos en las variables env rompen el principio de menos sorpresa, son una mala práctica y conducirán a la eventual filtración de secretos.

Creo que la nueva función (17.05) de la ventana acoplable Compilaciones de múltiples etapas ( https://docs.docker.com/engine/userguide/eng-image/multistage-build/ ) mitiga estas preocupaciones (válidas) acerca de simplemente usar --build- arg.

FROM mybuildertools ADD my-git-creds /root/.ssh RUN git clone [email protected]:example/foo /src FROM mybuildertools COPY --from=0 /src /src RUN ...build /src with no git credentials ending up in final image...

Desafortunadamente, no parece haber una manera fácil de permitir reconstrucciones posteriores (por ejemplo, cambios en el paso de compilación en el Dockerfile) a menos que tenga el directorio "my-git-creds".

Escribí https://github.com/abourget/secrets-bridge para abordar el problema de los secretos de tiempo de construcción.

Crea una configuración desechable que puede pasar como un argumento de compilación, durante el proceso de compilación, se conectará con el 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 el servidor sale.

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

Espero que esto ayude.

La razón simple es que el valor del secreto es visible para cualquier persona con la imagen simplemente ejecutando el history en ella.

Toma este archivo docker de muestra:

FROM alpine ARG secret RUN echo "${secret}"

(Agradable y simple, solo para ilustrar cómo puedes usar un secreto).

luego lo construimos $ docker build --build-arg secret=S3CR3T - < Dockerfile

Sending build context to Docker daemon 2.048 kB Step 1 : FROM alpine ---> 13e1761bf172 Step 2 : ARG secret ---> Running in 695b7a931445 ---> 5414c15a1cb6 Removing intermediate container 695b7a931445 Step 3 : RUN echo "${secret}" ---> Running in c90cf0d1414b s3cr3t ---> f2bcff49ac09 Removing intermediate container c90cf0d1414b Successfully built f2bcff49ac09

Y un ejemplo de cómo recuperar el "secreto" (busque |1 secret= en la primera línea):

$ docker history f2bcff49ac09 IMAGE CREATED CREATED BY SIZE COMMENT f2bcff49ac09 8 seconds ago |1 secret=S3CR3T /bin/sh -c echo "${secret}" 0 B 5414c15a1cb6 8 seconds ago /bin/sh -c #(nop) ARG secret 0 B 13e1761bf172 6 months ago /bin/sh -c #(nop) ADD file:614a9122187935fccf 4.797 MB

Este es el caso si ha creado la imagen localmente o la ha extraído de un registro.

Si su objetivo es mantener el secreto del tiempo de construcción fuera del contenedor en ejecución, el uso de ARG le ayudará: considere esto:

$ docker run --rm -ti f2bcff49ac09 sh / # env HOSTNAME=7bc772fd0f56 SHLVL=1 HOME=/root TERM=xterm PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PWD=/ $ # Note no secret in the above output