docker自身不支持rbac，需依赖外部镜像仓库（如harbor）或外挂oidc+opal实现精细化权限控制；harbor项目级rbac最易落地，配合机器人账号、签名强制、审计日志与策略即代码持续验证权限有效性。
Docker本身不内置RBAC权限控制，真正的精细化权限管理必须依赖外部镜像仓库（如Harbor、Nexus或带鉴权层的Registry），而不是Docker CLI或daemon。核心思路是：把权限控制下沉到仓库服务端，通过角色、项目、机器人账号和策略引擎协同实现“谁在什么条件下能对哪些资源做什么”。
用Harbor做项目级RBAC是最直接落地的方式
Harbor原生支持以项目为边界的RBAC，适合大多数企业场景：
- 为每个业务线、微服务或环境（dev/staging/prod）单独创建私有项目，禁用public项目共享
- 按角色分配最小权限：访客（只读Pull）、开发者（Pull+Push）、项目管理员（含删除、扫描配置、成员管理）
- 用户组优先用LDAP/AD同步，避免手动维护；个人账户不直接用于CI/CD，改用机器人账号
- 开启项目级“签名必需”，要求所有推送镜像必须经Cosign或Notary v2签名，否则拒绝入库
轻量级Registry需外挂OIDC+OPAL实现动态策略
若使用官方registry:latest，它默认无RBAC，必须加一层鉴权网关：
- 用Keycloak或Auth0作为OIDC身份源，所有拉取/推送请求先走OAuth2令牌校验
- 部署OPAL服务监听Git中.rego策略文件变更，实时向Registry网关下发规则
- 策略可带上下文：例如“允许dev-team拉取prod/**仅当标签含-rc-且时间在工作日9–18点”
- 配合nginx或traefik做反向代理，在proxy_pass前注入鉴权头或调用OPAL决策API
机器人账号与审计日志是权限落地的关键支撑
再好的策略设计，缺乏执行约束和事后追溯就形同虚设：
- 每个CI流水线（Jenkins/GitLab CI）绑定独立机器人账号，作用域限定为单一项目+仅Pull/Push
- 禁用长期有效的个人Token，所有机器人账号设置自动过期（如90天）并强制轮换
- 启用Harbor系统日志或Registry audit log，重点采集failed auth、delete artifact、role change事件
- 日志接入ELK或Splunk，配置告警规则：例如“1小时内同一IP连续5次鉴权失败”
权限不是一次配置完就结束，要持续评审与验证
RBAC的有效性依赖定期闭环：
- 每季度执行权限评审：检查是否存在冗余角色、僵尸机器人账号、越权成员
- 用curl + Token模拟各角色操作，验证实际行为是否符合预期（例如访客能否push、开发者能否delete）
- 在CI流程中嵌入权限检查步骤：推送前调用Harbor API校验当前Token是否有目标项目的Push权限
- 把.rego策略、Harbor项目配置YAML、机器人账号清单纳入Git版本管理，做到配置即代码
