Docker Build Secrets 实战指南：构建时密钥安全与零残留原理

1. 项目概述：为什么“构建时秘密”不是可选项，而是生存线

我亲手拆解过不下五十个被公开扫描到的生产级镜像，其中超过七成在docker history输出里直接暴露了 API 密钥、数据库密码、内部服务 Token，甚至还有人把.pem私钥文件硬编码进了COPY指令。这不是理论风险——这是每天都在发生的供应链攻击入口。你可能觉得“我们 CI 流水线很干净”，但只要 Dockerfile 里出现过ARG DB_PASSWORD或者ENV API_KEY=${API_KEY}，哪怕只在某次调试中临时启用过，这个值就已经固化在某一层的json元数据里，永远无法擦除。更隐蔽的是，很多团队用--build-arg传参后，再用RUN echo $DB_PASSWORD > /tmp/.cred做临时文件，以为删掉就安全了——错。Docker 的分层机制会把“创建文件”和“删除文件”记为两个独立层，docker save | tar -x解压后，那个带密码的临时文件依然躺在中间层的layer.tar里，等着被strings命令一把捞出来。

这就是 Docker Build Secrets 存在的根本原因：它不是“让构建更优雅的锦上添花”，而是切断敏感数据在镜像生命周期中任何残留可能性的唯一可靠手段。它解决的不是“怎么传密钥”的问题，而是“怎么确保密钥在构建结束那一刻彻底从系统里蒸发”的问题。关键词是蒸发——不是隐藏，不是加密，是物理性地不写入任何磁盘、不进入任何缓存、不生成任何元数据。你不需要成为安全专家才能理解它的价值：想象你去银行办业务，柜员给你一张写有密码的便签，办完事你当着他的面把便签撕碎冲进马桶——Build Secrets 就是那个“当场撕碎+即时冲走”的动作，而传统方式相当于把便签夹进你的存折里带回家，还忘了告诉自己这页不能拍照发朋友圈。

适合谁看？如果你写 Dockerfile，你必须看；如果你维护 CI/CD 流水线，你必须看；如果你负责容器镜像合规审计，你必须看。它不挑技术栈——Python 的 pip 源认证、Node.js 的 private registry、Java 的 Maven settings.xml 加密、Go 的 private module proxy，全适用。它也不挑部署环境——本地开发、GitLab CI、GitHub Actions、Jenkins、自建 Kubernetes 构建集群，全部原生支持。这不是一个“高级技巧”，这是现代容器化开发的基础操作规范，就像写代码前先配好.gitignore一样理所当然。

2. 核心设计逻辑：BuildKit 不是升级包，而是安全架构的重写

2.1 为什么经典构建引擎注定失败？

要真正吃透 Build Secrets，必须先看清旧体系的致命缺陷。Docker 经典构建引擎（也就是DOCKER_BUILDKIT=0时代）本质上是个“线性执行器”：它把 Dockerfile 当作一串按顺序执行的 shell 命令，每一步的输出（包括echo $SECRET这种误操作）都会被无差别地捕获为镜像层。它的缓存机制更是雪上加霜——只要某一层的输入（比如COPY . .的内容）没变，它就直接复用该层，完全不管这一层里是否曾短暂存在过密钥。我见过最典型的翻车案例：一个团队在RUN步骤里用curl -u "$USER:$PASS" https://internal.repo/maven.jar下载依赖，为了提速启用了缓存。结果某天运维不小心把USER和PASS的值改成了空字符串提交，构建居然成功了——因为缓存复用了上一次下载好的 jar 包，但docker history里赫然躺着USER=xxx和PASS=yyy的明文参数记录。攻击者根本不用等你漏出 jar，直接docker inspect就能拿到凭证。

BuildKit 的革命性在于它彻底抛弃了“层即历史”的思维。它把整个构建过程抽象成一张有向无环图（DAG）：每个RUN、COPY、FROM都是一个节点，节点之间通过明确的依赖关系连接。关键点来了：BuildKit 把“秘密”定义为一种不参与图节点计算的特殊资源。它不会被当作输入传递给任何节点，也不会被当作输出保存为层。当你写RUN --mount=type=secret,id=token ...，BuildKit 实际上是在执行这个RUN节点时，动态挂载一个内存中的 tmpfs 文件系统（路径默认/run/secrets/token），执行完立刻卸载。这个 tmpfs 根本不经过磁盘，不进入缓存键计算，甚至不触发任何文件系统事件。你可以把它理解为给RUN命令开了一个“安全通话间”，门一关，里面说什么，外面永远听不见，门一开，通话间自动销毁。

2.2 BuildKit 启用：不是开关，而是确认你已切换操作系统

很多人卡在第一步：“我加了--secret，但提示unknown flag: --secret”。这不是插件没装，是你还在用旧内核。BuildKit 在 Docker 23.0+ 是默认启用的，但默认启用不等于全局生效。这里有个极易被忽略的细节：Docker CLI 的build命令和docker buildx build命令是两套独立实现。docker build默认走 BuildKit 仅当DOCKER_BUILDKIT=1环境变量被显式设置，而docker buildx build则强制使用 BuildKit。所以最稳妥的启用姿势是：

# 方案一：临时启用（推荐用于验证） DOCKER_BUILDKIT=1 docker build -t myapp . # 方案二：永久启用（Linux/macOS） echo 'export DOCKER_BUILDKIT=1' >> ~/.bashrc && source ~/.bashrc # 方案三：无脑用 buildx（生产环境首选） docker buildx build -t myapp .

提示：docker buildx不仅强制启用 BuildKit，还支持跨平台构建（如--platform linux/arm64）、并行构建（--load或--push时自动优化）、以及更强大的缓存策略（--cache-from）。它不是“高级功能”，而是现代 Docker 构建的事实标准。别再用docker build了，就像别再用 IE 浏览器一样。

验证是否生效的黄金命令是docker build --progress=plain -t test .。如果输出里出现#1 [internal] load build definition from Dockerfile这样的带编号步骤，说明你在 BuildKit 模式下；如果看到Step 1/5 : FROM...这种老式编号，则 BuildKit 未激活。

2.3 三种秘密类型：不是功能罗列，而是安全边界的精准划分

BuildKit 定义的三种秘密类型，本质是针对三类不同安全威胁模型的防御方案：

这个表格揭示了一个重要原则：没有万能的秘密类型。试图用 Secret Mounts 去做 Git 克隆，就必须把私钥文件传给构建上下文，违背了“不传密钥”的初衷；试图用 Git Auth Secrets 去调用内部 API，它根本不会出现在RUN步骤里。选错类型，等于在防弹衣上打了个补丁，却把要害暴露在外。

3. 实操核心：从单密钥到多密钥协同的完整链路

3.1 秘密准备：文件权限比密码强度更重要

很多团队把精力花在“用什么工具生成强密码”上，却忽略了最基础的防线：文件权限。假设你创建了一个.secrets/api_key文件，内容是sk_live_abc123，但文件权限是644（所有人可读），那么任何能登录你构建服务器的人，只要执行find / -name "api_key" -type f 2>/dev/null | xargs ls -l就能定位并读取它。真正的安全起点是：

# 创建专用秘密目录（绝对不在 Git 仓库根目录！） mkdir -p /opt/build-secrets cd /opt/build-secrets # 创建密钥文件（注意：不要用 echo，避免 bash 历史记录） cat > api_key << 'EOF' sk_live_abc123def456 EOF # 设置严格权限：仅所有者可读写 chmod 600 api_key # 验证：ls -l 应显示 -rw------- 1 root root ls -l api_key

注意：cat > file << 'EOF'中的单引号'EOF'很关键，它禁止 shell 变量展开，防止你误把$API_KEY这种变量名写进去。这是老手和新手的分水岭。

.gitignore和.dockerignore的配置同样致命。常见错误是只写.secrets/，却忘了*.key、*.pem、.env这些通用模式。一个健壮的.dockerignore应该是：

# 忽略所有秘密相关文件 .secrets/ *.key *.pem *.crt .env .env.local config/*.yaml config/*.json # 忽略构建产物和临时文件 node_modules/ __pycache__/ *.pyc .DS_Store

3.2 单密钥实战：以 Python 私有 PyPI 为例的完整闭环

假设你的公司有一个私有 PyPI 仓库https://pypi.internal.company.com，需要 API Token 才能安装包。传统做法是pip install --index-url https://token:password@pypi.internal.company.com/simple/ package，这会让 token 明文出现在pip的日志和进程列表里。用 Build Secrets 的正确姿势是：

第一步：准备秘密文件

# 在构建服务器上执行 echo "pypi-token-here" > /opt/build-secrets/pypi_token chmod 600 /opt/build-secrets/pypi_token

第二步：编写 Dockerfile（关键：分离认证与安装）

# syntax=docker/dockerfile:1 FROM python:3.11-slim # 创建非 root 用户（安全基线） RUN useradd -m -u 1001 appuser USER appuser # 复制 requirements.txt（不含 secrets） COPY requirements.txt . # 关键：在 RUN 中挂载 secret，且只在需要时挂载 RUN --mount=type=secret,id=pypi_token \ # 1. 从 secret 读取 token 并写入 pip 配置（仅内存） mkdir -p /home/appuser/.pip && \ echo "[global]" > /home/appuser/.pip/pip.conf && \ echo "index-url = https://pypi.internal.company.com/simple/" >> /home/appuser/.pip/pip.conf && \ echo "trusted-host = pypi.internal.company.com" >> /home/appuser/.pip/pip.conf && \ # 2. 使用 pip install（此时 pip 会自动读取配置） pip install --no-cache-dir -r requirements.txt # 清理 pip 配置（可选，但建议） RUN rm -f /home/appuser/.pip/pip.conf # 复制应用代码（无 secrets） COPY --chown=appuser:appuser . /app WORKDIR /app CMD ["python", "app.py"]

第三步：构建命令（注意路径和 ID 匹配）

# 构建时指定 secret 来源 docker buildx build \ --secret id=pypi_token,src=/opt/build-secrets/pypi_token \ -t my-python-app \ .

这个流程的精妙之处在于：pip.conf文件从未被写入磁盘，它只存在于RUN命令执行的内存空间里；pip install命令结束后，整个/home/appuser/.pip/目录（如果存在）也不会被保存为层，因为RUN步骤的最终文件系统状态是pip安装完成后的状态，而不是中间配置状态。你可以用docker history my-python-app验证，输出里绝不会出现pypi_token或pypi.internal字样。

3.3 多密钥协同：复杂构建中的“秘密调度”艺术

现实项目往往需要多个密钥协同工作。例如一个 Java 应用，构建时需要：

• MAVEN_SETTINGS_XML：包含私有 Nexus 仓库认证的 XML 文件
• SONAR_TOKEN：用于 SonarQube 代码质量扫描
• LICENSE_KEY：商业库的激活码

错误做法是把三个密钥都挂载到同一个RUN命令里，然后写一堆cat /run/secrets/*。这违反了最小权限原则，也增加了出错概率。正确策略是“按需挂载，分步执行”：

# syntax=docker/dockerfile:1 FROM maven:3.9-openjdk-17 # 步骤1：只挂载 Maven 设置，配置仓库 RUN --mount=type=secret,id=maven_settings,uid=1001 \ mkdir -p /root/.m2 && \ cp /run/secrets/maven_settings /root/.m2/settings.xml && \ chmod 600 /root/.m2/settings.xml # 步骤2：只挂载 Sonar Token，执行扫描（注意：扫描不产生最终产物） RUN --mount=type=secret,id=sonar_token \ export SONAR_TOKEN=$(cat /run/secrets/sonar_token) && \ mvn sonar:sonar \ -Dsonar.host.url=https://sonarqube.internal \ -Dsonar.login=$SONAR_TOKEN # 步骤3：只挂载 License Key，编译主应用（License Key 只在此处需要） RUN --mount=type=secret,id=license_key \ export LICENSE_KEY=$(cat /run/secrets/license_key) && \ mvn clean package \ -Dlicense.key=$LICENSE_KEY \ -DskipTests # 最终阶段：只保留 jar，无任何 secrets FROM openjdk:17-jre-slim COPY --from=0 /workspace/target/app.jar /app.jar CMD ["java", "-jar", "/app.jar"]

构建命令需对应提供所有 secrets：

docker buildx build \ --secret id=maven_settings,src=/opt/build-secrets/maven-settings.xml \ --secret id=sonar_token,src=/opt/build-secrets/sonar_token \ --secret id=license_key,src=/opt/build-secrets/license_key \ -t my-java-app \ .

这种“分步挂载”看似多写了几个RUN，实则带来了三重收益：一是每个步骤的权限最小化（Sonar Token 永远不会出现在编译步骤里）；二是构建缓存更精准（修改maven_settings只影响第一步，不影响后续）；三是故障隔离（某个密钥失效，只导致对应步骤失败，而非整个构建崩溃）。

3.4 SSH Mounts：Git 私有仓库克隆的终极解法

git clone是另一个高危操作区。传统方案是RUN ssh-keyscan github.com >> /etc/ssh/known_hosts && git clone git@github.com:org/private.git，但这要求把私钥COPY进镜像，或者用ARG传入，都是灾难。SSH Mounts 的精妙在于它不传输密钥，只转发连接。

前提条件：

• 构建服务器上运行着ssh-agent
• 你的私钥已通过ssh-add ~/.ssh/id_rsa加载到 agent 中
• ssh-agent的 socket 路径通常是/tmp/ssh-XXXXXX/agent.XXXX

Dockerfile 写法：

# syntax=docker/dockerfile:1 FROM alpine:latest # 安装 git 和 openssh-client RUN apk add --no-cache git openssh-client # 关键：挂载 SSH agent socket RUN --mount=type=ssh \ # git 会自动使用 SSH_AUTH_SOCK 环境变量 git clone git@github.com:myorg/private-lib.git /tmp/private-lib && \ # 编译或处理私有库 cd /tmp/private-lib && make install

构建命令（必须启用 SSH forwarding）：

# 启用 SSH forwarding（default 是 agent socket 的别名） docker buildx build \ --ssh default \ -t my-app-with-private-git \ .

实测心得：如果遇到Permission denied (publickey)，首先检查ssh-add -l是否列出你的密钥；其次确认docker buildx build --ssh default是否真的把SSH_AUTH_SOCK传递给了构建容器（可在RUN中加printenv | grep SSH调试）；最后，某些 CI 环境（如 GitHub Actions）的ssh-agent是受限的，需用--ssh github=$HOME/.ssh/github_key指定具体密钥文件路径，而非依赖 agent。

4. CI/CD 深度集成：让秘密管理自动化、可审计、零泄漏

4.1 GitHub Actions：环境变量注入的黄金范式

GitHub Actions 的secrets是最接近“零配置”的集成方案。它的设计哲学是：秘密永远不离开 GitHub 的安全边界。当你在 workflow 中写${{ secrets.API_KEY }}，GitHub Actions runner 会在执行run步骤前，将该值作为环境变量注入到 shell 环境中，且该环境变量对ps、env等命令不可见（被 runner 特殊处理）。

一个生产级的 workflow 示例：

name: Build and Push on: push: branches: [main] jobs: build: runs-on: ubuntu-latest steps: # 步骤1：检出代码（不涉及 secrets） - uses: actions/checkout@v4 # 步骤2：设置 Docker Buildx（推荐） - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 # 步骤3：构建镜像（秘密仅在此处注入） - name: Build image with secrets env: # 将 GitHub Secrets 注入为环境变量 API_KEY: ${{ secrets.API_KEY }} DB_PASSWORD: ${{ secrets.DB_PASSWORD }} run: | # 使用 env 源类型，无需创建文件 docker buildx build \ --secret id=api_key,env=API_KEY \ --secret id=db_password,env=DB_PASSWORD \ --platform linux/amd64,linux/arm64 \ --tag ghcr.io/myorg/myapp:${{ github.sha }} \ --push \ . # 步骤4：推送镜像（不涉及 secrets） - name: Push to registry uses: docker/push-action@v4 with: push-images: true

这个 workflow 的安全关键点在于：API_KEY和DB_PASSWORD从未以文件形式落地到 runner 的磁盘上；它们只作为环境变量存在于docker buildx build命令的执行环境中；BuildKit 会直接从环境变量读取值并挂载为内存文件，全程不经过任何中间存储。你可以用run: printenv | grep -i secret在调试时验证，但正式 workflow 中绝不应有此类调试步骤。

4.2 GitLab CI：变量作用域与文件挂载的平衡术

GitLab CI 的variables和file_variables提供了更细粒度的控制。variables是纯环境变量，适合短小的 token；file_variables则会把 secret 值写入一个临时文件（路径由 GitLab 提供），适合大块内容如证书。

stages: - build build-image: stage: build image: docker:23.0.6 services: - docker:dind variables: # 短 token 用 variables GIT_STRATEGY: none before_script: - docker info script: # 使用 file_variables（GitLab 自动创建临时文件） - | docker buildx build \ --secret id=cert_file,src=${CERT_FILE} \ --secret id=api_token,env=API_TOKEN \ --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA \ --push \ . artifacts: - dist/ # 关键：定义 file_variables，GitLab 会自动注入 file_variables: CERT_FILE: $CI_PROJECT_DIR/certs/internal.crt variables: # 环境变量方式 API_TOKEN: $CI_API_TOKEN

注意：file_variables的CERT_FILE是 GitLab CI 的内置变量，指向一个由 GitLab 创建的临时文件路径，其内容就是你在 CI/CD Settings > Variables 中定义的CERT_FILE的值。这种方式避免了手动echo写文件，更安全。

4.3 审计与验证：构建后必做的三道安检

再完美的流程也需要验证。每次构建完成后，必须执行以下三步审计：

第一步：检查镜像历史（Layer 层面）

# 查看每一层的指令，确认无敏感词 docker history myapp:latest | grep -i -E "(api|key|pass|token|secret|auth)" # 检查是否有可疑的 ARG 或 ENV 指令 docker history myapp:latest | grep -E "ARG|ENV"

第二步：解包检查（文件系统层面）

# 导出镜像为 tar，并解压 docker save myapp:latest | tar -x # 搜索所有层中的敏感文件 find . -name "layer.tar" -exec sh -c ' for layer; do echo "=== Checking $layer ===" tar -tf "$layer" 2>/dev/null | grep -i -E "(api|key|pass|token|secret|auth)" done ' _ {} + # 检查是否存在 .gitignore 未覆盖的敏感文件 find . -name "layer.tar" -exec tar -xf {} \; -quit find . -name "*.key" -o -name "*.pem" -o -name ".env" -o -name "settings.xml"

第三步：静态扫描（合规层面）使用开源工具trivy进行深度扫描：

# 安装 trivy curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin # 扫描镜像中的密钥（基于正则匹配） trivy image --scanners secret --severity CRITICAL,HIGH myapp:latest # 扫描镜像中的漏洞（附带密钥检测） trivy image --scanners vuln,secret myapp:latest

实操心得：把这三步写成一个verify-build.sh脚本，作为 CI 流水线的最后一个 job。任何一步失败，立即exit 1并通知负责人。这不是“以防万一”，而是“必须如此”。

5. 高级陷阱与避坑指南：那些文档里不会写的血泪教训

5.1 “Mount not found” 错误的七种死因与解法

failed to solve: rpc error: code = Unknown desc = failed to compute cache key: failed to walk /var/lib/docker/tmp/buildkit-mount87654321: lstat /var/lib/docker/tmp/buildkit-mount87654321: no such file or directory—— 这个错误信息极其误导，它几乎从不表示 mount 本身有问题，而是暴露了更底层的配置缺陷。根据我排查过的 37 个真实案例，原因分布如下：

提示：永远先运行docker build --progress=plain，它会输出最原始的错误堆栈，比--progress=auto的美化输出更有诊断价值。

5.2 多阶段构建中的秘密“幽灵残留”现象

多阶段构建常被认为“天然安全”，但一个隐蔽的陷阱是：如果 builder 阶段的RUN命令创建了文件，而 final 阶段的COPY --from=builder又恰好复制了该文件，秘密就可能间接泄露。例如：

# 错误示范：秘密被间接复制 FROM python:3.11 AS builder RUN --mount=type=secret,id=token \ TOKEN=$(cat /run/secrets/token) && \ echo "API_KEY=$TOKEN" > /app/config.env # ❌ 写入了文件！ FROM python:3.11-slim COPY --from=builder /app/config.env /app/config.env # ❌ 复制了含密钥的文件！

解决方案不是禁止写文件，而是在 builder 阶段写入后立即清理，或用--chown控制所有权：

# 正确示范：清理与隔离 FROM python:3.11 AS builder RUN --mount=type=secret,id=token \ TOKEN=$(cat /run/secrets/token) && \ echo "API_KEY=$TOKEN" > /tmp/config.env && \ # 立即复制到目标位置并清理 cp /tmp/config.env /app/config.env && \ rm -f /tmp/config.env # final 阶段只复制必要文件，且不复制 config.env FROM python:3.11-slim COPY --from=builder /app/requirements.txt /app/requirements.txt RUN pip install --no-cache-dir -r /app/requirements.txt COPY --from=builder /app/src /app/src # config.env 不复制！运行时通过其他方式注入

5.3 CI/CD 中的秘密轮换：自动化不是选择，而是义务

硬编码在 CI/CD 变量中的密钥，其生命周期必须可控。一个成熟的做法是结合 HashiCorp Vault 或 AWS Secrets Manager：

# GitHub Actions 示例：从 Vault 动态获取 - name: Get secrets from Vault uses: hashicorp/vault-action@v2.8.0 with: url: https://vault.internal method: token token: ${{ secrets.VAULT_TOKEN }} env: VAULT_ADDR: https://vault.internal - name: Build with dynamic secrets run: | # Vault 会把 secrets 注入为环境变量 docker buildx build \ --secret id=api_key,env=VAULT_API_KEY \ --secret id=db_pass,env=VAULT_DB_PASS \ -t myapp .

轮换策略的核心是：所有密钥必须有明确的过期时间（TTL）。在 Vault 中创建 secret 时，设置ttl=1h，并在 CI job 开头强制刷新。这样即使某个 job 的 secret 泄露，其有效期也极短。我在一家金融客户那里实施此方案后，密钥平均暴露窗口从“永久”缩短到“47 分钟”。

6. Docker Compose 集成：多服务架构下的秘密治理

6.1 Compose 文件结构：集中定义，按需分发

Docker Compose v2.20+ 原生支持 build secrets，其设计思想是“声明式秘密管理”：在docker-compose.yml顶层定义所有秘密，然后在各 service 的build.secrets中声明依赖，而非在每个 Dockerfile 中硬编码路径。

# docker-compose.yml version: '3.8' # 顶层 secrets 定义（集中管理） secrets: # 来源：本地文件（开发环境） internal_api_key: file: ./secrets/internal-api-key.txt # 来源：环境变量（CI/CD 环境） db_password: environment: DB_PASSWORD # 来源：外部服务（生产环境） vault_token: external: true services: web: build: context: ./web # 声明此服务构建时需要哪些 secrets secrets: - internal_api_key - db_password # 运行时 secrets（与 build secrets 分离！） secrets: - internal_api_key api: build: context: ./api secrets: - internal_api_key - vault_token secrets: - internal_api_key - vault_token db: image: postgres:15 # db 服务不参与构建，故无 build.secrets environment: POSTGRES_PASSWORD_FILE: /run/secrets/db_password secrets: - db_password

对应的./web/Dockerfile保持简洁：

# syntax=docker/dockerfile:1 FROM nginx:alpine # 只需声明挂载，无需关心来源 RUN --mount=type=secret,id=internal_api_key \ --mount=type=secret,id=db_password \ # 使用 secrets 构建配置 echo "API_KEY=$(cat /run/secrets/internal_api_key)" > /etc/nginx/conf.d/api.conf

构建命令变得极其简单：

# 开发环境：自动读取本地文件 docker compose build # CI/CD 环境：注入环境变量 DB_PASSWORD=xxx docker compose build # 生产环境：Vault 集成（需额外配置） docker compose --file docker-compose.prod.yml build

6.2 秘密作用域隔离：避免服务间“秘密污染”

一个关键安全原则是：服务 A 的构建秘密，绝不应出现在服务 B 的构建过程中。Compose 的secrets定义天然支持此隔离。但在实践中，团队常犯的错误是把所有秘密都定义在顶层，然后每个 service 都secrets: [all_secrets]。这违背了最小权限。

正确的做法是按服务职责划分：

• web服务：只需internal_api_key（调用内部 API）
• worker服务：只需db_password（连接数据库）和redis_password（连接 Redis）
• monitoring服务：只需prometheus_token（推送指标）

secrets: internal_api_key: {file: ./secrets/web-api-key.txt} db_password: {environment: DB_PASSWORD} redis_password: {environment: REDIS_PASSWORD} prometheus_token: {environment: PROMETHEUS_TOKEN} services: web: build: secrets: [internal_api_key] # 仅此一个 worker: build: secrets: [db_password, redis_password] # 仅这两个 monitoring: build: secrets: [prometheus_token] # 仅此一个

这样，即使worker服务的构建环境被攻破，攻击者也无法获取web服务的 API Key，实现了严格的横向隔离。

7. 真实世界故障复盘：从事故中提炼的不可妥协原则

7.1 事故复盘：某 SaaS 公司的“双密钥泄露”事件

事件简述：该公司发布新版本时，CI 流水线突然失败，错误日志显示curl: (56) GnuTLS recv error (-110): The TLS connection was non-properly terminated.。运维紧急回滚，但安全团队在扫描旧镜像时发现，docker history输出中赫然有ARG GIT_TOKEN=ghp_abc123...，且该 token 在 GitHub 上已被标记为泄露。

根因分析：

• 直接原因：开发人员为调试git clone，在 Dockerfile 中临时添加了ARG GIT_TOKEN，并用--build-arg GIT_TOKEN=...构建。
• 深层原因：团队没有强制的