1.1 RBAC 模型定义与核心概念
基于角色的访问控制（RBAC, Role-Based Access Control）是 Kubernetes 默认且最广泛使用的授权模式。其核心思想是：权限不直接授予用户，而是通过“角色”作为中间层进行间接授权。这种设计大幅降低了大规模集群中权限管理的复杂度。
RBAC 黄金法则： 用户 → 角色（权限集合） → 资源。用户只与角色关联，角色定义对资源的操作权限。
1.1.1 RBAC 模型四要素
根据 NIST RBAC 标准模型，RBAC 包含以下四个核心元素：
| 元素 | Kubernetes 对应对象 | 说明 |
|---|---|---|
| 用户（User） | User / ServiceAccount / Group | 发起 API 请求的实体，可以是自然人、应用 Pod 或外部系统 |
| 角色（Role） | Role / ClusterRole | 一组权限规则的集合，定义对哪些资源能执行哪些操作 |
| 权限（Permission） | rules 中的 verbs + resources | 具体允许的操作（get/list/watch/create/update/delete）与目标资源 |
| 会话/绑定（Session/Binding） | RoleBinding / ClusterRoleBinding | 将用户与角色关联起来的绑定关系，决定用户在哪些命名空间生效 |
关键区分： Kubernetes 中的“会话”概念对应的是
RoleBinding 和 ClusterRoleBinding。一个用户可以有多个绑定，一个角色也可以被多个用户绑定，形成多对多关系。
1.1.2 RBAC 与传统 ACL 的对比
传统访问控制列表（ACL, Access Control List）直接将权限绑定到用户，而 RBAC 通过角色解耦。以下对比能清晰看出两者的本质差异：
| 对比维度 | 传统 ACL | RBAC |
|---|---|---|
| 授权粒度 | 用户 → 权限（直接绑定） | 用户 → 角色 → 权限（间接绑定） |
| 管理复杂度 | O(n×m)，n 个用户 × m 个资源 | O(n + r + b)，用户数 + 角色数 + 绑定数 |
| 权限变更 | 需逐个修改每个用户的 ACL 条目 | 只需修改角色定义，所有绑定用户自动生效 |
| 最小权限原则 | 难以统一实施，容易权限泛滥 | 天然支持，通过角色粒度精确控制 |
| 审计与合规 | 审计日志分散，难以追溯 | 角色作为审计单元，权限变更可追溯 |
| Kubernetes 支持 | 不适用（K8s 未采用 ACL 模式） | 原生支持，是默认授权模式 |
常见误区： 不要将 Kubernetes 的 RBAC 与 AWS IAM 或 Linux 文件权限的 ACL 混淆。K8s RBAC 不管理操作系统级权限，只控制对 Kubernetes API 资源的访问。
1.1.3 RBAC 在 Kubernetes 中的实现层次
Kubernetes RBAC 分为两个作用域：
- 命名空间级别（Role + RoleBinding）： 权限仅作用于特定命名空间内的资源（如 Pod、Service、Deployment）。
- 集群级别（ClusterRole + ClusterRoleBinding）： 权限作用于整个集群，包括节点、PV、Namespace 等集群范围资源，也可跨命名空间授权。
1.1.4 最小权限原则与 RBAC 设计
在 Kubernetes 生产环境中，RBAC 策略设计必须遵循最小权限原则（Least Privilege Principle）：
- 按需授权： 只授予完成工作所必需的最小权限集合。
- 角色细分： 将角色拆分为只读、运维、管理员等不同等级。
- 避免通配符滥用： 谨慎使用
*通配符，明确列出 verbs 和 resources。 - 定期审计： 使用
kubectl auth can-i --list检查用户权限。
生产建议： 默认拒绝所有权限，然后通过 RBAC 规则逐步开放。使用
ClusterRole 定义通用权限模板，通过 RoleBinding 在命名空间级别精细化控制。