答案是必须从源头防止敏感信息写入镜像层。docker镜像层不可变，run rm或--change无法真正删除历史层中的明文密码；应禁用env/run硬编码、采用buildkit --secret临时注入、多阶段构建只复制安全产物，并严格配置.dockerignore排除敏感文件。

不能靠“擦除”，得从源头防止写入。Docker 镜像层不可变，RUN rm 或 docker commit --change 这类操作无法真正删除历史层里的敏感内容，只能掩盖表象。真正安全的做法是确保敏感配置压根没进镜像。

检查镜像是否已含敏感信息

导出或推送前必须验证：

• 运行 docker history --no-trunc 镜像名，逐行查看构建命令，重点识别 echo 'pwd=xxx'、curl -u user:pass、sed -i 's/key=.*/key=abc/' 等明文操作
• 执行 docker inspect 镜像名，检查 Config.Env 和 Config.Labels 字段，确认没有 DB_PASSWORD、AWS_SECRET_ACCESS_KEY 等硬编码值
• 用 trivy image --secret 镜像名 扫描文件系统，自动匹配 PEM 私钥、JWT token、高熵字符串等常见密钥模式

构建阶段就隔离敏感配置

这是最有效、最根本的防线：

minimax-mcp-docker版（适配极空间）

MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。

下载

• 禁止在 Dockerfile 中使用 ENV API_KEY=xxx 或 RUN echo "token=..." > config.env —— 这些会永久留在某一层元数据或文件中
• 改用 BuildKit 的 --secret 机制：构建时临时挂载凭据，内存中使用，不落盘、不写层。例如：
  docker build --secret id=aws,src=./aws-cred .
  配合 Dockerfile 中 RUN --mount=type=secret,id=aws cat /run/secrets/aws > /tmp/creds
• 采用多阶段构建：把需要密钥的操作（如拉私有包、生成带认证的配置）放在 builder 阶段；runtime 阶段只 COPY --from=builder 编译产物或脱敏后的配置文件，绝不复制源码、.env、secrets.json 等

构建上下文和文件过滤要严格

很多泄露其实来自 COPY 操作误包含本地敏感文件：

• 务必配置 .dockerignore，显式排除：.env、secrets/**、config/*_prod.*、**/id_rsa*、.git、node_modules
• 避免无脑 COPY . .，改为精确指定路径，例如 COPY src/ app/src/
• 构建前用 docker build --no-cache --progress=plain . | grep -i "copy.*\.env" 快速确认是否意外引入了敏感文件

导出后做轻量验证

哪怕流程再严谨，导出后快速抽检能兜底：

• 执行 docker save 镜像名 | tar -t | grep -E "(config|\.env|\.yml|\.json|\.pem|\.key)"，筛查可疑路径是否存在
• 解压 tar 包（docker save 镜像名 | tar -xO）后，对各 layer 目录运行 grep -r "password\|secret\|key=" .
• 若发现残留，不要修补旧镜像，应修正 Dockerfile 后重新构建 —— 修补只是掩耳盗铃