Redes en Docker Desktop

Esta página explica cómo Docker Desktop enruta el tráfico de red y la E/S de archivos entre los contenedores, la VM y el host, y cómo este comportamiento es visible para los firewalls y las herramientas de protección de endpoints.

Descripción general

Docker Desktop ejecuta Docker Engine dentro de una máquina virtual (VM) ligera de Linux. Dependiendo de la configuración de tu sistema y sistema operativo, Docker Desktop enruta las operaciones de red y archivos entre la VM de Docker y el host utilizando diferentes componentes de backend.

Componentes del backend y sus responsabilidades

El backend actúa como:

• Proxy de red: Traduce el tráfico entre el host y la VM de Linux.
  • En Windows y Mac, el proceso com.docker.backend se encarga de esto.
  • En Linux, el proceso qemu realiza esta función.
• Servidor de archivos: Gestiona el acceso a archivos de los contenedores al sistema de archivos del host.
  • Al usar gRPC FUSE, el backend realiza la compartición de archivos.
  • Al usar virtiofs, osxfs o krun, el acceso a archivos es gestionado por esos demonios respectivos en lugar de por el proceso de backend.
• Plano de control: Gestiona las llamadas a la API de Docker, el reenvío de puertos y la configuración del proxy.

La siguiente tabla resume las configuraciones típicas con más detalle:

Cómo se conectan los contenedores a internet

Cada contenedor de Linux en Docker Desktop se ejecuta dentro de una pequeña red virtual gestionada por Docker; además, cada contenedor se conecta a una red gestionada por Docker y recibe su propia dirección IP interna. Puedes ver y gestionar estas redes con docker network ls, docker network create y docker network inspect. Se gestionan a través del archivo daemon.json.

Cuando un contenedor inicia una solicitud de red, por ejemplo con apt-get update o docker pull:

• La interfaz eth0 del contenedor se conecta a un puente virtual (docker0) dentro de la VM.
• El tráfico de salida del contenedor se envía a través de la Traducción de Direcciones de Red (NAT) utilizando un adaptador virtual (normalmente con una IP interna como 192.168.65.3). Puedes ver o cambiar esto en los ajustes de Docker Desktop.
• El tráfico se transfiere al sistema host a través de un canal de memoria compartida en lugar de una interfaz de red virtual tradicional. Este enfoque garantiza una comunicación confiable y evita conflictos con los adaptadores de red de nivel de host o las configuraciones de firewall.
• En el host, el proceso de backend de Docker Desktop recibe el tráfico y crea conexiones TCP/IP estándar utilizando las mismas API de red que otras aplicaciones.

Todo el tráfico de red de salida de los contenedores se origina en el proceso com.docker.backend. Los firewalls, las VPN y las herramientas de seguridad, como Crowdstrike, ven el tráfico proveniente de este proceso y no de una VM o de una fuente desconocida, por lo que el software de seguridad de firewall y de endpoint puede aplicar reglas directamente a com.docker.backend.

Cómo funcionan los puertos expuestos

Al publicar un puerto de contenedor utilizando la bandera -p o --publish, Docker Desktop hace que ese puerto sea accesible desde tu sistema host o red local.

Por ejemplo, con docker run -p 80:80 nginx:

• El proceso de backend de Docker Desktop escucha en el puerto del host especificado, en este caso, el puerto 80.
• Cuando una aplicación, como un navegador web, se conecta a ese puerto, Docker Desktop reenvía la conexión a la VM de Linux donde el contenedor se está ejecutando a través de un canal de memoria compartida.
• Dentro de la VM, la conexión se enruta a la dirección IP interna y al puerto del contenedor, por ejemplo 172.17.0.2:80.
• El contenedor responde a través de la misma ruta, por lo que puedes acceder a él desde tu host como a cualquier otro servicio local.

De forma predeterminada, docker run -p escucha en todas las interfaces de red (0.0.0.0), pero puedes restringirlo a una dirección específica, como 127.0.0.1 (localhost) o a un adaptador de red particular. Este comportamiento se puede modificar para enlazar con localhost de manera predeterminada en los ajustes de red de Docker Desktop

Los firewalls del host pueden permitir o denegar las conexiones entrantes filtrando por com.docker.backend.

Usar Docker Desktop con un proxy

Docker Desktop puede usar los ajustes de proxy predeterminados de tu sistema o los ajustes personalizados que configures en la configuración del proxy de Docker Desktop. Todo el tráfico del proxy pasa a través de com.docker.backend.exe.

Cuando se habilita un proxy:

• El proceso de backend reenvía las solicitudes de red, por ejemplo docker pull, a través de un proxy interno en http.docker.internal:3128.
• Luego, el proxy interno se conecta directamente a internet o a través de tu proxy ascendente (upstream), dependiendo de tu configuración, añadiendo autenticación si es necesario.
• A continuación, Docker Desktop descarga las imágenes o los datos solicitados a través del proxy como de costumbre.

Ten en cuenta que:

• El proxy respeta la configuración del proxy del sistema o la configuración manual.
• En Windows, se admite la autenticación Basic, NTLM y Kerberos.
• En Mac, NTLM/Kerberos no se admiten de forma nativa. Como solución alternativa, ejecuta un proxy local en localhost.
• Los plugins de la CLI y otras herramientas que utilicen directamente la API de Docker deben configurarse por separado mediante las variables de entorno HTTP_PROXY, HTTPS_PROXY y NO_PROXY.

Firewalls y visibilidad del endpoint

Para restringir la red de la VM o de los contenedores, aplica reglas a com.docker.backend.exe (Windows), com.docker.backend (Mac) o qemu (Linux), ya que toda la red de la VM se canaliza a través de estos procesos.

Utiliza el Firewall de Windows Defender o los firewalls de endpoints empresariales para el control. Esto te permite inspeccionar y restringir el tráfico a nivel de host sin modificar el motor de Docker.

Crowdstrike y herramientas similares pueden observar todo el tráfico y el acceso a archivos que pasa a través del proceso de backend.