核心是分库、分权与签名验证三位一体：按项目或环境（如finance-prod、dev-team-a）物理/逻辑分库，结合RBAC最小权限分配，并强制启用Docker Content Trust校验镜像完整性与来源可信。
核心是分库 + 分权 + 验证，不是只靠一个账号密码控制所有镜像。
按用途或团队分库，物理或逻辑隔离
别把所有镜像堆在一个仓库里。比如用 Harbor 时，为不同项目或环境建独立项目（Project）：finance-prod、dev-team-a、qa-staging。每个项目自带独立存储配额、网络策略和扫描规则。开发团队推送镜像只能进 dev-team-a，生产部署节点默认只允许从 finance-prod 拉取，天然阻断误操作越界。
- 金融类项目单独建库，限制 CIDR 访问范围，禁止公网出口
- 测试镜像库关闭自动扫描，但启用镜像签名强制校验
- 基础镜像库（如 ubuntu:20.04、openjdk:17）设为只读，仅管理员可更新
用 RBAC 绑定角色，不给“万能账号”
Harbor 或私有 Registry 支持基于角色的权限分配，每个用户/服务账户只赋予最小必要动作。例如：
- CI/CD 流水线用专用机器人账号，只配 push 权限，且仅限指定项目
- 运维人员有 pull + delete，但不能修改项目配置
- 生产服务器节点只绑定 pull-only 账号，凭证嵌入 kubelet 或 systemd service 文件中
避免使用 root 或 admin 全局账号做日常推送——这类账号一旦泄露，等于交出全部镜像控制权。
启用内容信任与签名验证
光靠账号权限不够，还要确认镜像没被篡改、来源可信。Docker Content Trust（DCT）机制可强制要求：
- 开启 DOCKER_CONTENT_TRUST=1 环境变量，让 docker pull 自动校验签名
- 在 Harbor 中开启“内容信任”开关，并为项目配置可信根证书
- CI 流水线构建完必须用 notary sign 打签名，未签名镜像禁止推送到 prod 项目
这样即使有人绕过权限拿到镜像层，也无法在开启 DCT 的环境中运行未经签名的镜像。
定期审计与凭证轮换
权限不是设完就一劳永逸。建议：
- 每月导出 Harbor 项目成员列表和权限快照，比对是否有冗余账号或越权角色
- 机器人账号密码/Token 每 90 天自动轮换，配合 CI 工具（如 Jenkins Credentials Binding）安全注入
- 禁用长期有效的个人 access token，改用短期 JWT 或 OIDC 联合登录
不复杂但容易忽略。
