1. RBAC 概述与基本概念
说起权限控制，我猜你肯定遇到过这样的场景：公司内部系统，每个人都有不同的操作范围。新员工入职，管理员一个个去配权限；老员工调岗，权限又得重新改。时间一长，权限管理变成了噩梦。这正是 RBAC 要解决的核心问题。
RBAC 的起源
RBAC 的全称是 Role-Based Access Control，也就是基于角色的访问控制。九十年代初，它被提出就是为了统一解决企业级权限管理的混乱局面。那时候还没什么云原生，大家用的还是大型机上的应用。我最早接触 RBAC 是在 2010 年做一个银行内部系统，说实话，当时觉得不就是“角色+权限”嘛，能有多复杂？后来真正做起来才发现——角色设计不对，后面全盘皆输。
说白了，RBAC 的核心思想很简单：不直接把权限分配给用户，而是通过“角色”这个中间层。用户先归属于某个角色，角色再去拥有权限。这样权限管理就变得灵活多了。
核心三要素：角色、权限、用户
我们把这三样东西拆开来看：
- 用户（User）：系统里的操作主体，比如张三、李四。用户是人，也可能是服务账号。
- 角色（Role）：一种职责或岗位的抽象，比如“项目经理”、“系统管理员”、“普通员工”。角色是权限的集合。
- 权限（Permission）：对某个资源执行某个操作的许可，比如“读取项目文档”、“创建用户”、“删除集群节点”。
它们的关系如图：
用户-角色-权限的关系
这种三层结构带来一个明显的好处：解耦。举个例子，你想想看，如果公司有 100 个员工，每个员工都需要访问同一个报表系统。没有角色的话，你得给 100 个人每个都配一遍报表权限。有了角色，只要把 100 个人都加到“报表查看者”这个角色里，然后给角色配一次读权限就行了。
我还遇到过一种情况：同一个用户同时拥有多个角色。比如一个人既是“开发工程师”又是“项目管理员”。RBAC 支持这种“多角色”模式，权限取所有角色权限的并集。嗯，这里要注意——权限的并集可能导致权限膨胀，所以需要在设计角色时遵循“最小权限原则”。
RBAC 的应用场景
RBAC 几乎无处不在。从企业内部的人力资源系统、ERP，到云平台的 IAM（比如 AWS IAM、阿里云 RAM），再到 Kubernetes 的 RBAC，都是这套思路。我个人习惯把场景分为三类：
| 场景 | 典型系统 | 角色举例 |
|---|---|---|
| 企业后台管理 | OA、CRM、ERP | HR专员、财务经理、普通员工 |
| 云平台权限 | AWS IAM、阿里云 RAM | 管理员、开发者、审计员 |
| 容器编排 | Kubernetes RBAC | ClusterAdmin、View、Edit |
还有一些特殊场景，比如密钥管理。密钥的访问控制如果不用 RBAC，很容易出现某个运维人员能直接拿到所有密钥的情况。这也是我们后面章节要重点审计的内容。
一个小对比：DAC、MAC、RBAC、ABAC
为了让你更清楚 RBAC 的定位，我画了个对比表：
| 模型 | 核心思想 | 适用场景 | 管理复杂度 |
|---|---|---|---|
| DAC（自主访问控制） | 资源所有者自己决定谁可以访问 | 个人文件共享 | 低 |
| MAC（强制访问控制） | 系统根据安全标签强制控制 | 军事、政府高安全系统 | 高 |
| RBAC | 通过角色关联用户和权限 | 企业通用，大多数商业应用 | 中 |
| ABAC（基于属性访问控制） | 根据用户、资源、环境属性动态决策 | 微服务、物联网、动态策略 | 较高 |
RBAC 在“灵活性”和“管理成本”之间取得了很好的平衡，所以它成了目前应用最广泛的模型。后面我们在做密钥权限边界审计时，主要就是基于 RBAC 来分析角色设计有没有越权、权限分配是否合理。
好了，这一章我们先把 RBAC 的骨架搭起来。你记住这三者之间的“用户→角色→权限”链条，后面所有的审计规则、边界分析、密钥管控都会围绕这个链条展开。为什么这么说？因为一旦链条中的某个环节设计不当，权限边界就会被突破。