10 prácticas recomendadas de seguridad para Docker

Aspectos clave de la seguridad de Docker

La seguridad de Docker abarca los aspectos de compilación, ejecución y orquestación de los contenedores Docker. Incluye la seguridad del Dockerfile y de las imágenes base de Docker, así como los aspectos de seguridad durante la ejecución de los contenedores, como los privilegios de usuario, el daemon de Docker y los controles adecuados de CPU para un contenedor, además de otras consideraciones sobre la orquestación de contenedores Docker a gran escala.

La seguridad de los contenedores Docker se puede desglosar en 4 problemas principales:

• Seguridad y prácticas recomendadas para Dockerfile

• Seguridad de los contenedores Docker durante la ejecución

• Riesgos de seguridad de la cadena de suministro con Docker Hub y su impacto en las imágenes de contenedores Docker

• Aspectos de seguridad de la orquestación de contenedores nativos de la nube relacionados con Kubernetes y Helm

10 prácticas recomendadas de seguridad para Docker

1. Prefiere imágenes base mínimas

Un problema común de seguridad de los contenedores Docker es que las imágenes de los contenedores terminan siendo grandes. En general, cuanto más software tenga tu contenedor, mayor será la superficie de ataque potencial. Por eso, el principio siempre debe ser incluir únicamente lo mínimo indispensable que necesita tu aplicación para ejecutarse. Lo más fácil suele ser usar una imagen genérica de contenedor Docker para poner todo en marcha rápidamente. Puede ser una imagen de sistema operativo como Debian o una imagen oficial de entorno de ejecución, como Node. Si tu proyecto no necesita bibliotecas generales del sistema ni utilidades del sistema, es mejor evitar usar un sistema operativo completo como imagen base.

Por naturaleza, las imágenes genéricas de entornos de ejecución contienen todo lo necesario para ejecutar aplicaciones en la mayoría de las circunstancias, y probablemente incluyen grandes cantidades de software que tu aplicación no utiliza. Una práctica recomendada es aprovechar las compilaciones de varias etapas: puedes usar una imagen genérica durante la compilación que incluya las herramientas necesarias y luego transferir la aplicación compilada a una imagen ligera, con un entorno mínimo adecuado para producción. 

También puedes considerar distribuciones de contenedores especializadas, como las imágenes distroless de Google o Alpine Linux, que es mucho más pequeña de forma predeterminada. En lenguajes compilados como Go o C, incluso puedes crear contenedores completamente vacíos especificando scratch en el Dockerfile, ya que este tipo de binarios puede no tener dependencias externas.

2. Usa un usuario con los privilegios mínimos

Cuando un Dockerfile no especifica USER, la ejecución del contenedor usa el usuario root de forma predeterminada. En la práctica, hay muy pocas razones por las que un contenedor deba tener privilegios de root, y esto puede convertirse fácilmente en un problema de seguridad de Docker. Docker ejecuta los contenedores con el usuario root de forma predeterminada. Si ese espacio de nombres se asigna al usuario root del contenedor en ejecución, significa que el contenedor podría tener acceso root al host de Docker. Ejecutar una aplicación en el contenedor con el usuario root facilita la escalada de privilegios si la aplicación es vulnerable a ataques.

Para reducir la exposición, crea un usuario y un grupo dedicados para la aplicación en la imagen Docker; usa la directiva USER en el Dockerfile para asegurarte de que el contenedor ejecute la aplicación con el menor nivel de privilegios posible.

Recuerda que es posible que los usuarios o grupos nuevos no existan en la imagen; asegúrate de crearlos con las instrucciones del Dockerfile.

A continuación se muestra un ejemplo completo de cómo hacerlo con una imagen genérica de Ubuntu:

1FROM ubuntu
2RUN mkdir /app
3RUN groupadd -r lirantal && useradd -r -s /bin/false -g lirantal lirantal
4WORKDIR /app
5COPY . /app
6RUN chown -R lirantal:lirantal /app
7USER lirantal
8CMD node index.js

El ejemplo anterior:

• crea un usuario del sistema (-r) sin contraseña, sin directorio de inicio ni shell

• agrega el usuario que creamos a un grupo existente que habíamos creado previamente (con groupadd)

• agrega un argumento final con el nombre del usuario que queremos crear y asociar con el grupo que creamos

Si prefieres Node.js y las imágenes de Alpine, estas ya incluyen un usuario genérico llamado node. Aquí tienes un ejemplo con Node.js que usa el usuario genérico node:

1FROM node:10-alpine 
2RUN mkdir /app
3COPY . /app
4RUN chown -R node:node /app
5USER node
6CMD [“node”, “index.js”]

Si desarrollas aplicaciones con Node.js, consulta las prácticas recomendadas oficiales para Docker y Node.js.

3. Firma y verifica las imágenes para mitigar los ataques MITM

La autenticidad de las imágenes Docker es un desafío. Confiamos mucho en ellas, ya que literalmente las usamos como contenedores que ejecutan nuestro código en producción. Por eso, es fundamental asegurarse de que la imagen que descargamos sea la que publicó su proveedor y que nadie la haya modificado. La manipulación puede ocurrir durante la transferencia entre el cliente de Docker y el registro, o si alguien vulnera la cuenta del propietario del registro para publicar una imagen maliciosa.

La firma de imágenes y otros artefactos relacionados es un tema clave para proteger la cadena de suministro de software, y las tecnologías en este campo están madurando rápidamente. Actualmente, las dos herramientas más utilizadas para hacerlo son:

• Docker Notary v1, que es la base de la funcionalidad Docker Content Trust (DCT) integrada en Docker CLI

• El proyecto SigStore, que incluye la herramienta cosign para firmar, almacenar y verificar artefactos de forma sencilla.
  

Docker Content Trust

Docker Content Trust (DCT) existe desde hace varios años y permite que los autores de imágenes firmen las etiquetas que publican en servidores de registro de imágenes compatibles con la API de Docker Notary, como DockerHub. Cuando DCT está habilitado en el host de Docker, bloquea la descarga, publicación o ejecución de cualquier imagen cuya firma no se pueda verificar. 

Firmar la imagen de tu contenedor con DCT es sencillo: solo configura la variable de entorno `DOCKER_CONTENT_TRUST=1`. Cuando publiques la imagen en DockerHub o en cualquier otro registro de imágenes compatible con Notary, Docker se encargará de aplicar la firma y almacenarla con la etiqueta de la imagen.

1❯ export DOCKER_CONTENT_TRUST=1                                                                                                                   
2❯ docker push myaccount/myimage:1                                                                                                          
3The push refers to repository [docker.io/myaccount/myimage]
464ab2aa20cf9: Layer already exists 
5b99937123ca0: Layer already exists 
6…
7orig: digest: sha256:c221d4dc80b8a0d3866602020b09722d942157c720273d325a0496a529b5fcab size: 4093
8Signing and pushing trust metadata
9You are about to create a new root signing key passphrase. This passphrase
10will be used to protect the most sensitive key in your signing system. Please
11choose a long, complex passphrase and be careful to keep the password and the
12key file itself secure and backed up. It is highly recommended that you use a
13password manager to generate the passphrase and keep it safe. There will be no
14way to recover this key. You can find the key in your config directory.
15Enter passphrase for new root key with ID 85871b5: 
16Repeat passphrase for new root key with ID 85871b5: 
17Enter passphrase for new repository key with ID e675351: 
18Repeat passphrase for new repository key with ID e675351: 
19Finished initializing "docker.io/ericsmalling/javagoof"
20Successfully signed docker.io/myaccount/myimage:1
21

Al iniciar el contenedor, puedes aplicar la verificación obligatoria de firmas simplemente configurando la misma variable de entorno. Docker CLI rechazará descargar o iniciar una etiqueta de imagen de contenedor que no esté firmada o tenga una firma no válida.

❯ docker run --rm -it myaccount/someapp                                                                                                docker: Error: remote trust data does not exist for docker.io/myaccount/someapp: notary.docker.io does not have trust data for docker.io/myaccount/someapp.
See 'docker run --help'.

Los temas más complejos, como la revocación de claves, se gestionan con la herramienta binaria notary. Para obtener más información sobre Notary v1 y DCT, consulta la documentación oficial.

Sigstore

Las herramientas del proyecto Sigstore buscan abordar no solo las firmas de imágenes de contenedores, sino también las de cualquier otro artefacto que quieras firmar, como una lista de materiales de software (SBOM), certificaciones sobre un artefacto (es decir, metadatos de compilación) o incluso un archivo binario que no sea una imagen, o «blob».

En el caso más sencillo, firmar una imagen es tan fácil como ejecutar el binario `cosign sign` e indicar el registro y la imagen:etiqueta que quieres firmar. El comando correspondiente `cosign verify` validará la firma.

❯ `Generate keypair (do this once):
❯ cosign generate-key-pair                                                                                                                        
Enter password for private key: 
Enter password for private key again: 
Private key written to cosign.key
Public key written to cosign.pub

❯ `Sign the already-pushed image
❯ cosign sign --key cosign.key myaccount/myimage:1                                                                                       Enter password for private key: 
tlog entry created with index: 1234567
Pushing signature to: index.docker.io/myaccount/myimage

Desde la versión v1.9, cosign requiere que generes y administres tus propios pares de claves. Aunque también ofrece el comando `generate-key-pair`, muy fácil de usar (que se muestra arriba), en la próxima versión GA admitirá una función de firma «sin claves». Esta funciona mediante un mecanismo de autorización OpenID Connect (también conocido como OIDC), que genera automáticamente pares de claves efímeras con tu dirección de correo electrónico anotada. Esta función ya está disponible: configura `COSIGN_EXPERIMENTAL=1` antes de ejecutar los comandos `sign` o `verify`.

❯ export COSIGN_EXPERIMENTAL=1
❯ cosign sign myaccount/myimage:1                                                                                                          
Generating ephemeral keys...
Retrieving signed certificate...

        Note that there may be personally identifiable information associated with this signed artifact.
        This may include the email address associated with the account with which you authenticate.
        This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later.
        By typing 'y', you attest that you grant (or have permission to grant) and agree to have this information stored permanently in transparency logs.

Are you sure you want to continue? (y/[N]): y
Your browser will now be opened to:
https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=********************
Successfully verified SCT...
tlog entry created with index: 1234567
Pushing signature to: index.docker.io/myaccount/myimage

Otro aspecto que debes considerar con las firmas de imágenes es cómo ejecutarás los contenedores. Para la mayoría, Kubernetes es la plataforma preferida, pero no ofrece compatibilidad nativa con DCT. Por lo tanto, a menos que uses una distribución específica que lo implemente, tendrás que proporcionar algún tipo de verificación durante la ejecución. Afortunadamente, puedes aprovechar la API del controlador de admisión de Kubernetes para hacerlo, y proyectos de código abierto como Connaisseur pueden gestionar firmas DCT / Notary v1 y Cosign.

4. DETECTA, CORRIGE Y MONITOREA LAS VULNERABILIDADES DE CÓDIGO ABIERTO

Al elegir una imagen base para nuestro contenedor Docker, asumimos indirectamente el riesgo de todas las cuestiones de seguridad de los contenedores que incluye esa imagen. Esto abarca tanto las configuraciones predeterminadas deficientes, que no contribuyen a la seguridad del sistema operativo, como las bibliotecas del sistema incluidas en la imagen base que elegimos.

Un buen primer paso es usar una imagen base lo más mínima posible, siempre que permita ejecutar tu aplicación sin problemas. Esto ayuda a reducir la superficie de ataque al limitar la exposición a vulnerabilidades. Sin embargo, no realiza auditorías por sí sola ni te protege de vulnerabilidades futuras que se descubran en la versión de la imagen base que estés usando.

Por eso, una forma de protegerte contra las vulnerabilidades del software de código abierto es usar herramientas como Snyk para agregar análisis continuo de seguridad de Docker y monitorear las vulnerabilidades que puedan existir en todas las capas de las imágenes Docker que se estén usando.

Analiza una imagen Docker para detectar vulnerabilidades conocidas con estos comandos:

1# fetch the image to be tested so it exists locally
2$ docker pull node:10
3# scan the image with snyk
4$ snyk test --docker node:10 --file=path/to/Dockerfile

Monitorea una imagen Docker para detectar vulnerabilidades conocidas. Cuando se descubran nuevas vulnerabilidades en la imagen, Snyk puede notificarte y ofrecerte recomendaciones para corregirlas:

1$ snyk monitor --docker node:10

Según los análisis realizados por usuarios de Snyk, descubrimos que el 44 % de los análisis de imágenes Docker detectaron vulnerabilidades conocidas para las que había imágenes base más recientes y seguras. Estas recomendaciones de corrección son exclusivas de Snyk y permiten a los desarrolladores tomar medidas y actualizar sus imágenes Docker.

Snyk también descubrió que, en el 20 % de todos los análisis de imágenes Docker, bastaba con volver a compilar la imagen Docker para reducir la cantidad de vulnerabilidades.

¿Cómo auditar la seguridad de los contenedores?

Es fundamental analizar tu proyecto de contenedor basado en Linux para detectar vulnerabilidades conocidas y garantizar la seguridad de tu entorno. Para hacerlo, Snyk analiza la imagen base, los paquetes del sistema operativo (SO) instalados y administrados por el gestor de paquetes, y los binarios clave de las capas que no se instalaron mediante el gestor de paquetes.

Snyk Container, la herramienta de administración de vulnerabilidades de contenedores, ofrece recomendaciones y orientación para corregir problemas en imágenes públicas de Docker Hub. Por ejemplo, recomienda imágenes base e indica en qué capa del Dockerfile se encontró una vulnerabilidad, entre otras cosas.

5. NO EXPONGAS INFORMACIÓN SENSIBLE EN LAS IMÁGENES DOCKER

A veces, al compilar una aplicación dentro de una imagen Docker, necesitas secretos como una clave privada SSH para descargar código de un repositorio privado o tokens para instalar paquetes privados. Si los copias en un contenedor intermedio de Docker, se almacenan en caché en la capa a la que los agregaste, aunque después los elimines. Debes mantener estos tokens y claves fuera del Dockerfile.

Usa compilaciones de varias etapas

Otra forma de mejorar la seguridad de los contenedores Docker es usar compilaciones de varias etapas. Aprovecha la compatibilidad de Docker con este tipo de compilaciones para obtener y administrar secretos en una capa de imagen intermedia que luego se descarta, de modo que ningún dato confidencial llegue a la imagen compilada. Usa código para agregar secretos a esa capa intermedia, como en el siguiente ejemplo:

1FROM ubuntu as intermediate
2
3WORKDIR /app
4COPY secret/key /tmp/
5RUN scp -i /tmp/key build@acme/files .
6
7FROM ubuntu
8WORKDIR /app
9COPY --from=intermediate /app .

Usa los secretos de Docker BuildKit

Usa la función de Docker BuildKit para administrar secretos y montar archivos confidenciales sin almacenarlos en caché, como en el siguiente ejemplo:

1# syntax = docker/dockerfile:1.0-experimental
2FROM alpine
3
4# shows secret from default secret location
5RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecre
6
7# shows secret from custom secret location
8RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar

Lee más sobre los secretos de compilación de Docker en su sitio.

Ten cuidado con la copia recursiva

También debes tener cuidado al copiar archivos a la imagen que estás compilando. Por ejemplo, el siguiente comando copia toda la carpeta de contexto de compilación, de forma recursiva, en la imagen Docker, lo que podría incluir también archivos confidenciales:

1COPY . .

Si tienes archivos confidenciales en tu carpeta, elimínalos o usa .dockerignore para excluirlos:

1private.key
2appsettings.json

¿Cómo proteger un contenedor Docker?

Asegúrate de usar compilaciones de varias etapas para que la imagen del contenedor creada para producción no incluya recursos de desarrollo, secretos ni tokens.

Además, asegúrate de usar una herramienta de seguridad para contenedores que analice tus imágenes de Docker desde la CLI, directamente desde Docker Hub o las que estén implementadas en producción mediante Amazon ECR, Google GCR u otros servicios.

6. Usa etiquetas fijas para garantizar la inmutabilidad

Cada imagen de Docker puede tener varias etiquetas, que son variantes de la misma imagen. La etiqueta más común es latest, que representa la versión más reciente de la imagen. Las etiquetas de las imágenes no son inmutables, y quien las publica puede usar la misma etiqueta varias veces.

Esto significa que la imagen base de tu archivo Docker puede cambiar entre compilaciones. Esto podría generar un comportamiento inconsistente debido a los cambios en la imagen base. Hay varias formas de mitigar este problema y mejorar la seguridad de Docker:

• Prefiere la etiqueta más específica disponible. Si la imagen tiene varias etiquetas, como :8 y :8.0.1 o incluso :8.0.1-alpine, prefiere la última, ya que es la referencia más específica de la imagen. Evita las etiquetas más genéricas, como latest. Ten en cuenta que una etiqueta específica que hayas fijado podría eliminarse con el tiempo.

• Para mitigar el problema de que una etiqueta específica de imagen deje de estar disponible y se convierta en un obstáculo para los equipos que dependen de ella, considera mantener una copia local de esa imagen en un registro o una cuenta bajo tu control. Es importante tener en cuenta el esfuerzo de mantenimiento que esto requiere, ya que tendrás que mantener un registro. Replicar la imagen que quieres usar en un registro propio es una buena práctica para asegurarte de que no cambie.

• Sé muy específico. En lugar de descargar una etiqueta, descarga una imagen usando la referencia SHA256 específica de la imagen de Docker, que garantiza que obtengas la misma imagen cada vez. Sin embargo, ten en cuenta que usar una referencia SHA256 puede ser arriesgado: si la imagen cambia, es posible que ese hash deje de existir.

¿Son seguras las imágenes de Docker?

Las imágenes de Docker pueden basarse en distribuciones de Linux de código abierto e incluir software y bibliotecas de código abierto. Una investigación reciente de Snyk sobre el estado de la seguridad del código abierto encontró que las imágenes de Docker más populares contienen al menos 30 vulnerabilidades.

7. Usa COPY en lugar de ADD

Docker ofrece dos comandos para copiar archivos del host a la imagen de Docker durante la compilación: COPY y ADD. Las instrucciones son similares, pero tienen distintas funciones y pueden generar problemas de seguridad en los contenedores de Docker:

• COPY: copia archivos locales de forma recursiva, con archivos o directorios de origen y destino explícitos. Con COPY, debes declarar las ubicaciones.

• ADD: copia archivos locales de forma recursiva, crea implícitamente el directorio de destino si no existe y acepta archivos comprimidos como origen, ya sea desde una ubicación local o una URL remota. En el primer caso, los descomprime en el directorio de destino; en el segundo, los descarga.

Aunque sutiles, las diferencias entre ADD y COPY son importantes. Tenlas en cuenta para evitar posibles problemas de seguridad:

• Si se usan URL remotas para descargar datos directamente en una ubicación de origen, podrían producirse ataques de intermediario que modifiquen el contenido del archivo descargado. Además, es necesario validar el origen y la autenticidad de las URL remotas. Al usar COPY, el origen de los archivos descargados desde URL remotas debe declararse mediante una conexión TLS segura y también debe validarse.

• Consideraciones sobre el espacio y las capas de imagen: usar COPY permite separar la incorporación de un archivo comprimido desde una ubicación remota de su descompresión en distintas capas, lo que optimiza la caché de la imagen. Si necesitas archivos remotos, puedes combinarlos en un solo comando RUN que los descargue, extraiga y elimine después. Así se optimiza una operación de una sola capa, en lugar de usar varias capas como sería necesario con ADD.

• Cuando se usan archivos comprimidos locales, ADD los extrae automáticamente en el directorio de destino. Aunque esto puede ser aceptable, conlleva el riesgo de bombas zip y vulnerabilidades Zip Slip, que podrían activarse automáticamente.

8. Usa etiquetas de metadatos

Las etiquetas de imagen proporcionan metadatos sobre la imagen que estás compilando. Esto ayuda a los usuarios a entender fácilmente cómo usarla. La etiqueta más común es “maintainer”, que especifica el nombre y la dirección de correo electrónico de quien mantiene la imagen. Agrega metadatos con el siguiente comando LABEL:

1LABEL maintainer="me@acme.com"

Además del contacto de mantenimiento, agrega cualquier metadato que sea importante para ti. Por ejemplo, un hash de confirmación, un enlace a la compilación correspondiente, el estado de calidad (¿se aprobaron todas las pruebas?), el código fuente, una referencia a la ubicación de tu archivo SECURITY.TXT y más.

Al agregar etiquetas, es una buena práctica adoptar un archivo SECURITY.TXT (RFC5785) que dirija a tu política de divulgación responsable para el esquema de etiquetas de Docker, como el siguiente:

1LABEL securitytxt="https://www.example.com/.well-known/security.txt"

Consulta más información sobre las etiquetas para imágenes de Docker.

9. Usa compilaciones de varias etapas para crear imágenes de Docker pequeñas y seguras

Al compilar tu aplicación con un Dockerfile, se crean muchos artefactos que solo son necesarios durante la compilación. Pueden ser paquetes, como herramientas y bibliotecas de desarrollo necesarias para compilar, dependencias necesarias para ejecutar pruebas unitarias, archivos temporales, secretos y más.

Mantener estos artefactos en la imagen base, que podría usarse en producción, aumenta el tamaño de la imagen de Docker. Esto puede alargar considerablemente el tiempo de descarga y ampliar la superficie de ataque, ya que se instalan más paquetes. Lo mismo ocurre con la imagen de Docker que usas: podrías necesitar una imagen específica para compilar, pero no para ejecutar el código de tu aplicación.

Golang es un excelente ejemplo. Para compilar una aplicación en Golang, necesitas el compilador de Go. El compilador produce un ejecutable que funciona en cualquier sistema operativo, sin dependencias, incluso en imágenes scratch.

Por eso Docker ofrece la capacidad de compilar en varias etapas. Esta función te permite usar varias imágenes temporales durante el proceso de compilación y conservar solo la imagen final junto con la información que copiaste en ella. De este modo, tienes dos imágenes:

• Primera imagen: una imagen muy grande, con muchas dependencias que se usan para compilar tu aplicación y ejecutar pruebas.

• Segunda imagen: una imagen muy pequeña, tanto en tamaño como en cantidad de bibliotecas, que contiene solo una copia de los artefactos necesarios para ejecutar la aplicación en producción.

10. Usa un linter

Usa un linter para evitar errores comunes y establecer buenas prácticas que los ingenieros puedan seguir de forma automatizada. Es una tarea útil de análisis de seguridad de Docker para detectar de forma estática problemas de seguridad en Dockerfile.

Un ejemplo de linter es hadolint. Analiza un Dockerfile y muestra advertencias sobre cualquier error que no cumpla sus reglas de buenas prácticas.

Hadolint es aún más potente cuando se usa en un entorno de desarrollo integrado (IDE). Por ejemplo, al usar hadolint como extensión de VSCode, los errores de lint aparecen mientras escribes. Esto te ayuda a escribir mejores Dockerfiles más rápido.

¿Cómo se refuerza la seguridad de una imagen de contenedor de Docker?

Puedes usar linters como hadolint o dockle para asegurarte de que el Dockerfile tenga una configuración segura. Asegúrate también de analizar tus imágenes de contenedor para evitar vulnerabilidades con un impacto grave en la seguridad de tus contenedores de producción. 

¿Docker representa un riesgo de seguridad?

Docker es una tecnología de virtualización de software que ha ganado popularidad y se ha adoptado ampliamente. Al compilar e implementar con Docker, debemos aplicar buenas prácticas de seguridad para mitigar riesgos como las vulnerabilidades incluidas en las imágenes base de Docker o las filtraciones de datos causadas por contenedores de Docker mal configurados.

¿Cómo protejo un contenedor de Docker?

Sigue las buenas prácticas de seguridad de Docker para asegurarte de usar imágenes base de Docker con pocas o ninguna vulnerabilidad conocida, aplicar configuraciones seguras en Dockerfile y monitorear los contenedores implementados para detectar cualquier diferencia entre las imágenes de desarrollo y las de producción. Además, asegúrate de seguir las buenas prácticas de Infrastructure as Code para las soluciones de orquestación de contenedores.

Seguridad de Docker: recursos adicionales

Para terminar, si quieres mantenerte al día con las buenas prácticas de seguridad para crear imágenes de Docker optimizadas para Node.js y Java:

1. ¿Eres desarrollador de Java? Este recurso te será útil: Docker para desarrolladores de Java: 5 cosas que debes saber para no poner en riesgo tu seguridad

2. 10 buenas prácticas para crear un contenedor de Java con Docker: una excelente guía detallada sobre cómo crear contenedores para aplicaciones de Java listos para producción.

3. 10 buenas prácticas para crear aplicaciones web de Node.js en contenedores con Docker: si eres desarrollador de Node.js, te encantará esta guía paso a paso para crear imágenes base de Docker eficientes y seguras para tus aplicaciones de Node.js.