1. RBAC 基础概念
1.1 什么是 RBAC？
RBAC（Role-Based Access Control，基于角色的访问控制）是一种将权限授予角色，再将角色授予用户的授权模型。在 Kubernetes 控制平面中，RBAC 是默认且最广泛使用的鉴权机制，它通过解耦用户与权限的直接绑定，实现可审计、可继承、最小权限的访问管理。
核心原则：权限不直接赋予用户，而是赋予角色；用户通过成为角色的成员获得相应权限。这种间接层使得权限变更只需修改角色定义，无需逐个调整用户。
1.2 核心三要素
RBAC 模型围绕三个基本元素构建，它们之间的关系决定了整个授权体系的灵活性：
| 要素 | Kubernetes 对应资源 | 说明 |
|---|---|---|
| 用户（User） | User / ServiceAccount / Group | 发起 API 请求的实体，可以是自然人、应用 Pod 或外部系统 |
| 角色（Role） | Role / ClusterRole | 一组权限规则的集合，定义对哪些资源（如 pods、secrets）能执行哪些操作（get、list、create） |
| 权限（Permission） | verbs + resources + apiGroups | 具体的操作许可，由 API 组、资源类型和动作动词三元组精确描述 |
三要素的绑定通过 RoleBinding 或 ClusterRoleBinding 完成，将角色与用户（或用户组）关联起来，从而授予权限。
关键区别：Kubernetes 中的 User 并非由 API 对象创建，而是由证书中的 CN 字段或外部身份提供者（如 OIDC）定义；ServiceAccount 则是命名空间内的 API 对象，用于为 Pod 提供身份。
1.3 RBAC 与 ABAC / DAC 的对比
在云原生安全体系中，理解 RBAC 与其他访问控制模型的差异至关重要。下表从多个维度进行对比：
| 维度 | RBAC（基于角色） | ABAC（基于属性） | DAC（自主访问控制） |
|---|---|---|---|
| 授权依据 | 用户所属的角色 | 用户、资源、环境的多维属性 | 资源所有者的主观判断 |
| 管理粒度 | 粗到中（角色级） | 细（属性级） | 粗（所有者级） |
| 可审计性 | 高（角色定义清晰） | 中（规则复杂时审计困难） | 低（权限分散在所有者手中） |
| Kubernetes 支持 | ✅ 默认启用，推荐使用 | ❌ 已弃用（v1.22+ 移除） | ❌ 不支持 |
| 变更影响 | 修改角色定义影响所有关联用户 | 修改属性规则影响所有匹配请求 | 需逐个修改资源 ACL |
| 适用场景 | 团队职责清晰、权限分级明确 | 动态环境、基于上下文（如时间、IP）的访问 | 小型系统、文件共享 |
安全提示：Kubernetes 社区已正式弃用 ABAC 模式，所有新集群应使用 RBAC。ABAC 的策略文件为 JSON 格式，缺乏类型安全且难以审计，在控制平面基线核验中属于必须整改项。
1.4 RBAC 授权流程（SVG 图）
下图展示了 Kubernetes API 请求经过 RBAC 鉴权的完整路径：
1.5 RBAC 与 ABAC 策略示例对比（SVG 图）
通过具体策略定义的对比，可以直观理解两种模型的差异：
1.6 为什么云原生环境首选 RBAC？
- 最小权限原则：通过角色定义精确控制每个用户或 ServiceAccount 能访问的资源与操作，避免过度授权。
- 职责分离：将集群管理、命名空间管理、只读审计等职责拆分为不同角色，降低误操作风险。
- 审计合规：所有 RoleBinding 和 ClusterRoleBinding 都是 Kubernetes API 对象，可被审计工具扫描和版本化。
- 可扩展性：支持聚合 ClusterRole，可将多个基础角色组合为更复杂的权限集，适应微服务架构的动态需求。
基线核验要点：在云原生运行基线审计中，RBAC 配置是必检项。重点检查：是否存在绑定到 cluster-admin 的普通用户、ServiceAccount 是否被授予了不必要的集群级别权限、Role 中是否使用了通配符（*）导致权限范围过大。