1. RBAC 基础概念
1.1 RBAC 模型定义
基于角色的访问控制（Role-Based Access Control，RBAC）是一种将权限授予角色，再将角色授予用户的授权管理模型。其核心思想是：用户不直接拥有权限，而是通过角色间接获得权限。这种解耦设计大幅降低了大规模系统中的权限管理复杂度。
关键特征：RBAC 是策略中立的访问控制模型，支持最小权限原则、职责分离和权限抽象，被 NIST（美国国家标准与技术研究院）标准 RBAC 所采纳。
1.2 核心三要素
RBAC 模型由三个基本元素构成，它们之间的关系决定了整个授权体系的运作方式：
| 要素 | 定义 | 示例 |
|---|---|---|
| 用户（User） | 访问系统资源的实体，可以是人、服务账号或设备 | 张三、CI/CD 机器人、监控代理 |
| 角色（Role） | 权限的逻辑集合，代表一类职责或岗位 | 运维工程师、审计员、发布管理员 |
| 权限（Permission） | 对特定资源执行特定操作的许可 | 读取 /etc/config、执行 deploy.sh |
三要素之间的映射关系遵循以下规则：
- 用户-角色关联：一个用户可以拥有多个角色，一个角色也可以被多个用户持有。
- 角色-权限关联：一个角色可以包含多个权限，一个权限也可以被多个角色引用。
- 用户-权限间接关联：用户通过其被授予的角色，继承该角色下的所有权限。
实践要点：在发布包校验场景中，通常定义
release-manager、release-verifier、release-viewer 三个角色，分别对应发布、校验和只读查看权限，避免直接给用户绑定细粒度操作。
1.3 RBAC 与 ACL 的区别
访问控制列表（Access Control List，ACL）是另一种常见的授权机制，与 RBAC 在管理理念和适用场景上存在显著差异。下表从多个维度进行对比：
| 对比维度 | RBAC（基于角色） | ACL（基于列表） |
|---|---|---|
| 授权粒度 | 粗粒度到中粒度，按角色聚合 | 细粒度，每个资源独立配置 |
| 管理复杂度 | 低，角色数量远少于用户数 | 高，用户-资源条目呈指数增长 |
| 扩展性 | 优秀，新增用户只需分配角色 | 较差，新增用户需逐资源配置 |
| 权限继承 | 支持，角色层级可继承权限 | 不支持，每个条目独立 |
| 典型场景 | 企业应用、云平台、CI/CD 系统 | 文件系统、网络设备 ACL |
| 发布包校验适用性 | 推荐：角色清晰，审计方便 | 不推荐：条目爆炸，难以审计 |
常见误区：不要将 RBAC 与 ACL 对立使用。在实际系统中，RBAC 负责高层级授权决策，ACL 可用于底层资源级细粒度控制。例如：RBAC 决定用户能否访问发布仓库，ACL 控制该用户对仓库内某个具体文件的读写权限。
1.4 为什么发布包校验选择 RBAC
在发布包校验场景中，RBAC 相比 ACL 具有以下优势：
- 审计友好：角色变更记录清晰，便于合规审计。
- 职责分离：可定义互斥角色（如发布者与校验者不能为同一人）。
- 批量管理：人员流动时只需调整角色分配，无需修改每个包的权限列表。
- 最小权限：角色权限按需设计，避免过度授权。