Se preparó una traducción del artículo específicamente para estudiantes del curso de seguridad de Linux .
En este artículo, nos gustaría centrarnos en Docker y discutir consejos y trucos que proporcionan un proceso más seguro y de alta calidad para procesar imágenes de Docker.
Entonces, comencemos con nuestra lista de 10 mejores prácticas de seguridad de imagen de Docker.
1. Prefiere imágenes básicas mínimas
A menudo puede iniciar proyectos con una imagen básica de contenedor Docker, por ejemplo, escribiendo un
Dockerfile con el
FROM node "por defecto". Sin embargo, al especificar una imagen de nodo, tenga en cuenta que la distribución Debian Stretch completamente instalada es la imagen base que se utiliza para construirla. Si su proyecto no requiere ninguna biblioteca o utilidad de sistema común, es mejor evitar el uso de un sistema operativo (SO) completamente funcional como imagen base.
En
el Informe de estado de seguridad de código abierto Snyk 2019, encontramos que muchos de los contenedores Docker populares que aparecen en el sitio web de Docker Hub contienen imágenes que contienen muchas vulnerabilidades conocidas. Por ejemplo, cuando usa la popular imagen universal de
docker pull node , en realidad ingresa el sistema operativo en su aplicación, que, como sabe, tiene 580 vulnerabilidades en las bibliotecas de su sistema.
Como puede ver en el informe de seguridad, cada una de las diez imágenes Docker más populares que probamos en Docker Hub contenía vulnerabilidades conocidas. Al preferir imágenes mínimas que combinan solo las herramientas del sistema y las bibliotecas necesarias para ejecutar su proyecto, también minimiza el espacio para que los atacantes ataquen y se asegura de proporcionar un sistema operativo seguro.
MÁS INFORMACIÓN SOBRE LA SEGURIDAD DE SUS IMÁGENES2. Usuario menos privilegiado
Cuando el
Dockerfile no especifica
USER , el contenedor se ejecuta de forma predeterminada como usuario root. En la práctica, hay muy pocas razones por las cuales un contenedor debe tener privilegios de root. Docker inicia los contenedores de forma predeterminada con el usuario root. Luego, cuando este espacio de nombres se asigna al usuario root en un contenedor en ejecución, se deduce que el contenedor potencialmente tiene acceso root en el host Docker. Ejecutar la aplicación en un contenedor con un usuario root expande aún más el espacio de ataque y proporciona una manera fácil de elevar los privilegios si la aplicación en sí misma es vulnerable a ataques.
Para minimizar la exposición, habilite la creación de un usuario y grupo dedicado en la imagen de Docker para la aplicación; use la directiva
USER en el
Dockerfile para verificar que el contenedor inicie la aplicación con el acceso menos privilegiado.
Un usuario dedicado puede no existir en la imagen; cree este usuario utilizando las instrucciones en el
Dockerfile .
El siguiente es un ejemplo completo de cómo hacer esto para una imagen universal de Ubuntu:
FROM ubuntu RUN mkdir /app RUN groupadd -r lirantal && useradd -r -s /bin/false -g lirantal lirantal WORKDIR /app COPY . /app RUN chown -R lirantal:lirantal /app USER lirantal CMD node index.js
Ejemplo anterior:
- crea un usuario del sistema (-r) sin contraseña, sin instalar un directorio de inicio y sin shell
- agrega el usuario que creamos al grupo existente que creamos de antemano (usando groupadd)
- agrega el último argumento al nombre del usuario que queremos crear, en combinación con el grupo que creamos
Node.js e imágenes alpinas, ya incluyen un usuario genérico llamado
node . Aquí hay un ejemplo de Node.js que usa el nodo de usuario genérico:
FROM node:10-alpine RUN mkdir /app COPY . /app RUN chown -R node:node /app USER node CMD [“node”, “index.js”]
Si está desarrollando aplicaciones Node.js, puede consultar las
mejores prácticas oficiales de
Docker y Node.js.3. Firme y verifique las imágenes para evitar ataques MITM
La autenticidad de las imágenes de Docker es un problema. Confiamos en estas imágenes porque las usamos literalmente como un contenedor que ejecuta nuestro código en producción. Por lo tanto, es importante asegurarse de que la imagen que utilizamos sea exactamente la que ofrece el editor, y que ninguna de las partes la haya cambiado. La falsificación puede ocurrir a través de una conexión por cable entre el cliente Docker y el registro, o pirateando el registro de la cuenta del propietario para reemplazar la imagen.
Validar una imagen de Docker
La configuración predeterminada de Docker le permite recuperar imágenes de Docker sin verificar su autenticidad, lo que podría conducir al uso de imágenes de Docker cuyo origen y autor no están verificados.
Se recomienda que siempre verifique las imágenes antes de usarlas, independientemente de la política. Para experimentar con la validación, habilite temporalmente Docker Content Trust con el siguiente comando:
export DOCKER_CONTENT_TRUST=1
Ahora intente extraer la imagen sobre la que sabe que no está firmada: la solicitud será rechazada y la imagen no se recibirá.
Imágenes Docker exclusivas
Prefiera las imágenes
certificadas por Docker de socios confiables que hayan sido verificados y supervisados por Docker Hub en lugar de imágenes cuyo origen y autenticidad no pueda verificar.
Docker le permite firmar imágenes y, por lo tanto, proporciona otro nivel de protección. Para firmar imágenes, use
Docker Notary . Notary comprueba la firma de la imagen por usted y bloquea el inicio de la imagen si la firma de la imagen no es válida.
Cuando Docker Content Trust está habilitado, como mostramos anteriormente, el ensamblaje de la imagen de Docker firma la imagen. Cuando la imagen se inicia por primera vez, Docker crea y almacena la clave privada en
~/docker/trust para su usuario. Esta clave privada se usa para firmar cualquier imagen adicional a medida que se crea.
Para obtener instrucciones detalladas sobre cómo configurar imágenes firmadas, consulte la
documentación oficial de Docker .
4. Encuentra, repara y rastrea vulnerabilidades en componentes de código abierto
Cuando seleccionamos la imagen base para nuestro contenedor Docker, indirectamente corremos el riesgo de todos los problemas de seguridad con los que está asociada la imagen base. Estas pueden ser configuraciones predeterminadas mal configuradas que no contribuyen a la seguridad del sistema operativo, así como las bibliotecas del sistema asociadas con la imagen base que hemos elegido.
Un buen primer paso es utilizar la imagen básica mínima posible para ejecutar la aplicación sin problemas. Esto ayuda a reducir el espacio de ataque al limitar la vulnerabilidad; Por otro lado, no realiza ninguna de sus propias comprobaciones y no lo protege de futuras vulnerabilidades que puedan identificarse para la versión utilizada de la imagen base.
Por lo tanto, una forma de protegerse contra las vulnerabilidades en el software de código abierto es usar herramientas como Snyk para agregar un escaneo continuo y un seguimiento de las vulnerabilidades que pueden existir en todas las capas de imágenes Docker utilizadas.
Una imagen de Docker se escanea en busca de vulnerabilidades conocidas mediante estos comandos:
La imagen de Docker se supervisa para detectar vulnerabilidades conocidas, de modo que después de descubrir nuevas vulnerabilidades en la imagen de Snyk, puede notificar y proporcionar recomendaciones para corregirla de la siguiente manera:
$ snyk monitor --docker node:10
Según el escaneo realizado por los usuarios de Snyk, encontramos que el 44% de los escaneos de imágenes de Docker revelaron vulnerabilidades conocidas y para las cuales había disponibles imágenes básicas más nuevas y más seguras. Esta consulta de reparación, mediante la cual los desarrolladores pueden tomar medidas y actualizar sus imágenes de Docker, es exclusiva de Snyk.
Snyk también descubrió que para el 20% de todos los escaneos de imágenes de Docker, simplemente reconstruya la imagen de Docker para
reducir las vulnerabilidades . Obtenga más información sobre la cantidad de informes de seguridad abiertos de 2019 en el blog de Snyk.
El final de la primera parte.
Continúa en la segunda parte , y ahora invitamos a todos a un seminario web gratuito sobre el tema: "vulnerabilidades de Docker. Escapar del contenedor al host con la escalada de privilegios " .