构建自动化审计日志镜像分发体系需内嵌审计于仓库层，首选Harbor实现结构化、不可篡改、身份绑定的操作留痕，并支持JSON日志、上下文关联、Webhook告警及自动响应闭环。
构建具备自动化审计日志功能的镜像分发体系，核心在于将日志采集、操作追踪与镜像生命周期深度绑定，而非仅依赖外部监控。关键不是“加个日志组件”，而是让每一次推送、拉取、扫描、签名、删除都生成结构化、不可篡改、可追溯的审计事件。
审计能力必须内嵌到仓库层
单纯在容器运行时打日志或用宿主机日志收集器捕获 docker pull 命令，覆盖不全且易被绕过。真正有效的审计起点是镜像仓库本身：
- 选用原生支持审计日志的仓库方案，如 Harbor —— 它默认开启操作审计（push/pull/delete/scan/sign），日志包含操作者、时间、IP、镜像名、标签、摘要（digest）、HTTP状态码及响应耗时；
- 避免使用裸 registry:2，它无内置审计能力，需自行接入反向代理（如 Nginx）记录 access log，但无法识别镜像层级操作或用户身份（仅能记录 token 或 IP）；
- Harbor 审计日志默认输出到 /var/log/harbor/audit.log，支持对接 Syslog、Kafka 或 ELK，也可通过 API（/api/v2.0/audit-log）按时间范围、用户名、资源类型查询。
关键操作必须强制留痕并关联身份
审计价值取决于操作是否真实可归责。需关闭匿名访问，确保每个动作绑定明确主体：
- 禁用 Harbor 的“Anonymous Access”；所有用户通过 LDAP/OIDC 或本地账户登录，禁止直接用 admin token 批量操作；
- 为 CI/CD 系统创建专用机器人账户（Robot Account），命名体现用途（如 ci-jenkins-prod-push），并限制其仅对指定项目（Project）有 push 权限；该账户的所有 push 行为在审计日志中清晰标记来源；
- 启用 Docker Content Trust（DCT）后，每次 docker push --sign 和 docker pull --disable-content-trust=false 都会触发签名验证事件，日志中记录密钥 ID、签名时间、验证结果，形成可信链证据。
日志需结构化、防篡改、带上下文
原始文本日志难以分析。应推动日志升级为机器可读格式，并锚定关键上下文：
- 配置 Harbor 将 audit.log 输出为 JSON 格式（修改 harbor.yml 中 audit_log_location: json），字段含 user_name、repo_name、tag、digest、operation、status、repo_type（image/helm）；
- 在 CI 流水线中，于 docker push 后主动调用 Harbor API 记录构建上下文：例如将 Git Commit SHA、Jenkins Build ID、触发分支写入镜像 label（org.opencontainers.image.revision），再通过 Harbor 的 artifact API 关联该镜像的 audit 日志条目；
- 对高敏操作（如删除 latest 标签、覆盖已发布镜像）配置 Webhook，实时推送到 SIEM 系统，并触发告警；Harbor 支持自定义 webhook payload，可包含操作人邮箱、源 IP 地址段归属信息。
审计闭环：从日志到响应
日志不是摆设。需建立基于审计数据的自动响应机制：
- 用 Logstash 或 Fluentd 过滤出 status=500 或 operation=delete 的高频事件，自动暂停对应用户账户并通知安全团队；
- 定期执行审计合规检查脚本：例如扫描过去7天内所有未扫描即拉取至生产环境的镜像（通过匹配 pull 日志中的 repo_name 与 scan_job 成功日志），生成风险报告；
- 将镜像 digest 与 SBOM（软件物料清单）哈希值绑定存储，在审计日志中引用 SBOM ID；一旦某镜像被通报存在 CVE，可快速定位所有已拉取该 digest 的集群节点并下发阻断策略。
