Docker se ha consolidado como una herramienta esencial para desarrolladores y equipos de operaciones gracias a su capacidad para simplificar la creación, despliegue y gestión de contenedores. Con la llegada de Docker Engine v28, la plataforma introduce una mejora significativa en la seguridad de las redes de contenedores, enfocándose en minimizar riesgos y evitar accesos no autorizados dentro de redes locales. Este cambio responde a la evolución del ecosistema y a la necesidad creciente de proteger las aplicaciones containerizadas en entornos complejos. Una de las funcionalidades tradicionales de Docker es la creación automática de reglas de NAT (Traducción de Direcciones de Red) mediante iptables en Linux para permitir que los puertos publicados en el host se redirijan hacia los contenedores. Por ejemplo, un comando típico como docker run -d -p 8080:80 permite que el puerto 8080 de la máquina anfitriona sea un punto de acceso hacia el puerto 80 del contenedor.
Sin embargo, esta configuración previa presentaba ciertos riesgos en entornos compartidos o multiusuario, especialmente en redes LAN donde otros dispositivos podían, bajo configuraciones específicas, acceder a puertos no publicados de los contenedores. Antes de la versión 28, Docker confiaba en que la cadena FORWARD del firewall estuviera configurada de forma estricta para proteger el acceso. No obstante, si dicha cadena tenía una política permisiva establecida como ACCEPT y el reenvío de paquetes IP (net.ipv4.ip_forward) estaba habilitado, existía la posibilidad de que una máquina en el mismo segmento de red accediera a puertos internos de contenedores sin que estos estuvieran explícitamente publicados.
De esta manera, los contenedores podían quedar expuestos inadvertidamente dentro de una red local privada, generando potenciales brechas de seguridad. Este escenario se vuelve especialmente relevante en entornos corporativos, redes multi-inquilino o infraestructuras con múltiples VLANs y subredes, donde usuarios no autorizados podrían intentar descubrir y conectar con servicios que no deberían estar accesibles. Los atacantes podían añadir rutas customizadas hacia subredes internas de Docker y realizar conexiones directas a servicios sensibles, como bases de datos o aplicaciones privadas, sin ningún filtro a nivel de Docker. Con Docker Engine v28, se introduce un cambio fundamental para mitigar estas vulnerabilidades. Ahora, el motor aplica una política estricta de rechazo (DROP) para todo el tráfico entrante a puertos de contenedores que no estén publicados explícitamente mediante las opciones -p o --publish.
Es decir, cualquier intento de acceso remoto a puertos internos que no estén expuestos deja de ser posible por defecto. Este modelo «seguro por defecto» garantiza que sólo los servicios que se desean compartir sean accesibles y reduce la superficie de ataque. Para los usuarios que acostumbran a acceder a contenedores sin publicar puertos, o que trabajan con configuraciones avanzadas de red, Docker ofrece mecanismos para mantener el comportamiento anterior. Se puede optar por desactivar esta política restrictiva configurando el parámetro ip-forward-no-drop en el archivo daemon.json o ejecutando Docker con la opción --ip-forward-no-drop.
Además, se puede crear una red personalizada con la opción de modo nat-unprotected para mantener un nivel de accesibilidad más abierto, aunque siempre con la recomendación de evaluar los riesgos asociados. Estas mejoras no sólo aplican para tráfico IPv4, sino que también extienden la protección a IPv6, algo relevante dado que muchas redes corporativas y servicios públicos están adoptando cada vez más este protocolo. De esta forma, Docker aborda de manera integral el aislamiento de contenedores y previene accesos no autorizados a nivel de red en cualquier protocolo soportado. Para equipos y administradores, la actualización a Docker Engine v28 requiere reevaluar la configuración del firewall local. Es probable que muchos entornos no experimenten cambios perceptibles si operan bajo las configuraciones estándares recomendadas por Docker, pero aquellos con reglas de red personalizadas deben realizar pruebas en entornos controlados antes de implementar la versión en producción.
Esto evitará interrupciones inesperadas por bloqueos de accesos que antes eran posibles y ahora estarán denegados. La introducción de estas políticas de seguridad coincide con la evolución del ecosistema de contenedores. Docker ya no es sólo una herramienta para entornos de desarrollo o pruebas aisladas; hoy día es la base para infraestructuras críticas, entornos multiusuario y plataformas orquestadoras que gestionan cientos o miles de nodos. La protección de la red se vuelve un requisito indispensable para cumplir estándares de seguridad empresarial y normativas regulatorias. El enfoque adoptado por Docker respalda las mejores prácticas actuales en seguridad informática: minimizar la exposición de servicios, restringir accesos a lo estrictamente necesario y facilitar que los usuarios no deban ser expertos en administración de firewalls para mantener su entorno seguro.
Estos cambios reflejan años de aprendizaje y feedback de la comunidad, resaltando la importancia de un modelo de seguridad proactivo y predeterminado. Los casos en los que esta nueva configuración podría afectar se relacionan con arquitecturas que se apoyan en acceso directo a la IP del contenedor desde otras máquinas en la red local, sin publicar puertos. Por ejemplo, desarrolladores que usan redirecciones o configuraciones avanzadas que no pasan por el estándar docker run -p pueden necesitar ajustar sus redes o recurrir a las opciones de exclusión mencionadas. Además, para escenarios complejos donde se requiere granularidad máxima, Docker recomienda la gestión manual avanzada de iptables, aunque esto puede ser desafiante y sólo está indicado para quienes tengan experiencia profunda en redes y seguridad. A nivel práctico, la transición hacia Docker Engine v28 representa un avance para asegurar que las aplicaciones desplegadas en contenedores mantengan su confinamiento esperado y que los accesos se controlen según la intención declarada por el usuario.
La mayoría de usuarios podrán adoptar esta versión sin inconvenientes y se beneficiarán de mayores garantías de protección sin necesidad de configuraciones adicionales. Asimismo, la comunidad y soporte de Docker están disponibles para ayudar en la adopción de esta versión, aportando documentación, ejemplos y vías de contacto para resolver dudas o incidencias derivadas. En conclusión, Docker Engine v28 marca un paso importante en la evolución de la plataforma, alineando su comportamiento a las expectativas actuales en seguridad y redes. Limitar el acceso a puertos no publicados por defecto reduce significativamente riesgos en entornos locales compartidos y mejora la postura general de seguridad de los contenedores. Actualizar a esta versión es fundamental para quienes buscan un entorno de contenedores robusto y protegido, capaz de sostener las demandas de infraestructuras modernas sin comprometer la facilidad de uso ni la flexibilidad.
Para desarrolladores, administradores y equipos de seguridad que buscan mantenerse a la vanguardia, conocer y aplicar las nuevas capacidades de Docker Engine v28 es clave para garantizar despliegues confiables y resilientes. Mantener las aplicaciones y servicios protegidos empieza con una red bien configurada y controlada, y Docker ha dado un paso decisivo para contribuir a este objetivo.
