A lo largo de todos los capítulos hemos descargado multitud de imágenes desde DockerHub. Estas imágenes son el elemento fundamental sobre el que hemos desarrollado todo el curso pero si no tenemos cuidado pueden representar un posible riesgo de seguridad ya que, normalmente son imágenes realizadas por terceros y, por lo tanto, no tenemos ningún control sobre ellas.
Este aspecto no es tan importante si las usamos únicamente para el desarrollo pero adquiere mucha más relevancia si tenemos pensado llevar esos contenedores a producción.
Para intentar minimizar los riesgos de usar imágenes hay que seguir una serie de pautas generales:
Intentar siempre usar una imagen de un usuario verificado o una imagen publicada por la propia empresa Docker.
Verificar la integridad de la imagen que nos descargamos.
Intentar usar imágenes que tengan lo mínimo.
Restringir los privilegios de los datos a los que pueden acceder los contenedores.
En caso de crear nuestras propias imágenes pagar por el servicio de DockerHub "Vulnerability Scanner" o utilizar herramientas que sirve para ese mismo propósito.
USUARIOS VERIFICADOS E IMÁGENES OFICIALES DE LA EMPRESA DOCKER
Aunque no es una garantía al 100%, el hecho de descargar este tipo de imágenes ayuda a reducir los posibles riesgos que puedan existir. Para obtener este tipo de imágenes, cuando hacemos una búsqueda debemos activar los filtros adecuados:
Docker utiliza un mecanismo de firma digital llamado DCT (Docker's Content Trust) para verificar la INTEGRIDAD y la AUTORÍA de las imágenes que nos descargamos desde DockerHub. Por defecto el mecanismo DCT está deshabilitado y cuando hacemos docker pull podemos descargar imágenes sin verificar ni la integridad ni la autoría.
Si habilitamos DCT solo podré hacer PULL / RUN / BUILD con imágenes"Trusted"salvo que explícitamente haga alguna excepción añadiendo el flag ---disable-content-trust a la ejecución de dichas órdenes.
Si quiero habilitarlo tengo que poner la variable de entorno DOCKER_CONTENT_TRUST=1. A partir de entonces no podré descargarme imágenes no firmadas, incluso aunque sean mías.En Linux esto se realiza de la siguiente manera:
# Añado la siguiente línea al final del fichero .bashrc que sirve para añadir esa variable de entorno
export DOCKER_CONTENT_TRUST=1
# Recargo el .bashrc
> source /home/miusuario/.bashrc
IMPORTANTE: El procedimiento en Windows y Mac para establecer variables de entorno es diferente.Si no quiero crear la variable de entorno puedo añadir DOCKER_CONTENT_TRUST=1 delante de la orden docker para conseguir el mismo efecto.
FIRMA DIGITAL DE MIS IMÁGENES
Si quiero firmar digitalmente mis imágenes tengo que seguir los siguientes pasos:
Generar la parejas de claves público/privada. La privada se coloca en ~/.docker/trust/private
Compartir mi clave pública con el servidor Notary asociado a DockerHub. Notary es una herramienta que me permite publicar contenidos confiables asegurando la integridad de dicho contenido y la autoría del mismo. Si utilizara otro registro diferente a DockerHub el hecho de tener un servicio Notary es requisito para poder firmar las imágenes en ese registro.TENGO QUE GENERAR UNA CLAVE PÚBLICA PARA CADA REPOSITORIO (Colección de versiones de la misma imagen).
Firmar la imagen. Este proceso firma y a la vez hace un push.
# 1. Generar la pareja de claves
> docker trust key generate miclave.pub
# 2. Comparto mi clave pública con el servidor Notary en el repositorio para las imágenes del respositorio usuario/nombreimagen. En nombre del firmante es miclave y miclave.pub es la clave pública generada en el proceso anterior. Recordad que un mismo repositorio puede contener varias versiones (TAGS) de una misma imagen.
Cuando estamos construyendo imágenes debemos intentar que sean imágenes de un tamaño mínimo. ¿Qué sentido tiene usar un sistema operativo entero si solo queremos instalar una aplicación o un servicio?.
Cada aplicación nueva que instalamos añade un potencial punto de inseguridad y nos obliga a estar atentos para actualizar a una nueva versión cuando surja una vulnerabilidad.
Dos buenas prácticas en este sentido son:
Si estamos construyendo nuestra propia imagen usaremos una imagen de base que sea de tamaño mínimo. Un ejemplo es bitnami/minideb. . También es cierto que a lo largo del curso hemos utilizado imágenes de terceros con un único servicio ya instalado. Normalmente estas imágenes ya están pulidas y no tienen mas que lo necesario.
Usar el fichero .dockerignore en nuestro proceso de build. Así evitamos que nuestra imagen tenga más tamaño del necesario.
RESTRICCIÓN DE PRIVILEGIOS
Cuando hablamos de restricción de privilegios nos referimos a los permisos que el contenedor va a tener en el acceso a los volúmenes montados, bind mounts o a ciertos directorios del propio contenedor.
Si vamos a usar un volumen o un bind mount en el que no queremos que se pueda escribir desde el contenedor podemos hacerlo añadiendo la opción readonly al flag --mount. Por ejemplo:
# Realizo un bind mount evitando que desde el contenedor se pueda escribir en mi carpeta:
> docker run -it --mount type=bind,src=/home/pekechis/pruebaPHP,dst=/var/www/html,readonly -p 8686:80 php:7.4-apache
Pero si por el contrario quiero evitar que se escriba en una carpeta propia del contenedor tengo que usar el flag --read-only de la orden docker run. El contenedor no podrá realizar ningún tipo de escritura en su sistema de ficheros. Por ejemplo:
# Arranco un contenedor en modo solo lectura.
> docker run -it --read-only ubuntu:20.04 /bin/bash
SERVICIO "VULNERABILITY SCANNER"
Para cuentas de pago DockerHub proporciona un servicio que escanea las imágenes para encontrar vulnerabilidades tanto a nivel de sistema operativo como a nivel de las posibles aplicaciones que tengamos instaladas en dichas imágenes. Para activar este servicio tenemos que cambiar de plan y aplicarlo a cada una de las imágenes que queramos escanear desde la sección de administración del repositorio de la imagen:
