Differences

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

--- guia_rapida_de_dockerfile [2021/03/06 02:16] – [Directivas de un fichero Dockerfile] busindre
+++ guia_rapida_de_dockerfile [2021/05/22 17:16] (current) – [Directivas de un fichero Dockerfile] busindre
@@ Line 115: / Line 115: @@
 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 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>