Docker网络隔离不保护代码资产，但能防止测试容器误连生产系统；应创建--internal自定义bridge网络、禁用host模式、配合只读文件系统与权限最小化，并严格分离测试与生产配置。
在单元测试中使用 Docker 网络隔离，本身不直接保护“代码资产”——代码安全主要靠镜像构建阶段的控制（如多阶段构建、.dockerignore），而非网络层。但网络隔离能有效防止测试容器意外连通外部系统（如生产数据库、配置中心、密钥服务），从而避免敏感信息在测试过程中被读取、泄露或误写。这是保障测试环境“可信边界”的关键一环。
用自定义 bridge 网络切断默认外联
Docker 默认的 bridge 网络会通过 docker0 桥接宿主机网络，容器可能通过 DNS 解析或直连 IP 访问内网服务。单元测试应禁用该行为：
- 显式创建无外联能力的自定义网络：
docker network create --driver bridge --internal test-isolated-net（--internal参数禁止该网络访问外部） - 运行测试容器时绑定此网络：
docker run --network test-isolated-net -v $(pwd):/src app-test:latest pytest tests/ - 验证隔离效果：进入容器执行
ping 8.8.8.8或curl http://192.168.1.100应全部失败
禁止容器访问宿主机敏感端口和服务
即使在隔离网络中，若容器以 host 模式运行或通过 host.docker.internal 访问宿主机，仍可能触达本地密钥管理器（如 HashiCorp Vault dev 模式）、本地数据库或临时配置文件。
- 测试镜像中禁用
--network host和--add-host显式映射 - 在
docker-compose.test.yml中明确设置：network_mode: "test-isolated-net"，并移除extra_hosts条目 - 若必须模拟依赖服务（如 Redis），用
depends_on启动轻量容器，并确保它也加入同一--internal网络，不暴露给外部
结合网络策略与运行时权限最小化
网络隔离需配合其他机制才能形成纵深防护：
- 测试容器启动时添加
--read-only，防止写入临时密钥或日志泄露 - 移除默认 capabilities：
--cap-drop=ALL，尤其禁用NET_ADMIN和NET_RAW（避免容器自行修改网络规则） - 启用 seccomp 策略限制网络相关系统调用，例如禁止
bind到特权端口或connect到已知风险地址段（如10.0.0.0/8）
测试配置与生产配置严格分离
很多敏感代码泄露源于测试代码引用了真实配置路径（如 os.getenv("VAULT_ADDR")）。网络隔离无法阻止这种逻辑调用，但可让调用必然失败，从而暴露问题：
- 在测试镜像中覆盖环境变量，强制使用无效值：
ENV VAULT_ADDR=http://nonexistent:8200 - 利用 Docker 的
--tmpfs挂载空内存盘替代敏感挂载点：--tmpfs /etc/secrets:ro - CI 流水线中增加检查项：扫描测试代码是否含
os.environ.get.*VAULT|KEY|SECRET等关键词，发现即阻断
