容器镜像仓库和镜像源安全本质是守住软件供应链入口，需通过机制保障可信度：选经验证的官方或最小化基础镜像、强制校验摘要、实施RBAC与HTTPS、启用Cosign签名与Kubernetes准入验证、结合SBOM，并建立扫描—更新—下线闭环。
容器镜像仓库和镜像源的安全，本质是守住软件供应链的入口。可信度不是靠“感觉”，而是靠机制——从谁构建、怎么存、谁拉取、是否被改过，每个环节都要有验证手段。
选对源头：只用经过验证的基础镜像
官方镜像（如 docker.io/library/ubuntu:22.04、nginx:alpine）默认经过基础安全审查，更新及时、漏洞响应快。企业应明确禁止直接使用未认证的第三方镜像（例如 Docker Hub 上个人账号发布的同名镜像），尤其避免使用含调试工具、SSH 服务或 root 权限默认开启的非精简镜像。
- 优先采用最小化发行版镜像，比如 Alpine、Distroless 或 UBI Minimal
- 内部统一维护基础镜像清单，定期扫描并发布更新版本号（如 myreg.example.com/base/alpine:3.19-202606）
- 在 CI 流水线中强制校验基础镜像摘要（sha256:...），而非仅依赖标签（tag），防止 tag 被覆盖导致意外交替
管住仓库：访问控制 + 加密 + 审计日志
私有镜像仓库不能只是“能推能拉”，必须具备企业级权限治理能力。Harbor、Nexus Repository、AWS ECR 等主流方案都支持基于角色的细粒度控制，关键在于落地配置。
- 启用 HTTPS 强制通信，禁用 HTTP 协议访问
- 为不同团队/项目分配独立命名空间（project），设置 push/pull/read-only 权限，避免全员 admin
- 开启操作审计日志，记录谁、何时、对哪个镜像做了 pull/push/delete/sign 操作，日志需集中留存至少 180 天
- 敏感项目镜像仓库与公网隔离，仅允许通过跳板机或 CI 系统专用账号访问
签好每一张“数字身份证”：签名验证不可绕过
签名不是锦上添花，而是运行前的硬性门禁。它同时解决两个问题：镜像没被篡改（完整性），以及确实出自你信任的流水线（来源可信）。
- 使用 Cosign 或 Docker Content Trust (DCT) 对所有生产镜像签名，私钥由密钥管理服务（如 HashiCorp Vault、AWS KMS）托管，不落地 CI 机器
- 在 Kubernetes 集群中部署 Kyverno 或 OPA Gatekeeper 准入控制器，策略设为：“拒绝拉取未签名或签名验证失败的镜像”
- 配合 SBOM（软件物料清单） 生成（如 Trivy 输出 SPDX/Syft 格式），将组件清单与签名绑定，便于快速定位漏洞影响范围
持续运营：扫描+更新+下线闭环
镜像不是一次构建就一劳永逸。一个未更新的基础镜像可能半年内累积数十个高危 CVE，而旧版镜像若长期保留在仓库中，仍可能被误引用。
- 在 CI 构建阶段嵌入 Trivy 或 Grype 扫描，失败则阻断发布；生产镜像还需每月执行一次全量重扫
- 建立镜像生命周期策略：非生产镜像保留 90 天，生产镜像保留 18 个月，超期自动归档或标记为 deprecated
- 对已知存在严重漏洞的基础镜像（如含 log4j 1.x 的旧 Java 镜像），主动推送 deprecation notice，并提供升级路径指引
