用权限组管理多团队协作的核心是按角色建组并明确“谁能在哪个项目里做什么”，如dev-team-a、qa-group、ops-admins；项目命名需含团队与环境标识，便于批量匹配权限；生产环境默认只读，严格区分读写；定期清理无效权限。
用权限组管理多团队协作，核心是把“谁能在哪个项目里做什么”这件事明确下来，而不是靠人工提醒或口头约定。关键不在仓库数量多少，而在权限是否按需分配、是否容易维护。
按角色建权限组，别按人设权限
给每个典型角色（如开发、测试、运维、安全审计）单独建组，而不是给每个成员单独配权限。比如：
- dev-team-a：对 team-a-prod 项目有 push/pull 权限，但不能删除镜像
- qa-group：只对所有 -test 结尾的项目有 pull 权限
- ops-admins：拥有全部项目的管理员权限，但操作需二次确认或留审计日志
这样新增成员时，只需加入对应组；调整策略时，改一组就全局生效。
项目命名带环境和团队标识
仓库项目名本身要能反映归属和用途，方便权限规则批量匹配。推荐格式：{团队}-{环境}-{类型}，例如：
- mobile-dev-docker
- finance-prod-helm
- ai-sandbox-cnab
有了这种结构，权限策略就能写成“允许 mobile 组访问所有 mobile-* 项目”，不用逐个配置。
读写权限严格区分，生产环境默认只读
绝大多数误操作来自意外推送或覆盖。建议默认策略：
- 所有 -prod 项目：禁止普通用户 push，仅允许 CI 系统通过专用 token 推送已签名镜像
- 所有 -dev 项目：允许对应开发组 push/pull，但禁止删除历史标签（防覆盖）
- 测试组统一使用只读权限，避免本地构建污染测试镜像源
Harbor 和 Artifactory 都支持基于项目前缀+动作的细粒度策略，不需要为每个项目重复设置。
定期清理无效权限，不是设完就完事
权限会随人员流动、项目结束而过期。建议每季度执行一次检查：
- 列出所有空权限组（无成员）并归档
- 扫描长期未登录的账号，暂停其所属组权限
- 核对项目活跃度，停用半年无 push/pull 记录的 -test 类项目
不清理的权限组，迟早变成安全隐患的温床。
