禁止在 run 中硬编码凭证，应使用构建参数、多阶段构建或密钥管理服务动态注入敏感信息。run 命令固化凭证至镜像层，无法清除；--build-arg 仅构建时有效；多阶段构建确保最终镜像不含敏感数据；kms 提供可审计、可轮换的凭证管理。
构建镜像时，RUN 指令本身不传输数据，但它执行的命令若包含密钥、密码或令牌（比如 curl -u user:pass 或 pip install --index-url https://token@pypi.example.com），这些敏感信息会固化进镜像层——哪怕只用一次，也会留在历史记录里，极易被反向提取。
禁止在 RUN 中硬编码凭证
这是最常见也最危险的做法。例如：
RUN curl -sS https://api.example.com/deploy?token=abc123 | sh
该 token 会完整保留在该层镜像中，即使后续用 rm 删除脚本也无法清除。
- 任何能拉取该镜像的人都可通过
docker history --no-trunc或docker image inspect查看命令历史 - CI/CD 日志若未脱敏，也可能泄露 token
- 不符合《网络安全法》第21条“采取技术措施保障网络免受干扰、破坏和非法使用”
用构建参数（--build-arg）+ 构建时临时注入
适用于需在构建阶段访问私有源（如内网 PyPI、Git 仓库、License 服务器）的场景：
- 定义参数但不设默认值：
ARG DEPLOY_TOKEN - 构建时传入：
docker build --build-arg DEPLOY_TOKEN=xxx -t app . - 关键限制：该参数不会写入镜像层，仅在构建时可用；且必须配合
--squash或多阶段构建，避免残留 - ⚠️ 注意：不要在 Dockerfile 中
echo $DEPLOY_TOKEN或写入文件，否则仍会落盘
优先采用多阶段构建 + 构建上下文隔离
把敏感操作放在临时构建阶段，最终镜像只保留运行时必需内容：
- 第一阶段：用
ARG获取 token，下载依赖、编译代码、生成产物 - 第二阶段：基于轻量基础镜像（如
alpine:latest），仅COPY --from=0 /app/dist ./ - 敏感凭证 never touch final image，连构建缓存都不跨阶段保留
- 示例：从私有 Git 仓库拉代码 → 编译 → 只复制二进制到 scratch 镜像
对接密钥管理服务（KMS）动态获取
适合企业级 CI 环境，将凭证解耦出构建流程：
- 在 CI 节点配置 KMS 访问权限（如 Vault token、AWS IAM Role）
- 构建脚本中调用 KMS API 获取短期 token：
curl -s $VAULT_ADDR/v1/secret/data/deploy-token --header "X-Vault-Token: $VAULT_TOKEN" - 将 token 注入构建过程（如通过
--build-arg或挂载临时文件），并确保不记录日志 - 优势：凭证生命周期可控、可审计、支持轮换与吊销
