harbor权限管理基于“项目+角色+实体”三级联动，以最小授权为原则：项目是唯一逻辑容器，权限仅限项目级；内置角色权限固定不可修改；机器人账户是自动化操作唯一安全出口；admin权限须严格管控。
Harbor的权限管理核心在于“项目+角色+实体”三级联动，不是靠给用户堆权限，而是靠划分边界、绑定动作、最小授权来落地。关键不在功能多，而在结构清、边界明、可审计。
项目是权限的唯一逻辑容器
所有镜像和Chart必须归属某个项目，权限只能在项目层级配置，无法细化到仓库名或镜像标签。这意味着设计之初就要按团队、环境或用途拆分项目，比如：
- dev-apps：开发团队日常构建推送，仅开放给开发者角色
- prod-base：生产用基础镜像（如nginx:alpine、redis:7），设为公开只读，供所有环境拉取
- infra-charts：运维使用的Helm Chart项目，仅限维护者角色操作
切忌把所有镜像塞进一个项目再试图用命名规则区分——Harbor不识别镜像名语义，也不支持通配符权限。
内置角色决定能做什么，不能越界
Harbor预置5个角色，权限固定不可修改。最常用的是：
- 访客（Guest）：仅能拉取镜像、查看扫描报告，适合测试人员
- 开发者（Developer）：可推/拉/列出镜像，但不能删除，适合CI流水线机器人账户
- 维护者（Maintainer）：在开发者基础上增加删除权限，适合运维脚本或清理任务
- 项目管理员（Project Admin）：可管理成员、策略、机器人账户，但不能跨项目操作
注意：没有“只读管理员”这类混合角色。若需限制某人只能看不能动，就选访客；若需其能推但不能删，就选开发者。
机器人账户是自动化权限的唯一安全出口
CI/CD、定时脚本、同步工具必须用机器人账户，绝不用真实员工账号。创建时牢记三点：
- 名称带业务标识，例如robot-ci-prod-deploy，便于后期审计和回收
- 权限只勾选实际需要的动作：推送镜像选“push”，漏洞扫描结果只读选“read scan”，不需要就别勾
- 令牌（token）生成后立即复制保存，页面关闭即不可再查，丢失只能重置
一个典型场景：Jenkins向prod-apps项目推送镜像。应创建机器人账户，绑定该项目，角色选“开发者”，不勾选“delete”。这样即使Jenkins配置泄露，攻击者也无法删掉历史镜像。
系统管理员权限要收得紧、用得少
admin账户拥有全局项目管理、用户管理、系统配置等能力，不应作为日常操作账号。建议：
- 禁用admin密码登录Web界面，改用LDAP或OIDC统一身份源
- 所有日常操作（如加成员、调策略）都通过项目管理员账号完成
- 审计日志中重点监控admin用户的操作记录，设置告警阈值
权限不是越多越好，而是刚好够用、留痕可溯、失效可控。
