结论：企业需用Harbor等支持项目级RBAC的仓库，通过项目隔离、最小权限、机器人账号、签名强制和审计联动五点实现多团队CI安全。
直接说结论：Docker本身不提供RBAC，企业要实现多团队CI安全，必须用Harbor这类支持项目级RBAC的仓库，并围绕“项目隔离+角色最小化+机器人账号+签名强制+审计联动”五点落地。
按团队/环境建独立项目，物理隔离权限边界
每个开发团队、测试组或部署环境（dev/staging/prod）都创建一个私有项目，禁用默认public项目。项目设为“不可见”，避免未授权拉取。例如：
- frontend-team项目：仅前端团队成员可Push/Pull
- backend-prod项目：仅后端SRE和发布流水线能Pull，禁止Push
- shared-lib项目：开放只读给所有团队，但禁止删除和覆盖
角色分配遵循最小权限，禁用默认高权配置
Harbor内置角色需重新校准使用习惯：
- 访客（Guest）：仅Pull + 查看扫描报告，不能触发扫描或查看日志
- 开发者（Developer）：显式勾选“Push Artifact”，默认不带Delete权限
- 项目管理员（Project Admin）：可管理成员、设置扫描策略，但无系统级操作权限
- 避免给个人账户直接赋Admin角色，改用组同步（LDAP/AD）统一管控
CI流水线全部绑定机器人账号，杜绝凭证泄露
每个Jenkins Job或GitLab CI Pipeline使用专属机器人账号，且严格限定作用域：
- 命名规范如：ci-frontend-dev、robot-backend-staging
- 作用域锁定为单一项目，权限仅限Pull或Push（不混用）
- 启用自动过期（如90天），到期前通过Webhook通知更新
- 禁用长期有效的个人Token，所有CI凭证生命周期由Harbor统一管理
签名强制+漏洞扫描嵌入CI流程，权限与内容双重校验
权限控制不止于“谁可以推”，更要确保“推的是什么”：
- 在项目中开启“Signature Required”，未签名镜像Push直接被拒绝
- CI阶段用Cosign签名：cosign sign --key cosign.key $IMAGE_NAME
- 扫描策略设为“阻断高危漏洞”，Trivy扫描失败则Pipeline中断并告警
- Kubernetes集群侧用Kyverno验证镜像签名状态，未签名或签名失效的镜像禁止部署
审计日志接入SIEM，关键行为实时监控告警
权限有效性依赖可观测性支撑：
- 启用Harbor系统日志，采集failed auth、delete artifact、role change等事件
- 日志转发至ELK或Splunk，配置规则如：“1小时内同一IP连续5次鉴权失败”触发告警
- 每季度执行权限评审：清理僵尸机器人账号、检查越权成员、验证角色实际行为是否符合预期
- 所有策略配置（.rego文件、项目YAML、机器人清单）纳入Git版本管理，实现配置即代码
