密钥绝不可硬编码或通过构建参数注入 Dockerfile，否则会残留于镜像层并被轻易提取；应运行时挂载文件、环境变量注入或集成 Secret 管理服务，构建阶段仅限 BuildKit --secret 临时使用。
直接在 Dockerfile 中硬编码或通过构建参数注入密钥（如 API Key、SSH 私钥、数据库密码等），会带来严重安全风险：密钥可能残留于镜像层中，即使后续 RUN 命令删除文件，仍可通过 docker history 或镜像解包轻易提取。一旦镜像被推送至共享仓库（如 Docker Hub 或私有 Registry），密钥即等同于公开。
避免在构建阶段暴露密钥
核心原则是——密钥不应出现在任何镜像层里。以下做法必须禁止：
- 使用
COPY或ADD指令复制含密钥的本地文件（如config.json、id_rsa） - 通过
ARG+ENV传入密钥并写入环境变量（ENV SECRET=$API_KEY） - 在
RUN命令中用echo或curl下载/写入密钥（即使紧接着rm，该层仍保留内容）
推荐的安全替代方案
将密钥与镜像构建过程解耦，延迟到容器运行时注入：
-
运行时挂载文件：启动容器时用
docker run -v /host/secrets:/app/secrets:ro挂载宿主机上的密钥文件，确保权限为600，且不打包进镜像 -
环境变量注入（非构建时）：使用
docker run --env-file .env或编排工具（如 Docker Compose 的environment+env_file）传入，避免出现在构建上下文或镜像历史中 -
Secret 管理服务集成：在 Kubernetes 中用
Secret对象挂载；在 Docker Swarm 中用docker secret；或对接 HashiCorp Vault、AWS Secrets Manager 等，在应用启动时按需拉取
若必须在构建中访问私有资源（如 Git 仓库、私有包源）
可有限度使用构建时凭据，但需严格控制生命周期：
- 启用 Docker BuildKit（
DOCKER_BUILDKIT=1），利用--secret机制：docker build --secret id=ssh_key,src=$HOME/.ssh/id_rsa .，并在 Dockerfile 中用RUN --mount=type=secret,id=ssh_key ...临时挂载，进程退出后自动销毁 - 对私有包源（如 pip private index、npm registry），优先配置
.netrc或auth.conf并通过--secret注入，而非写死在requirements.txt或package.json - 构建完成后立即清理构建节点上的临时凭据，避免残留
加强构建环境与流程管控
技术手段之外，流程同样关键：
- 限制 CI/CD 系统中构建任务的权限，避免密钥被任意 job 提取；使用短期令牌（如 GitHub OIDC、AWS STS）替代长期密钥
- 对基础镜像和中间镜像定期扫描（如 Trivy、Snyk），检测意外写入的密钥字符串或私钥格式文件
- 在 CI 流水线中加入静态检查步骤，禁止提交含
SECRET=、password:、-----BEGIN RSA PRIVATE KEY-----等模式的 Dockerfile 或构建脚本
