Docker usando gosu vs USUARIO

Question

Docker usando gosu vs USUARIO

Docker siempre tenía un comando USER para ejecutar un proceso como un usuario específico, pero en general muchas cosas tenían que ejecutarse como ROOT.

He visto un montón de imágenes que utilizan un ENTRYPOINT con gosu para de-elevar el proceso a ejecutar.

Todavía estoy un poco confundido acerca de la necesidad de gosu. ¿No debería ser suficiente el USUARIO?

Sé que ha cambiado bastante en términos de seguridad con Docker 1.10, pero todavía no tengo claro la forma recomendada de ejecutar un proceso en un contenedor docker.

Puede alguien explicar cuando yo usaría gosu vs USER?

Gracias

EDITAR:

La guía de mejores prácticas de Docker no es muy clara: Dice que si el proceso se puede ejecutar sin privilegios, use USER, si necesita sudo, es posible que desee usar gosu. Eso es confuso porque uno puede instalar todo tipo de cosas como ROOT en el Dockerfile, luego crear un usuario y darle los privilegios adecuados, luego finalmente cambiar a ese usuario y ejecutar el CMD como ese usuario. Entonces, ¿por qué necesitaríamos sudo o gosu entonces?

26

docker dockerfile

Author: MrE, 2016-04-22

Source

3 answers

Estoy usando gosu y entrypoint.sh porque quiero que el usuario del contenedor tenga el mismo UID que el usuario que creó el contenedor.

Volúmenes y permisos de Docker.

El propósito del contenedor que estoy creando es para el desarrollo. Necesito compilar para Linux, pero todavía quiero toda la connivencia de la edición local (OS X), herramientas, etc. Mi mantener los UIDs el mismo dentro y fuera del contenedor mantiene la propiedad del archivo mucho más cuerdo y evita que algunos errores (el usuario del contenedor no puede editar archivos en el volumen montado, etc.)

4

Author: user2466803,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-06-20 20:07:00

La ventaja de usar gosu es también el manejo de señales. Puede trap por ejemplo SIGHUP para recargar el proceso como lo haría normalmente a través de systemctl reload <process> o tal.

1

Author: khaoz,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-07-24 07:34:35

score 21 · Accepted Answer

Los Dockerfiles son para crear imágenes. Veo a gosu como más útil como parte de una inicialización de contenedor cuando ya no puede cambiar usuarios entre comandos de ejecución en su Dockerfile.

Después de crear la imagen, algo como gosu te permite soltar permisos de root al final de tu punto de entrada dentro de un contenedor. Es posible que inicialmente necesite acceso root para realizar algunos pasos de inicialización (arreglar uid, permisos de volumen montados en el host, etc.). Luego, una vez inicializado, ejecuta el final servicio sin privilegios de root y como pid 1 para manejar las señales de forma limpia.

Editar: Este es un ejemplo simple de usar gosu en una imagen para docker y jenkins: https://github.com/bmitch3020/jenkins-docker

El entrypoint.sh busca el gid de /var/lib / docker.sock y actualiza el gid del usuario de docker dentro del contenedor para que coincida. Esto permite que la imagen sea portada a otros hosts docker donde el gid en el host puede diferir. Cambiar el grupo requiere acceso root dentro del contenedor. Si hubiera usado USER jenkins en el dockerfile, me quedaría atascado con el gid del grupo docker como se define en la imagen, que no funcionaría si no coincide con el host docker en el que se está ejecutando. Pero el acceso de root se puede eliminar cuando se ejecuta la aplicación, que es donde entra gosu.

Al final del script, la llamada exec evita que el shell bifurque gosu, y en su lugar reemplaza pid 1 con ese proceso. Gosu a su vez hace lo mismo, cambiando el uid y luego ejecuta el proceso jenkins para que tome el control como pid 1. Esto permite que las señales sean manejadas correctamente que de otra manera serían ignoradas por un shell como pid 1.