网络命名空间是docker实现多租户安全隔离最基础最关键的机制，为每个容器提供独立ip、端口、路由表和网络接口，天然阻断直接通信；默认启用，但需禁用host模式、慎用container模式，并通过自定义bridge网络、compose分网及防火墙规则强化隔离。
网络命名空间是 Docker 实现多租户安全隔离最基础也最关键的机制。它让每个容器拥有独立的网络视图——包括自己的 IP 地址、端口、路由表和网络接口，天然阻断容器间直接通信，避免端口冲突或流量越界。
默认已启用，但需避免破坏隔离
Docker 启动容器时，默认就创建并加入独立的 network namespace，无需额外开启。真正影响安全的是后续操作：
- 禁用 --network=host：该模式会复用宿主机网络栈，完全绕过命名空间隔离，多租户环境下必须禁止
- 慎用 --network=container:xxx：会让新容器共享另一容器的网络命名空间，仅限可信内部调试，不可用于租户间服务互通
- 不依赖默认 bridge 的“自动互通”：docker0 网桥虽方便，但同网桥下所有容器默认可互访，这不是租户隔离，而是共享风险
用自定义桥接网络划分租户边界
为不同租户创建彼此隔离的自定义 bridge 网络，是最常用且有效的实践：
- 为租户 A 创建专属网络：
docker network create tenant-a-net - 为租户 B 创建另一个：
docker network create tenant-b-net - 启动容器时明确指定网络：
docker run --network tenant-a-net ... - 两个网络之间无路由、无 DNS 解析、无 IP 可达性，实现硬隔离
结合 Docker Compose 实现服务级细粒度控制
在微服务或多组件场景中，单靠一个租户网络还不够，需进一步按角色分网：
- 在
docker-compose.yml中定义多个网络（如frontend、backend、internal） - 将 Web 服务只连
frontend，API 服务连frontend和backend，数据库只连backend - 这样即使同属租户 A，前端也无法直连数据库，攻击面大幅收窄
配合防火墙规则做最后一道防线
命名空间隔离是逻辑层防护，建议叠加 iptables 或 nftables 规则加固：
- 限制租户网络进出方向：
iptables -A FORWARD -i br-tenant-a-net -o br-tenant-b-net -j DROP - 禁止容器主动访问宿主机敏感端口（如 2375/2376 Docker API）
- 对暴露到公网的容器，统一走 Nginx 反向代理，不直接映射端口
