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 模式)、本地数据库或临时配置文件。
在 Linux 上通过 Docker 运行 OpenClaw,并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 测试镜像中禁用
--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等关键词,发现即阻断










