Differences

This shows you the differences between two versions of the page.

--- guia_rapida_de_dockerfile [2021/03/06 02:14] – busindre
+++ guia_rapida_de_dockerfile [2021/05/22 17:16] (current) – [Directivas de un fichero Dockerfile] busindre
@@ Line 22: / Line 22: @@
 <code bash>ARG DEBIAN_FRONTEND=noninteractive</code>
-Con ARG no deben usarse credenciales ni llaves criptográficas ya que estas estarían visibles al ejecutar "docker history". Las variables son únicamente validas en el momento de definirse. La última definición de la variable en el Dockerfile será la que puede ser sobrescrita desde la linea de comandos. Si se usan múltiples FROM (multi-stage builds), ARG debe estar también definida en cada stage. La [[guia_rapida_de_dockerfile#construccion_de_imagenes_docker_mediante_eatapas_multi-stage|construcción por etapas]] se explica más adelante.
+Con ARG no deben usarse credenciales ni llaves criptográficas ya que estas estarían visibles al ejecutar "docker history". Las variables son únicamente validas en el momento de definirse. La última definición de la variable en el Dockerfile será la que puede ser sobrescrita desde la linea de comandos. Si se usan múltiples FROM (multi-stage builds), ARG debe estar también definida en cada stage. La [[#construccion_de_imagenes_docker_mediante_etapas_multi-stage|construcción por etapas]] se explica más adelante.
 Las variables definidas von ARG pueden ser sobrescritas siempre con ENV (se verá más adelante), haciendo inútil por tanto el uso de la sustitución por linea de comando de variables definidas mediante ARG. Ejemplo de sustitución de variable definida con ARG.
@@ Line 112: / Line 112: @@
-**ADD** permite copiar ficheros del host a la imagen y los contenedores dispondrán de esos ficheros, permite configurar propietario y grupo. Si se especifica el nombre de usuario, este debe estar en "/etc/passwd" y "/etc/group". Se debe de usar siempre rutas relativas al directorio donde creemos la imagen con el Dockerfile. Para el destino sí se deben usar rutas absolutas. Se pueden especificar varios origenes pero NO sin son remotos.
+**ADD** permite copiar ficheros del host a la imagen y los contenedores dispondrán de esos ficheros, permite configurar propietario y grupo. Si se especifica el nombre de usuario, este debe estar en "/etc/passwd" y "/etc/group". Se debe de usar siempre rutas relativas al directorio donde creemos la imagen con el Dockerfile. Para el destino sí se deben usar rutas absolutas. Se pueden especificar varios orígenes pero NO sin son remotos.
 La diferencia con COPY es que ADD descomprime automáticamente ficheros comprimidos y permite descargar de internet archivos. Los permisos predeterminados son 600 para los ficheros obtenidos remotamente con ADD.
-<code bash>ADD --chown=XXXX:XXXX "alpine-minirootfs-3.13.0-x86_64.tar.gz" /opt/codicoalpine
+<code bash>ADD --chown=XXXX:XXXX "alpine-minirootfs-3.13.0-x86_64.tar.gz" /opt/codigoalpine
 # ADD decomprimirá el tar.gz en /opt/codigoalpine, si no se desea la descompresión automática se debe usar COPY.
 # La aplicación de permisos en este caso no se aplican a los ficheros descomprimidos.</code>
-ADD no es compatible con procesos de autenticación cuando usamos origenes remotos. En esos casos se puede usar RUN von wget o cualquier otro software que permite descargar mediante autenticación.
+ADD no es compatible con procesos de autenticación cuando usamos orígenes remotos. En esos casos se puede usar RUN von wget o cualquier otro software que permite descargar mediante autenticación.
 <code bash>ADD https://freetsa.org/files/cacert.pem /opt/</code>
 **COPY** no permite usar ficheros remotos y no descomprime los ficheros de manera automáticamente como si hace ADD.
-<code bash>COPY --chown=XXXX:XXXX "alpine-minirootfs-3.13.0-x86_64.tar.gz" /opt/codicoalpine
+<code bash>COPY --chown=XXXX:XXXX "alpine-minirootfs-3.13.0-x86_64.tar.gz" /opt/codigoalpine
-# El propietario de /opt/codicoalpine/alpine-minirootfs-3.13.0-x86_64.tar.gz sera XXXX.</code>
+# El propietario de /opt/codigoalpine/alpine-minirootfs-3.13.0-x86_64.tar.gz sera XXXX.</code>
 La ruta origen es relativa siempre al directorio de trabajo donde estemos (PWD).
-<code>COPY directorio_local/ /opt/codicoalpine/</code>
+<code>COPY directorio_local/ /opt/codigoalpine/</code>
 NOTA: Si en el destino se usa una ruta relativa, será en base al WORKDIR usado por la imagen. Si se copia un directorio del anfitrión (host) los permisos son también copiados (no así el propietario).
@@ Line 134: / Line 134: @@
 COPY "alpine-minirootfs-3.13.0-x86_64.tar.gz" /opt/volumen2/</code>
+Si se quiere controlar el montaje de volúmenes con un determinado usuario que no sea root, este puede ser primeramente definido en el fichero Dockerfile. Una vez se monte el volumen, heredará los permisos y propietario definidos previamente en la imagen. En el ejemplo se crea una imagen docker llamada alpine_volumen que usará un usuario no privilegiado "testuser".
+<code bash>ARG USR=testuser
+FROM alpine
+RUN addgroup -S $USR && adduser -S $USR -G $USR           # Se crea el usuario y el grupo para luego aplicarlo al punto de montaje del volumen.
+RUN mkdir /DIR_testuser && chown $USR:$USR /DIR_testuser  # Se crea el directorio donde será montado el volumen y su propietario
+VOLUME /DIR_testuser                                      # Se hace una referencia al volumen que será montado desde linea de comando o docker-compose.
+USER $USR                                                 # Usuario del proceso.</code>
+Linea de comando (se creará el volumen XXXX si no existe).
+<code bash>docker run --rm -it -v XXXX:/DIR_testuser alpine_volumen</code>
+Montar el volumen desde docker-compose, el volumen se crea automáticamente si no existe. El contenedor creado solo ejecutará una shell.
+<code>version: "3"
+services:
+  web:
+    image: alpine_volumen  # Imagen creada a partir del Dockerfile mostrado anteriormente.
+    stdin_open: true # docker run -i
+    tty: true        # docker run -t
+    command: /bin/sh
+    volumes:
+      - XXXX:/DIR_testuser  # El volumen será montado como el usuario testuser.
+volumes:
+    XXXX:</code>
+NOTA: El traspaso automático de la configuración de usuario y permisos al montar el volumen sucede únicamente, cuando el volumen no ha sido usado previamente por otro contenedor. Esto es solo aplicable a volúmenes, NO a directorios (bind mounts) del host. Para cpntrolar los permisos de "bind mounts" con aplicaciones como docker-compose, habría que usar en ENTRYPOINT comandos chmod / chown para adaptar los permisos a las necesidades o bien adaptarlos en el anfitrión manualmente ([[permisos_y_propietarios_en_volumenes_con_docker-compose|leer]]).
 **WORKDIR** configura el directorio de trabajo, sencillamente es la carpeta donde ejecutaran RUN, CMD, ENTRYPOINT, COPY y ADD sus instrucciones. Si no existe el directorio es creado automáticamente. Puede usarse varias veces y puede ampliarse múltiples veces si la primera inicialización usa una ruta directa y las siguientes relativas. También puede interactuar con  ENV.  Los WORKDIR no crean nuevas capas a la hora de crear imágenes.
@@ Line 169: / Line 194: @@
     --retries=N</code>
-===== Construcción de imágenes Docker mediante eatapas (multi-stage) =====
+===== Construcción de imágenes Docker mediante etapas (multi-stage) =====
 Para poder disponer de imágenes pequeñas se necesita que estas tengan el mínimo indispensables de ficheros para correr la aplicación deseada. Para ello en los Dockerfiles es posible utilizar y trabajar sobre varias imágenes base para que al final, una última imagen pueda copiar los ficheros ya construidos en esas etapas de construcción anteriores (imágenes temporales). Esas imágenes intermedias (etapas de construcción) se reerencian mediante la instrucción **AS** y desaparecen al terminar el proceso de construcción.
@@ Line 232: / Line 257: @@
 Si se puede evitar el uso de root (usuario predeterminado) mejor.
+Utilizar algún sistema de escaneo de vulnerabilidades por ejemplo [[https://github.com/quay/clair|Clair]] o [[https://github.com/docker/docker-bench-security|Docker Bech Security]] pero cada día salen nuevas herramientas / Plugins de Frameworks para dicha finalidad y otras son consideradas "deprecated".
+Nunca debe cambiarse el propietario del socket de docker. Si un usuario no root necesita hacer uso de comandos docker, simplemente se agrega el grupo "docker" al usuario pertinente.
+<code bash>usermod -aG docker ${USER}</code>
+Evitar la activación del modo privilegiado de docker (por defecto desactivado). De necesitarlo deben usarse imágenes oficiales en la medida de lo posible. El uso de la opción "no-new-privileges:true" en estos casos puede ser de interés.
+Para tareas de autenticación, autorización, cifrado,etc es recomendable usar "secretos". Esto permite gestionar ese tipo de información que se necesita en tiempo de ejecución pero que no se quiere almacenar en la imagen de Docker o en el repositorio de código fuente.
 **Crear una imagen con nombre personalizado**.
 <code bash> docker build -t alpine_busi .</code>