1. RBAC 基础概念
1.1 RBAC 模型定义
基于角色的访问控制（RBAC，Role-Based Access Control）是一种将权限授予角色、再将角色授予用户的访问控制模型。其核心思想是：权限不直接关联用户，而是通过“角色”作为中间层实现逻辑解耦。RBAC 在 1992 年由 David Ferraiolo 和 Richard Kuhn 正式提出，随后被 NIST 标准化为 INCITS 359-2012。
核心原则：用户 → 角色 → 权限，三者形成“用户-角色-权限”的间接映射关系。
1.2 核心要素
| 要素 | 定义 | 示例 |
|---|---|---|
| 用户（User） | 访问系统的主体，可以是人、服务账号或自动化进程 | zhangsan@company.com、ci-bot |
| 角色（Role） | 权限的逻辑集合，代表一类职责或岗位 | devops-engineer、readonly-viewer |
| 权限（Permission） | 对某个资源执行特定操作的许可 | ec2:DescribeInstances、s3:PutObject |
| 会话（Session） | 用户激活角色后的临时上下文 | 用户登录后激活 admin 角色 |
关键区别：在 RBAC 中，权限变更只需修改角色定义，所有被授予该角色的用户自动继承变更，无需逐个调整用户。
1.3 RBAC 与 ACL 的区别
ACL（访问控制列表）将权限直接绑定到用户或用户组，而 RBAC 通过角色层实现间接授权。下表从多个维度对比两者差异：
| 对比维度 | RBAC | ACL |
|---|---|---|
| 授权粒度 | 粗粒度到中粒度（角色级） | 细粒度（对象级） |
| 管理复杂度 | 低（角色数量远少于用户数） | 高（每个对象维护独立列表） |
| 扩展性 | 优秀（新增用户只需分配角色） | 较差（用户数增长时 ACL 条目爆炸） |
| 典型场景 | 企业应用、云平台 IAM、Kubernetes RBAC | 文件系统权限、网络设备 ACL |
| 权限继承 | 支持（角色层级继承） | 不支持（扁平结构） |
| 审计难度 | 低（通过角色追溯权限来源） | 高（需要遍历所有 ACL 条目） |
常见误区：ACL 中的“用户组”并非角色。用户组只是用户的集合，不携带权限语义；而角色是权限的集合，具有明确的业务含义。
1.4 RBAC 模型结构图
下图展示了 RBAC 的核心关系：用户通过角色获得权限，权限由操作和资源组合定义。
1.5 RBAC 与 ACL 的架构对比图
下图从系统架构角度对比 RBAC 和 ACL 的授权路径差异：
1.6 实际应用中的 RBAC 层级
NIST RBAC 标准定义了四个层级，从基础到高级逐步增强：
- Flat RBAC（平坦 RBAC）：用户-角色-权限的基本映射，无角色继承。
- Hierarchical RBAC（层级 RBAC）：支持角色继承，子角色自动获得父角色的权限。
- Constrained RBAC（约束 RBAC）：引入职责分离（SoD）约束，防止权限冲突。
- Symmetric RBAC（对称 RBAC）：支持角色间的双向关系，如角色互斥。
SRE 视角：在云原生环境中，Kubernetes RBAC 属于 Hierarchical RBAC 的变体，通过 ClusterRole 和 RoleBinding 实现跨命名空间的权限继承。审计时需重点关注 ClusterRole 的聚合规则，避免权限扩散。