镜像仓库安全加固核心是控制谁能看到、谁能推送、推送的内容是否可信；需强制身份认证与细粒度权限、启用镜像签名验证、漏洞扫描阻断高危发布、隔离网络并留存完整审计日志。
镜像仓库安全加固核心是控制谁能看到、谁能推送、推送的内容是否可信。重点不在“装得多”，而在“管得严、验得准、查得勤”。
启用身份认证与细粒度权限控制
公开仓库（如默认 Docker Hub）或内部自建仓库（如 Harbor、Nexus、GitLab Container Registry）必须关闭匿名访问。所有操作强制登录，且按角色分配最小必要权限。
- Harbor 中为项目设置“访客”“开发者”“维护者”等角色，禁止普通用户拥有 admin 或 project-admin 权限
- Docker Hub 使用团队（Team）和组织（Organization）管理成员，禁用个人账号直接 push 到组织仓库
- 使用 LDAP/AD 或 OIDC 集成统一身份源，避免本地密码分散管理
强制镜像签名与内容验证
不验证签名的 pull 操作等于信任任意来源——哪怕来自你自己的仓库。Docker Content Trust（DCT）或 Cosign 是主流方案。
- 启用 DCT 后，docker pull 默认只拉取已签名镜像；未签名或签名失效会拒绝拉取
- Harbor 支持配置“签名策略”，可强制要求所有推送到特定项目的镜像必须由指定密钥签名
- Cosign 更轻量、兼容 OCI 标准，适合 CI 流水线中自动签名：
cosign sign --key cosign.key my-registry/my-app:v1.2
扫描镜像漏洞并阻断高危发布
镜像不是“构建完就安全”，基础镜像、依赖包、甚至应用代码都可能含 CVE。扫描必须在推送前完成，并设为流水线门禁。
- Harbor 内置 Trivy 扫描器，可配置“严重/关键漏洞禁止推送”策略
- CI 中集成 Trivy 或 Snyk：扫描失败时 立即终止构建，不生成镜像也不上传
- 定期对存量镜像重新扫描（例如每周一次），尤其当新 CVE 公布后
隔离网络与审计日志不可少
仓库本身要是“内网堡垒”，所有访问行为必须留痕、可追溯。
- 将镜像仓库部署在独立网络区段，仅开放 HTTPS（443）端口给 CI/CD 和 K8s 节点，禁用 HTTP
- 开启完整操作审计日志（push/pull/delete/login/fail login），日志至少保留 180 天，接入 SIEM 系统
- 对敏感操作（如删除镜像、修改项目权限）设置二次确认或审批流程（Harbor 支持 webhook 对接审批系统）
不复杂但容易忽略——安全不是加个认证就完事，而是从开发提交代码那一刻起，签名、扫描、权限、日志就该串成一条闭环链。
