Como ya vimos en el capítulo 6 la orden ADD funciona como una copia recursiva desde el origen hasta la carpeta destino en el contenedor, creando los directorios  en caso de que no existan. Esta copia recursiva puede ser desde un contenido local o desde una URL y además si le pasamos un archivo comprimido a la orden ADD los descomprime de manera automática.  Pero en caso de que este contenido venga de una URL:

• ¿Confiamos realmente en los autores?
• ¿Cómo sabemos que los contenidos no han sido comprometidos a nivel de seguridad en el origen?
• ¿Nos hemos protegido frente a ataques Man-In-The-Middle?.

Todo estos aspectos deben de ser tenidos en cuenta.

Al igual que ADD, COPY hace una copia recursiva desde el origen hasta el destino pero no permite ni URL de origen ni descomprime los ficheros. Si copiamos un archivo .zip este permanecerá como un archivo .zip. Esta vez el problema reside en ambos casos en la recursividad de la copia.

Cuando copiamos elementos de forma recursiva incrementamos  la posibilidad de que suceda lo siguiente:

• Aumentar  el tamaño de la imagen de manera innecesaria, tal y como dijimos anteriormente.
• Copiar en el contenedor ficheros  sensibles que contengan claves, tokens de APis etc...

En ambos casos tenemos que tener un fichero .dockerignore debidamente configurado y  que excluya explícitamente del proceso de copia recursiva archivos con claves como *.ENV, *.pem etc..

El contenido del fichero .dockerignore funciona de manera análoga al fichero .gitignore, tal y como hemos comentado a lo largo del curso. Una descripción más detallada de los contenidos que podemos escribir en este archivo la podéis encontrar aquí.

Como norma general los procesos que se ejecutan en un contenedor (al igual que en otros sistemas) no deben ejecutarse como root, en especial aquellos que son  servicios expuestos al exterior.

¿Por qué es importante esto?

Desde el punto de vista de seguridad una buena práctica es  que las aplicaciones únicamente tengan acceso a los recursos que necesitan para desempeñar sus funciones (PRINCIPIO DEL MÍNIMO PRIVILEGIO). Si no lo  hacemos así y ejecutamos aplicaciones como root esa aplicación podrá realizar cualquier operación en nuestro sistema, por ejemplo:

• Realizar operaciones no permitidas como borrar ficheros, parar servicios y transferir información.
• Acceder a ficheros con contenido sensible que hayamos podido colocar en el contenedor, por ejemplo usando un bind mount.

Debemos de tener en cuenta que estamos usando imágenes de terceros y  confiando en las aplicaciones que vienen en dicha  imágenes. Debemos confiar,  pero siempre ser cautos y comprobar  si esa  aplicación que vamos a usar está actualizada desde el punto de vista de la seguridad.

¿ Cómo evito esto en mi Dockerfile?

Puedo afrontar este tipo de problemas desde un Dockerfile siguiendo este flujo de trabajo cuando lo estoy creando:

1.  Crear un usuario y un grupo para ese usuario (RUN).
2. Ejecutar todas las instrucciones del Dockerfile que tengan que ser realizadas como root (RUN, COPY, ADD,WORKDIR  etc....).
3. De manera previa a ejecutar el ENTRYPOINT y/o el CMD cambiar el usuario de ejecución de las órdenes al usuario creado previamente (USER).
4. Definir el ENTRYPOINT y/o CMD y que esa órdenes lances procesos pertenecientes al usuario creado.

Un ejemplo de esta estrategia: