必须通过宿主机 auditd 监控 docker cli 调用才能准确定位误删责任人，因镜像仓库默认不记录细粒度删除操作；auditd 可精确捕获执行用户、完整命令、时间及源 ip，而 harbor 等仓库日志仅能辅助佐证且存在 token 匿名化等局限。
不能直接靠镜像仓库本身“自动记录谁删了哪个镜像”——Docker 官方 registry（包括 Harbor、Nexus 等主流私有仓库）默认不开启细粒度操作审计，尤其是删除动作。要准确定位误删镜像的责任人，必须提前部署系统级审计能力，核心是 在宿主机层面捕获 docker 命令调用行为，而非依赖仓库日志。
关键路径：用 auditd 监控所有 docker CLI 调用
多人共用一台 Docker 主机时，真正的操作源头是用户执行的 docker rmi、docker image prune 或 docker system prune -a 等命令。auditd 可以精确记录：
- 执行命令的用户名（不是 root，而是实际登录用户）
- 完整命令行参数（例如是否带
-f、删的是 ID 还是repo:tag） - 进程启动时间、终端（tty）、源 IP（若通过 SSH 登录）
- 调用链：哪个 shell 启动了 docker 二进制文件
快速启用 auditd 捕获 docker 删除操作
在 Docker 主机上运行以下命令即可生效（需 root 权限）：
sudo auditctl -a always,exit -F path=/usr/bin/docker -F perm=x -F key=docker-cmd-
sudo auditctl -a always,exit -F path=/usr/bin/dockerd -F perm=x -F key=docker-daemon（可选，监控守护进程自身） - 确保规则持久化：将上述行加入
/etc/audit/rules.d/docker.rules，再运行sudo augenrules --load
之后所有 docker rmi 行为都会写入 /var/log/audit/audit.log，可用如下命令即时检索：
sudo ausearch -k docker-cmd | aureport -f -i | grep "rmi\|prune"sudo ausearch -m execve -i -ts recent | grep -i "docker.*rmi"
结合镜像元数据缩小排查范围
如果已知被删镜像的名称或 ID，可交叉验证：
- 用
docker inspect <image-id></image-id>查看其Labels（如org.opencontainers.image.created、com.example.team），确认归属项目与构建时间 - 检查该镜像是否曾被容器引用：
docker ps -a --filter ancestor=<image-id> --format "{{.ID}} {{.Names}} {{.Status}}"</image-id>，若存在已退出容器，说明它近期被使用过，删除更可疑 - 对比
docker images输出中缺失的REPOSITORY:TAG和 audit 日志中的命令参数，锁定精确匹配项
私有仓库侧的辅助线索（非主依据）
Harbor、Nexus 等支持开启操作日志，但注意其局限性：
- Harbor 需在
harbor.yml中启用log.level: debug并配置log.driver: syslog，才可能记录DELETE /api/v2.0/projects/xxx/repositories/yyy/artifacts/zzz请求 - 日志里通常只有 token 所属用户（可能是 CI 机器人账号），无法还原到具体操作人；且 Web UI 删除不经过 API，无记录
- 仅当镜像通过
docker push推送后又被curl -X DELETE删除时，才有较完整上下文
因此，仓库日志只能作为佐证，不能替代宿主机 auditd 的原始命令审计。
