from指令本身不产生运行时日志，审计必须聚焦构建源头：强制显式指定标签或digest、ci/cd中提取并记录基础镜像信息、通过私有仓库代理拉取并启用审计日志、结合label固化来源元数据、统一代理仓库管控入口。
Docker 基础镜像的 FROM 指令本身不产生运行时日志，它只在构建阶段起作用，属于 Dockerfile 的静态声明。因此，“对 FROM 做审计日志”不能靠容器运行后抓取，而必须聚焦在镜像构建源头、拉取行为、以及构建上下文的可追溯性上。核心目标是：知道谁、何时、基于什么基础镜像（含标签/摘要）、从哪个仓库拉取并用于构建。
以下是真正可行且生产可用的审计路径：
明确基础镜像来源并强制记录
- 所有 Dockerfile 必须显式指定带标签或 digest 的
FROM，禁用裸名（如FROM ubuntu），改用FROM ubuntu:22.04或更安全的FROM ubuntu@sha256:abc123... - 在 CI/CD 流水线中加入校验脚本，自动提取
FROM行并写入构建元数据（如 Git commit、触发人、时间、基础镜像 digest） - 示例提取命令：
grep -E '^FROM' Dockerfile | head -1 | awk '{print $2}' | xargs -I {} docker inspect --format='{{.RepoDigests}}' {}
审计基础镜像的拉取行为
- Docker daemon 默认不记录
docker pull谁拉了哪个镜像，但可通过以下方式补全：- 启用
journald日志驱动后，执行journalctl -u docker | grep "pull.*ubuntu"可看到 UID 和命令行（需开启--log-driver=journald） - 更可靠的方式：统一通过私有仓库（如 Harbor）代理所有拉取请求，Harbor 的审计日志天然记录
pull操作，含用户名、IP、镜像路径、时间戳
- 启用
结合镜像构建历史做反向溯源
- 构建完成的镜像可通过
docker image inspect <image></image>查看RootFS.Layers和Metadata.LastTagTime，但关键信息在History中：docker history --no-trunc myapp:latest | head -n 5
- 配合
--format '{{.CreatedBy}}'提取每层命令，定位FROM对应的原始镜像 ID 或 digest - 若启用 Docker Content Trust（DCT），
FROM镜像必须带签名，DOCKER_CONTENT_TRUST=1 docker build会失败于未签名基础镜像——这本身就是一种强审计约束
在构建产物中固化 FROM 审计信息
- 利用
LABEL将基础镜像信息写入最终镜像：ARG BASE_IMAGE=nginx:1.25 FROM $BASE_IMAGE LABEL base_image="$BASE_IMAGE" LABEL base_image_digest=$(echo "$BASE_IMAGE" | sed 's/.*@//')
- 构建时传参并解析 digest（需配合脚本预处理），确保
docker inspect能直接查到可信来源
统一管控入口：禁止直连公共仓库
- 通过 Nexus/Harbor 配置代理仓库 + 拉取策略（如仅允许白名单 registry），所有
FROM引用都经由内部仓库解析 - 开启仓库级审计日志，就能完整追踪：谁在什么时间、为哪个项目、拉取了哪个
FROM镜像用于构建
本质上，FROM 审计不是事后翻日志，而是把“谁用了什么基础镜像”变成构建流程中不可绕过的元数据采集点。
