核心是通过网络拓扑控制通信边界：为关键业务创建专属自定义桥接网络（如prod-net），脱离默认bridge网络以阻断横向渗透；显式指定网络与ip，实现容器间服务名通信且跨网默认不通；禁用host/container网络模式，辅以iptables限流、用户命名空间重映射及资源监控，形成防横向、防逃逸、可测可控的闭环防护体系。
直接用 Docker 网络隔离策略保障关键业务稳定性，核心不是“加防火墙”，而是通过网络拓扑控制通信边界——让不该通的彻底不通，该通的可控可测。
为关键业务创建专属自定义桥接网络
默认的 bridge 网络（docker0）所有容器共享一个子网，存在横向渗透风险。关键业务必须脱离默认网络：
- 执行
docker network create --driver bridge --subnet 192.168.100.0/24 --gateway 192.168.100.1 prod-net，指定私有 CIDR，避免与宿主机或其它环境冲突 - 启动关键服务时显式指定网络：
docker run -d --name payment-api --network prod-net --ip 192.168.100.10 -p 8080:8080 payment-service:latest - 同一网络内容器可通过服务名（如
payment-api）直接解析通信；跨网络容器默认无法 ping 通、telnet 通、DNS 解析失败
禁止非必要跨网通信，堵住横向移动路径
即使用了自定义网络，仍需防止意外连通。Docker 原生不提供 ACL，但可通过以下方式加固：
- 不使用
--network host或--network container:这类共享网络栈的模式，尤其避免在关键服务中启用 - 对非关键容器（如日志收集器、监控探针）使用
--network none或单独隔离网络，并仅通过 volume 或 hostPath 暴露必要数据 - 若需有限访问（如只允许监控系统调用健康接口），用
iptables在宿主机层面限制源 IP 和目标端口：iptables -A INPUT -s 10.0.5.0/24 -d 192.168.100.10 -p tcp --dport 8080 -j ACCEPT，再iptables -A INPUT -d 192.168.100.10 -j DROP
启用用户命名空间重映射，降低逃逸危害
网络隔离防横向，用户命名空间防提权。二者配合才能应对容器逃逸：
- 在
/etc/docker/daemon.json中添加：{"userns-remap": "default"}，重启 Docker 服务 - 此时容器内 UID 0（root）被映射为宿主机上一个普通 UID（如 100000+），即使突破容器，也无法直接操作宿主机 root 文件系统或绑定特权端口
- 注意：启用后需确保镜像中文件权限适配映射范围，避免因 UID/GID 不匹配导致服务启动失败
结合资源限制与网络性能监控形成闭环
网络稳定不只是“通不通”，更是“稳不稳”。关键业务需持续观测真实网络表现：
- 用
docker stats --no-stream payment-api查看实时网络 I/O 和 CPU 占用，设置告警阈值（如网络接收速率突增 300% 可能意味异常流量） - 定期执行轻量探测：
docker exec payment-api ping -c 3 auth-db（假设数据库在同一网络），延迟 >15ms 或丢包立即触发检查 - 对 API 网关等入口容器，用
docker run --rm -it --network prod-net nicolaka/netshoot curl -s -o /dev/null -w "%{http_code}" http://payment-api:8080/health验证服务可达性
