关键在于使用自定义bridge网络实现逻辑分组：为不同业务域（如用户、支付、数据库）创建独立网络，仅将需通信的容器加入同一网络，跨网络容器默认完全隔离，从而在连通性与最小权限间取得平衡。
要让容器之间既能通得上，又不随便乱通，关键不在“连”，而在“怎么连”——重点是网络划分、访问控制和通信路径的显式定义。默认 bridge 网络虽然方便，但所有接入的容器默认互通，不符合最小权限原则，也不满足等保、GDPR 或金融行业对数据隔离的基本要求。
用自定义 Bridge 网络做逻辑分组
避免使用默认 docker0 网桥。每个业务域（如用户服务、支付服务、数据库）应分配独立的自定义网络，天然形成通信边界。
- 创建专用网络：
docker network create --driver bridge --subnet 10.20.1.0/24 user-net - 只把需要交互的容器加入同一网络，例如 web 和 auth 容器都连 user-net，而 db 容器只连 backend-net
- 跨网络容器无法直接通信（即使在同一主机），连 ping 都不通，这是最基础的隔离层
通过多网络组合实现分层访问控制
单容器可同时接入多个网络，借此精确控制其“能见谁”。典型微服务架构中，一个 API 服务常需同时连接前端网和后端网，但数据库只连后端网。
- Docker Compose 示例中明确声明各服务所属网络，不写进某个网络的服务就完全不可达
- 前端网络（frontend）只含 Nginx 和 API 网关；后端网络（backend）含业务服务与 PostgreSQL；监控网络（monitoring）单独存在，仅 Prometheus 和 Grafana 加入
- 这种结构使攻击者即使攻破 Web 容器，也无法直接扫描或访问数据库容器
禁用默认互通，关闭非必要网络能力
很多安全风险源于“默认开启”。主动关闭冗余通道，比事后加防火墙更可靠。
- 启动容器时显式指定
--network，不依赖隐式默认网络 - 对无需联网的批处理或脱敏任务容器，使用
--network none，彻底切断网络栈 - 避免混用 host 模式，除非压测等极少数场景——它绕过所有 Docker 网络策略，等于把容器进程暴露在主机网络平面
配合网络策略插件实施细粒度规则（进阶）
当需要基于协议、端口、标签做动态控制时，Bridge 模式本身不支持策略，需引入 CNI 插件如 Calico。
- 部署 Calico 后，可通过 NetworkPolicy 资源定义：只允许 api 容器用 TCP 5432 访问 db 容器，禁止其他任何流量
- 策略按标签（label）匹配容器，与 IP 无关，适配容器弹性伸缩场景
- 该方式满足等保2.0中“通信传输保密性”和“访问控制策略细化到端口级”的合规项
