Riesgos de la red host de Docker: cuándo merece la pena y cómo limitar el daño

Qué hace realmente la red host (y qué elimina silenciosamente)

En el networking normal de Docker, los contenedores viven en sus propios espacios de nombres de red. Obtienen interfaces virtuales, IP privadas y normalmente acceden al exterior vía NAT. Los puertos publicados se gestionan mediante una combinación de reglas de iptables/nftables y a veces un proxy en espacio de usuario. El contenedor es un inquilino. El host es el edificio.

Con --network host, mueves el contenedor al espacio de nombres de red del host. No hay par veth. No hay IP separada para el contenedor. No hay puente de Docker para ese contenedor. El contenedor ve las interfaces del host, la tabla de enrutamiento del host y los puertos en escucha del host. Un proceso dentro del contenedor que se enlaza a 0.0.0.0:8080 se está enlazando en el host.

Esto no es “solo una red más rápida”. Es un intercambio en aislamiento. Estás eludiendo una porción importante del límite del contenedor, lo que significa:

• Sin red de seguridad para publicación de puertos. Docker no puede mediar la exposición con -p. El proceso decide qué escuchar y dónde.
• Los conflictos de puerto se vuelven fallos inmediatos. Dos contenedores no pueden escuchar el mismo puerto del host sin coordinación.
• Las expectativas del firewall cambian. Ya no tratas con traducción contenedor→host vía cadenas DOCKER; el tráfico es simplemente… tráfico del host.
• La observabilidad se complica. “¿Qué contenedor posee ese socket?” pasa a ser una pregunta forense en lugar de una consulta de CLI.
• Los límites de seguridad se adelgazan. La aislación por espacio de nombres de red desaparece; otras protecciones siguen aplicando (cgroups, mount namespaces, seccomp, capabilities), pero has eliminado una capa significativa.

En Linux, la red host es directa porque los network namespaces son una función del kernel de Linux. En Docker Desktop (Mac/Windows), “red host” no es el mismo animal; se ejecuta dentro de una VM y se comporta de forma diferente. En producción, la mayor parte del dolor (y la velocidad) está en Linux.

La cita que deberías recordar

Werner Vogels (idea parafraseada): “Todo falla, todo el tiempo.” Si tratas la red host como “segura porque es rápida”, estás presupuestando tiempo de inactividad.

Broma corta #1: La red host es como darle al contenedor la llave maestra del edificio—genial hasta que empieza a “reorganizar” las puertas.

Cuándo merece la pena usar la red host

No estoy aquí para moralizar. La red host es una herramienta. A veces es la herramienta adecuada.

1) Rutas de paquetes de alto rendimiento donde importa la sobrecarga de NAT/bridge

Si estás manejando muchos paquetes por segundo o recortando latencia, eliminar la ruta veth/bridge/NAT puede ayudar. Piensa en recolectores de telemetría, balanceadores L4 o appliances de red especializados ejecutándose como contenedores. La red host también evita la presión de conntrack por NAT en algunas configuraciones.

Pero: si “necesitas red host por rendimiento”, demuéstralo. Métricas antes y después. En la mayoría de cargas web, el cuello de botella no es el bridge de Docker; es TLS, llamadas al sistema, GC, llamadas a la base de datos o la ineficiencia de la aplicación.

2) Necesitas participar en el enrutamiento a nivel host o en daemons de routing

Algunos demonios esperan enlazarse a puertos conocidos en interfaces específicas o interactuar con el enrutamiento del host de forma que es incómoda a través de un bridge. Ejemplos: hablantes BGP, comportamientos tipo VRRP o software que manipula rutas y espera visibilidad del host.

3) Entornos de laboratorio simples y despliegues “un servicio por máquina”

Si una máquina está dedicada a un servicio containerizado y la tratas como un servidor “pet” (lo sé), la red host puede reducir la fricción de configuración. Tienes menos piezas móviles: sin mapeo de puertos, menos casos límite de networking de Docker, menos “¿por qué no puedo alcanzarlo desde esa VLAN?” en la depuración.

4) Agentes de monitorización que deben ver la red del host

Algunas herramientas de monitorización de red, captura de paquetes, IDS o exportadores de flujo necesitan adjuntarse a interfaces reales del host. La red host es una forma. Otra es --cap-add NET_ADMIN más acceso a dispositivos específicos; pero es común ver la red host usada para estos agentes.

Cuándo no merece la pena

• Hosts multi-tenant. Si ejecutas muchos servicios por host, la red host aumenta la probabilidad de exposición accidental y conflictos de puertos.
• Cualquier cosa con entrada no confiable. Endpoints HTTP públicos, parsers, gateways de protocolo. Quieres capas, no menos capas.
• Cualquier cosa que quieras mover rápidamente. La red host a menudo incorpora suposiciones sobre interfaces y puertos del host, lo que ralentiza migraciones.
• Cuando “lo arregló una vez”. Usar la red host como superstición es cómo terminas con una plataforma frágil.

Los riesgos reales: aislamiento, radio de impacto y “ups, eso es el host”

Riesgo #1: Eludes el modelo de publicación de puertos de Docker

Con el networking en bridge, -p 127.0.0.1:8080:8080 es una declaración explícita y útil. Con la red host, no existe “publicar”. El proceso se enlaza; el host escucha. Si la app se enlaza a 0.0.0.0, es accesible en todas las interfaces que tenga el host: VLANs de producción, VLANs de gestión, VPNs, lo que sea.

Así es como puertos administrativos internos se convierten en incidentes externos. No por malicia. Por valores predeterminados.

Riesgo #2: La política de firewall a nivel host se convierte en la única puerta real

En una configuración típica con bridge, verás las cadenas DOCKER y DOCKER-USER mediando el tráfico. Con la red host, el tráfico del contenedor es tráfico del host. Eso está bien si tu firewall del host es estricto. Es catastrófico si tu firewall del host es “lo añadiremos después”.

Riesgo #3: Conflictos de puertos y arranques no deterministas

En un host ocupado, dos servicios pueden “funcionar en staging” porque el orden de arranque difiere, y luego fallar en producción porque algo más se enlazó primero. No es teórico. Es el tipo de fallo que obtienes a las 2 AM porque un nodo se reinició y systemd arrancó cosas en un orden ligeramente distinto.

Riesgo #4: La observabilidad y la atribución se complican

Con networking en bridge, puedes decir “el contenedor X posee 172.17.0.5:9000”. Con la red host, dices “algo en el host posee :9000”, y ahora estás indagando en árboles de procesos, cgroups y metadatos de contenedores para averiguarlo. Eso ralentiza la respuesta a incidentes.

Riesgo #5: Algunas protecciones siguen existiendo, pero no te engañes

La red host no te concede automáticamente root en el host. Los namespaces de mounts, PIDs, usuarios y cgroups siguen importando. Seccomp sigue importando. Capabilities siguen importando. Pero la frontera de red es un lugar común para aplicar el principio de mínimo privilegio. La has eliminado.

Riesgo #6: “Localhost” ya no es local al contenedor

Dentro de un contenedor en red host, 127.0.0.1 es el loopback del host. Eso significa:

• El contenedor puede alcanzar servicios del host ligados a localhost (si no están restringidos de otra manera).
• Si el contenedor se enlaza a localhost, también se está enlazando al loopback del host, pudiendo colisionar con otros servicios locales.

Broma corta #2: La forma más rápida de “reducir la latencia” es eliminar tu firewall. Por favor, no midas así.

Datos interesantes y breve historia (para contexto, no para la noche de trivia)

1. Los network namespaces de Linux llegaron al kernel en 2008 (alrededor de la era 2.6.24), permitiendo pilas de red por proceso sin máquinas virtuales completas.
2. Docker originalmente dependía mucho de iptables para la publicación de puertos, por eso las redes de Docker y las reglas de firewall han estado entrelazadas desde los primeros días.
3. Existió un “proxy en espacio de usuario” para manejar casos límite (como conexiones hairpin), y con el tiempo muchas implementaciones migraron a rutas NAT en kernel para reducir la sobrecarga.
4. Conntrack es un recurso compartido: cuando NATeas mucho tráfico de contenedores, apuestas tu clúster a una tabla de estados finita en el kernel.
5. La red host es anterior a Docker: runtimes de contenedores y jails ofrecían modos de “pila compartida” mucho antes de que fuera una bandera en Docker.
6. En Kubernetes, hostNetwork: true tiene tradeoffs similares; los riesgos no son específicos de Docker, son específicos del espacio de nombres.
7. Algunos CNIs evitan NAT por completo al enrutar IPs de pods, razón por la cual “red host por rendimiento” no siempre es la comparación correcta.
8. Los firewalls modernos de Linux pasaron de iptables a nftables, y entornos mixtos pueden producir conjuntos de reglas que parecen correctos pero no hacen lo que crees.

Tres microhistorias corporativas desde el terreno

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa SaaS mediana ejecutaba una pasarela de logs en unas pocas máquinas Linux. Ingería logs de agentes internos y los reenviaba a un backend gestionado. Alguien cambió el contenedor a --network host porque “NAT estaba perdiendo paquetes”. El cambio pasó tras una prueba rápida. Los logs fluyeron. Todos volvieron a desplegar características.

Dos semanas después, un cambio de red no relacionado expuso una interfaz previamente no enrutable a un segmento de red corporativa más amplio. La pasarela de logs también expuso un endpoint administrativo—pensado para ser accesible solo en localhost para depuración. En modo bridge había quedado publicado solo en 127.0.0.1. En modo host, el servicio se enlazó a 0.0.0.0 por defecto porque la configuración era descuidada y nadie lo notó.

La primera señal no fue una alerta. Fue un ticket: “¿Por qué este servicio tiene una UI administrativa?” Luego vinieron los informes de escaneo. Luego la pregunta ejecutiva: “¿Estamos comprometidos?” Ese día se pasó demostrando una negativa—revisando logs de acceso, ajustando la política del firewall y aprendiendo que “interno” no es una frontera de seguridad.

La causa raíz real no fue solo la red host. Fue la suposición de que el runtime del contenedor mantendría la exposición contenida. La red host hizo esa suposición falsa al instante.

Microhistoria 2: La optimización que se volvió en contra

Un equipo fintech tenía una API sensible a la latencia. Alguien midió la latencia p99 y decidió que el bridge de Docker “añadía jitter”. Movieron el contenedor de la API a red host. Los benchmarks mejoraron un poco en un host tranquilo. Diapositiva de victoria. Despliegue.

Entonces el tráfico de producción se encontró con la realidad: servicios co-ubicados, actualizaciones del kernel y la verdad desordenada de los puertos efímeros. La API usaba un pool de conexiones salientes a una base de datos. Con la red host, el tráfico saliente compartía el rango de puertos efímeros del host con todo lo demás. Bajo carga, el host empezó a agotar puertos efímeros durante ráfagas, causando fallos de conexión que parecían inestabilidad de la base de datos.

El equipo persiguió a la base de datos durante días—añadió réplicas, afinó parámetros, culpó a la red—hasta que alguien miró ss -s y vio una montaña de sockets en TIME-WAIT. La “optimización de rendimiento” no solo movió el cuello de botella; lo llevó a un recurso compartido del host que ahora afectaba servicios no relacionados.

Revirtieron a networking en bridge para la API, arreglaron el reuso de conexiones, ajustaron cuidadosamente tcp_tw_reuse (y con precaución), y pusieron pruebas de carga adecuadas en el proceso de cambios. La ganancia de latencia no valió el riesgo sistémico.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una gran empresa ejecutaba unos pocos contenedores en red host en nodos dedicados: un reenviador DNS interno y un colector de métricas. Tenían una política: cualquier contenedor en red host debía enviarse con (1) una unidad systemd explícita que documentara puertos, (2) una lista de permitidos en el firewall del host, y (3) un trabajo de auditoría recurrente que sacara instantáneas de sockets en escucha y las comparara.

No era glamuroso. Generaba tickets que leían “puerto 8125/udp sigue abierto, se esperaba”. Nadie fue ascendido por ello. Pero creó un contrato estable: si querías red host, pagabas por barandillas.

Un día, una actualización rutinaria de imagen del contenedor incluyó una nueva versión de un agente de métricas que activó un servidor HTTP de depuración por defecto. La diferencia en la auditoría marcó un nuevo listener en :6060. El firewall lo bloqueó de todos modos. El on-call recibió una alerta, confirmó que era nuevo y lo deshabilitó en la configuración antes de que fuera un hallazgo en un escaneo.

El postmortem fue corto y casi aburrido—que es lo mejor. Los controles funcionaron, el radio de impacto se mantuvo pequeño y el cambio no se convirtió en un incidente de seguridad.

Tareas prácticas: comandos, salidas y qué decisión tomar

Estos no son comandos “de juguete”. Son las cosas que ejecutas cuando decides si la red host es segura y cuando limpias después de que no lo fue.

Tarea 1: Identificar contenedores en red host (la comprobación inicial obvia)

cr0x@server:~$ docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Networks}}'
NAMES               IMAGE                         NETWORKS
api-1               myco/api:2026.01              bridge
node-exporter       prom/node-exporter:v1.8.0     host
dns-forwarder       myco/dns:2.3                  host

Qué significa: Cualquier cosa que muestre host está compartiendo el espacio de nombres de red del host.

Decisión: Para cada contenedor en red host, documenta a qué puertos debe enlazarse y quién los posee. Si no puedes responder en 60 segundos, ya estás en territorio de “potencial incidente”.

Tarea 2: Confirmar que el contenedor está realmente en el netns del host

cr0x@server:~$ docker inspect -f '{{.Name}} {{.HostConfig.NetworkMode}}' node-exporter
/node-exporter host

Qué significa: Esto es definitivo: el contenedor está en modo host.

Decisión: Si este contenedor no está en un nodo dedicado, trátalo como un servicio de riesgo elevado y aplica los pasos de contención abajo.

Tarea 3: Listar puertos en escucha en el host (la red host lo hace obligatorio)

cr0x@server:~$ sudo ss -lntup
Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      4096   0.0.0.0:9100       0.0.0.0:*     users:(("node_exporter",pid=2314,fd=3))
tcp   LISTEN 0      4096   127.0.0.1:5432     0.0.0.0:*     users:(("postgres",pid=1189,fd=6))
tcp   LISTEN 0      4096   0.0.0.0:8080       0.0.0.0:*     users:(("java",pid=4128,fd=112))

Qué significa: Ves lo que el mundo puede alcanzar potencialmente. En modo host, los servicios de contenedor aparecen como procesos normales del host.

Decisión: Cualquier cosa escuchando en 0.0.0.0 (o ::) necesita una posición consciente en el firewall. Si esperabas que un servicio fuera solo interno, enlázalo a una interfaz específica o bloquéalo explícitamente.

Tarea 4: Mapear un proceso en escucha de vuelta a un contenedor (atribuición rápida)

cr0x@server:~$ ps -p 2314 -o pid,cmd,cgroup
  PID CMD                                                    CGROUP
 2314 /bin/node_exporter --web.listen-address=:9100          0::/docker/1e7b9d0f6a3f8b2c9f3d6a1b4a6f0b2c1d9e0a7b...

Qué significa: La ruta del cgroup incluye el ID del contenedor.

Decisión: Si no puedes atribuir un puerto a un propietario rápidamente, crea un runbook que lo permita. Los incidentes no son momento para redescubrir metadatos de procesos de Linux.

Tarea 5: Ver qué interfaces tiene el host (y cuáles estás exponiendo accidentalmente)

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             10.20.4.18/24
eth1             UP             172.16.12.18/24
docker0          DOWN           172.17.0.1/16

Qué significa: Múltiples NICs significan múltiples zonas de confianza. La red host expone a través de todas ellas a menos que te enlaces con cuidado.

Decisión: Si un servicio debe ser accesible solo en eth0, enlázalo a 10.20.4.18 (o bloquea eth1) en lugar de confiar en “nadie enruta eso”.

Tarea 6: Comprobar la tabla de rutas (caminos de salida inesperados son reales)

cr0x@server:~$ ip route
default via 10.20.4.1 dev eth0
10.20.4.0/24 dev eth0 proto kernel scope link src 10.20.4.18
172.16.12.0/24 dev eth1 proto kernel scope link src 172.16.12.18

Qué significa: Los contenedores en red host heredan este enrutamiento. Si tienes enrutamiento dividido o policy routing, los contenedores también lo seguirán.

Decisión: Si necesitas control de egress por servicio, la red host te está complicando la vida. Prefiere namespaces separados o proxies de egress.

Tarea 7: Ver qué framework de firewall está activo (iptables vs nftables importa)

cr0x@server:~$ sudo iptables -S | head
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-USER

Qué significa: INPUT con valor por defecto ACCEPT es una bandera roja en cualquier entorno con contenedores en red host.

Decisión: Si INPUT está en ACCEPT, arréglalo primero. Red host más INPUT permisivo es cómo te vuelves “expuesto a Internet” por accidente.

Tarea 8: Inspeccionar la cadena DOCKER-USER (donde deberías poner políticas allow/deny)

cr0x@server:~$ sudo iptables -S DOCKER-USER
-N DOCKER-USER
-A DOCKER-USER -j RETURN

Qué significa: No hay política aplicada aquí. También: la red host no fluye de forma fiable por las cadenas de Docker para ingreso de todos modos.

Decisión: Para la red host, aplica política en INPUT (y posiblemente OUTPUT). Para contenedores en bridge, DOCKER-USER es un buen punto de control. No confundas ambos.

Tarea 9: Confirmar qué puertos son alcanzables desde otro host (verificación real)

cr0x@server:~$ nc -vz 10.20.4.18 9100
Connection to 10.20.4.18 9100 port [tcp/*] succeeded!

Qué significa: El puerto es alcanzable en esa interfaz desde donde ejecutaste esto.

Decisión: Si la alcanzabilidad es más amplia de lo previsto, no “recuerdes arreglarlo después”. Bloquéalo ahora y luego ajusta las direcciones de enlace.

Tarea 10: Comprobar la presión de conntrack (la red host a menudo coincide con alto tráfico)

cr0x@server:~$ sudo conntrack -S
cpu=0 found=120938 invalid=12 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0

Qué significa: invalid y drops pueden insinuar sobrecarga o problemas de enrutamiento asimétrico. Las configuraciones con mucho NAT estresan conntrack; la red host puede reducir NAT pero no elimina mágicamente la presión de estado.

Decisión: Si ves drops/early_drops crecientes durante incidentes, estás frente a un cuello de botella del estado del kernel. Considera reducir NAT, ajustar límites de conntrack o rediseñar el flujo de tráfico.

Tarea 11: Mirar el resumen de sockets (agotamiento de puertos y tormentas TIME-WAIT)

cr0x@server:~$ ss -s
Total: 31234 (kernel 0)
TCP:   19872 (estab 2412, closed 16011, orphaned 3, timewait 15890)

Transport Total     IP        IPv6
RAW       0         0         0
UDP       412       356       56
TCP       3861      3312      549
INET      4273      3668      605
FRAG      0         0         0

Qué significa: Grandes cuentas de timewait bajo carga pueden señalar churn de conexiones. La red host hace que tu contenedor comparta el espacio de puertos efímeros del host y los límites de ciclo de vida TCP con todo lo demás.

Decisión: Si TIME-WAIT domina, arregla el reuso de conexiones y pooling primero. Solo después considera tuning del kernel—con cuidado, porque ajustar puede enmascarar bugs hasta que explotan.

Tarea 12: Confirmar el rango de puertos efímeros (recurso compartido, a menudo pasado por alto)

cr0x@server:~$ sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768	60999

Qué significa: Ese es el rango para puertos efímeros salientes. Todos los workloads en red host lo comparten.

Decisión: Si ejecutas muchos clientes de alto churn en el mismo host, considera ampliar el rango y reducir el churn. Mejor: aislar workloads o evitar la red host para clientes muy chatos.

Tarea 13: Identificar qué contenedor posee un puerto abierto sospechoso usando lsof

cr0x@server:~$ sudo lsof -iTCP:8080 -sTCP:LISTEN
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
java    4128 root  112u  IPv6  65741      0t0  TCP *:http-alt (LISTEN)

Qué significa: El proceso se está enlazando en todas las interfaces (*). Ahora necesitas mapear PID a contenedor vía cgroup como en la Tarea 4.

Decisión: Si no debe ser público, o bien enlázalo a una dirección específica o bloquea el ingreso en el firewall del host inmediatamente.

Tarea 14: Verificar que Docker no haya expuesto algo silenciosamente vía puertos publicados (comparación con grupos de control)

cr0x@server:~$ docker port api-1
8080/tcp -> 127.0.0.1:18080

Qué significa: Contenedor en modo bridge está explícitamente ligado a localhost en el lado del host. Esa es la seguridad que pierdes en modo host.

Decisión: Si dependías de enlaces a 127.0.0.1 para seguridad, la red host es incompatible a menos que recrees esa seguridad mediante enlaces de la app y firewall.

Tarea 15: Comprobar si el contenedor tiene capacidades de red adicionales (host networking más NET_ADMIN es picante)

cr0x@server:~$ docker inspect -f '{{.HostConfig.CapAdd}}' dns-forwarder
[NET_ADMIN NET_RAW]

Qué significa: El contenedor puede manipular redes y fabricar paquetes. En modo red host, eso puede afectar directamente al host.

Decisión: Trátalo como alto riesgo. Si necesitas NET_ADMIN en modo host, aíslalo en un nodo dedicado y refuerza la auditoría.

Tarea 16: Validar la resolución de nombres (la red host hereda el comportamiento de /etc/resolv.conf del host)

cr0x@server:~$ cat /etc/resolv.conf
nameserver 10.20.4.53
search corp.example

Qué significa: Los contenedores en modo host suelen compartir la configuración de resolución del host, que puede cambiar durante renovaciones DHCP o sesiones VPN.

Decisión: Si la estabilidad de DNS importa, fija la configuración DNS explícitamente (configuración de systemd-resolved, gestión estática de resolv.conf o ajustes de resolver a nivel de la aplicación).

Guía de diagnóstico rápido: qué comprobar primero/segundo/tercero

Esta es la secuencia “no te pongas nervioso, triagea” cuando un contenedor en red host está implicado y el tráfico falla o el rendimiento cae en picado.

Primero: confirma qué está realmente escuchando y dónde

• Ejecuta sudo ss -lntup. Identifica listeners inesperados y si se enlazan a 0.0.0.0, una IP específica o 127.0.0.1.
• Mapea PIDs sospechosos a contenedores usando ps -o cgroup o cat /proc/<pid>/cgroup.

Objetivo: Determinar si la falla es simplemente “dirección de enlace equivocada” o “conflicto de puerto”. Esas son soluciones rápidas.

Segundo: verifica la alcanzabilidad desde el lugar correcto

• Desde un host par en la misma red, prueba con nc -vz <ip> <port>.
• Si es UDP, usa nc -vzu o sondas específicas de la aplicación, y verifica con contadores de paquetes (ip -s link).

Objetivo: Decidir si es un problema local de proceso o un problema de ruta/firewall.

Tercero: comprueba el firewall del host y el policy routing

• Inspecciona reglas de INPUT (sudo iptables -S o reglas nft si aplica).
• Confirma interfaces y rutas (ip -br addr, ip route).
• Si usas policy routing, comprueba reglas (ip rule) y tablas relevantes (ip route show table <n>).

Objetivo: Asegurarte de que no expusiste o bloqueaste el servicio cambiando el modelo de namespaces.

Cuarto: busca agotamiento de recursos compartidos del host

• ss -s para tormentas TIME-WAIT y cuentas establecidas.
• sysctl net.ipv4.ip_local_port_range y ajustes TCP si sospechas agotamiento de puertos efímeros.
• conntrack -S si hay NAT/tabla de estados involucrada en cualquier parte del camino.

Objetivo: Identificar si la red host te movió a un cuello de botella compartido (puertos efímeros, conntrack, CPU softirq).

Quinto: comprueba softirq de CPU y saturación de NIC (la capa “es el kernel”)

• mpstat -P ALL 1 o top para ver saturación de CPU.
• cat /proc/softirqs y sar -n DEV 1 (si está disponible) para ver presión de interrupciones de red.

Objetivo: Confirmar si la supuesta “sobrehead de Docker” era en realidad contención de CPU/interrupciones.

Errores comunes: síntoma → causa raíz → solución

1) “El servicio es accesible desde Internet”

Síntoma: Un escaneo de seguridad encuentra un puerto nuevo abierto; los logs muestran IPs aleatorias.

Causa raíz: Contenedor en red host se enlaza a 0.0.0.0; la política INPUT del host lo permite.

Solución: Enlaza explícitamente a la interfaz/IP prevista; aplica deny-by-default en INPUT y allowlist solo rangos/puertos fuente necesarios.

2) “Dos contenedores ya no pueden arrancar en el mismo nodo”

Síntoma: Una instancia falla con “address already in use”.

Causa raíz: La red host elimina el mapeo de puertos; tienes un conflicto real de puertos.

Solución: Asigna puertos únicos por instancia, o deja de usar modo host. En orquestación, aplica anti-affinity para que solo una instancia aterrice por nodo.

3) “Llamadas a localhost alcanzan lo equivocado”

Síntoma: Un contenedor intenta llamar a 127.0.0.1:xxxx esperando un sidecar, pero alcanza un servicio del host (o nada).

Causa raíz: En modo red host, el loopback es el loopback del host.

Solución: Usa descubrimiento de servicios explícito y puertos dedicados, o mantén sidecars en un namespace de red compartido con bridge networking. Deja de asumir que localhost significa “este contenedor”.

4) “Tras cambiar a red host, las conexiones salientes fallan intermitentemente”

Síntoma: Fallos de conexión en ráfagas; muchos TIME-WAIT; errores como “cannot assign requested address”.

Causa raíz: Agotamiento de puertos efímeros o churn de conexiones en el host, compartido entre workloads.

Solución: Reduce el churn de conexiones (keep-alives, pooling); considera ampliar el rango efímero; distribuye workloads; replantea el modo host para clientes con alto churn.

5) “Reglas de firewall que antes funcionaban parecen no aplicarse”

Síntoma: Las reglas en DOCKER-USER no bloquean tráfico hacia un contenedor en red host.

Causa raíz: La red host elude las cadenas del bridge de Docker; el tráfico llega a INPUT directamente.

Solución: Implementa política en las cadenas INPUT/OUTPUT del host (iptables/nftables), no solo en las cadenas específicas de Docker.

6) “La monitorización muestra IPs de origen equivocadas”

Síntoma: Los logs muestran la IP del host como origen; la atribución falla; los ACLs fallan.

Causa raíz: La red host colapsa la identidad del contenedor en L3; la IP de origen es la IP de la interfaz del host.

Solución: Usa identidades mTLS, encabezados explícitos con precaución, o namespaces de red separados donde se requiera identidad. No construyas ACLs asumiendo IPs por contenedor si usas modo host.

7) “El tráfico evade el proxy/ control de egress esperado”

Síntoma: El contenedor puede alcanzar redes que no debería; los logs de egress son incompletos.

Causa raíz: El enrutamiento y la configuración del resolver del host se aplican; los controles de egress basados en namespaces ya no son efectivos.

Solución: Aplica egress en el firewall del host, o mueve la carga fuera de la red host y dentro de un camino de egress controlado.

Cómo limitar el daño cuando debes usar la red host

Si eliges la red host, te debes a tu yo futuro cierta contención. Esto no es paranoia. Es higiene operativa básica.

1) Coloca workloads en red host en nodos dedicados

El aislamiento por programación no reemplaza a los namespaces, pero es un limitador de radio de impacto efectivo. Si el contenedor comparte la red del host, al menos no lo hagas compartir el host con todo lo demás.

2) Deny-by-default en INPUT, luego allowlist

La red host convierte cada listener en un listener del host. Tu firewall del host debería ser aburrido y estricto:

• DROP por defecto en INPUT.
• Permitir established/related.
• Permitir SSH solo desde redes de gestión.
• Permitir puertos específicos del servicio desde rangos de origen específicos.

Hazlo con tu tooling estándar de firewall, no con comandos editados a mano en nodos aleatorios. La deriva es cómo pierdes control.

3) Enlaza a interfaces explícitas

Prefiere enlazar a una IP específica en vez de 0.0.0.0. Si necesitas exposición multi-interfaz, nómbrala explícitamente en la configuración. Si la aplicación no soporta controles de bind sensatos, ese es un problema de producto, no de operaciones.

4) Quita capacidades agresivamente

La red host no requiere NET_ADMIN en la mayoría de los casos. Si no lo necesitas, no lo incluyas. Lo mismo para NET_RAW. No estás construyendo un fabricador de paquetes; estás ejecutando un servicio.

5) Usa sistemas de archivos de solo lectura y mounts mínimos

Esto no es específico de red, pero importa: si el contenedor está en el netns del host y además tiene acceso de escritura a rutas sensibles del host, apilas riesgos. Usa rootfs de solo lectura cuando sea posible y bind mounts mínimos.

6) Haz explícita la propiedad de puertos en código y en operaciones

Define puertos en un solo lugar. Documenta. Alerta cuando cambien. Para contenedores en red host, la “deriva de puertos” es un riesgo de producción y de seguridad.

7) Prefiere contenedores rootless cuando sea posible, pero entiende los límites

Docker rootless puede reducir el impacto de escapes de contenedores, pero la red host y rootless no siempre encajan limpiamente según tu entorno. No asumas que rootless hace que la red host sea “segura”. La hace más segura en algunas dimensiones, no en todas.

8) No uses la red host como atajo para DNS/descubrimiento roto

Si la razón por la que recurres al modo host es “el contenedor no alcanza X”, arregla el enrutamiento, el firewall o el descubrimiento de servicios. El modo host no es un terapeuta de redes.

Listas de verificación / plan paso a paso

Plan A: Decidir si la red host está justificada

1. Escribe el objetivo. “Bajar latencia” no es un objetivo. “Reducir p99 en 2 ms con 10k rps” sí lo es.
2. Mide la línea base. Captura latencia, CPU, softirq, pérdidas de paquetes, estadísticas de conntrack.
3. Prueba alternativas más seguras primero. Usa networking en bridge con MTU afinado, un CNI apropiado, o puertos host con binds estrictos; arregla el churn a nivel de aplicación.
4. Haz un canario en nodos dedicados. No mezcles con otros workloads al principio.
5. Define expectativas de puerto/bind. Puertos exactos, protocolos, direcciones de enlace y rangos de origen permitidos.
6. Construye un rollback. Si revertir toma más de un deploy, estás apostando.

Plan B: Si ya ejecutas red host, reducir riesgo sin reescribirlo todo

1. Inventaría todos los contenedores en red host usando docker ps y docker inspect.
2. Haz snapshots de listeners con ss -lntup y registra lo esperado vs lo actual.
3. Implementa deny-by-default en INPUT y reglas explícitas allow para puertos requeridos.
4. Fija direcciones de enlace en las configs de la app; evita 0.0.0.0 salvo necesidad real.
5. Quita capacidades innecesarias y ejecuta como no-root si es posible.
6. Añade detección: alerta sobre nuevos listeners y sobre deriva en políticas de firewall.

Plan C: Migrar fuera de la red host (el plan para reducir deuda)

1. Identifica por qué se eligió modo host. ¿Rendimiento? ¿Alcanzabilidad? ¿Dolor con mapeo de puertos?
2. Reproduce el problema original en un entorno controlado.
3. Mueve a networking bridge o enrutable con puertos publicados explícitos, o usa un CNI que provea IPs de contenedor enrutable.
4. Vuelve a probar rendimiento y verifica que no regresaste por arreglar lo incorrecto.
5. Elimina suposiciones específicas del host (nombres de interfaces, puertos hardcodeados, dependencias de localhost).
6. Despliega gradualmente y mantén el firewall del host estricto durante la migración.

Preguntas frecuentes

1) ¿La red host de Docker es “insegura” por defecto?

Es menos aislada por diseño. Si tu firewall del host es estricto y tus servicios se enlazan explícitamente, puedes ejecutarla de forma segura. Si tu firewall es permisivo y tus apps se enlazan a 0.0.0.0 por defecto, es una trampa con pies.

2) ¿--network host hace que los contenedores sean más rápidos?

En ocasiones. Puede eliminar la sobrecarga bridge/NAT y simplificar las rutas de paquetes. En muchos sistemas reales, el cuello de botella está en otra parte. Mide antes de decidir y vuelve a medir después.

3) ¿Puedo seguir usando -p con la red host?

No. No hay nada que publicar. El contenedor se enlaza directamente en el host. Tu “mapeo de puertos” ahora es “lo que haga el proceso”.

4) ¿Por qué mis reglas en DOCKER-USER no bloquean contenedores en red host?

Porque el tráfico de contenedores en red host no pasa por las cadenas del bridge de Docker como esperas. Trátalo como cualquier otro proceso del host: aplica política en INPUT/OUTPUT (iptables/nftables) y/o en firewalls upstream.

5) ¿Qué hay de hostNetwork: true en Kubernetes?

El mismo intercambio básico: compartes el espacio de nombres de red del nodo. Obtienes rendimiento y simplicidad en algunos casos y pierdes aislamiento de red. Las mitigaciones (nodos dedicados, firewalls de nodo estrictos, binds explícitos) siguen siendo aplicables.

6) ¿La red host elude todo el aislamiento de contenedores?

No. Elude el aislamiento del espacio de nombres de red. Sigues teniendo otros límites de namespace, cgroups, perfiles seccomp y capabilities (si están configurados sensatamente). Pero perder netns es una reducción significativa en la defensa en profundidad.

7) ¿Cómo digo qué contenedor abrió un puerto cuando uso red host?

Usa ss -lntup para obtener el PID, y luego mapea PID a contenedor vía cgroups (ps -o cgroup) o metadatos de Docker. Construye un runbook, porque lo necesitarás bajo presión.

8) ¿Cuál es la postura “por defecto” más segura para producción?

Evita la red host a menos que puedas articular un beneficio medido o un requisito funcional. Si debes usarla, coloca esos contenedores en nodos dedicados con firewall de host deny-by-default y direcciones de enlace explícitas.

9) Si solo me enlazo a 127.0.0.1, ¿estoy a salvo?

Estás más seguro, pero no universalmente. Solo-localhost reduce la exposición a la red, pero aún necesitas considerar quién puede alcanzar el host (usuarios SSH, otros procesos locales y cualquier camino de escalada de privilegios local). Además, en red host, los contenedores comparten ese localhost con el host.

10) ¿Docker rootless basta para hacer aceptable la red host?

Rootless ayuda a reducir ciertos impactos de escapes, pero no arregla el problema fundamental: los listeners están en la red del host y la política de firewall es la frontera real. Trátalo como una mitigación parcial, no como un permiso libre.

Conclusión: siguientes pasos prácticos

Si recuerdas una cosa: la red host no es “solo un modo de red”. Es la decisión de colapsar un límite. Eso puede ser inteligente, pero nunca debe ser casual.

1. Haz inventario de contenedores en red host hoy y anota los listeners previstos para cada uno.
2. Ejecuta ss -lntup en los hosts y reconcilia “previsto” vs “real”. Arregla sorpresas.
3. Asegura la política INPUT del host para que listeners accidentales no se conviertan en incidentes externos.
4. Aísla workloads en red host en nodos dedicados cuando sea posible.
5. Mide las reclamaciones de rendimiento antes de usar el modo host como optimización general.
6. Automatiza la detección: alerta sobre nuevos listeners y deriva de firewall, porque los humanos olvidan y el software envía defaults.

La red host puede ser la decisión correcta. Simplemente hazla una decisión ingenieril, no un mood.