1. RBAC 基础回顾：Kubernetes RBAC 核心概念及工作原理
Kubernetes RBAC（基于角色的访问控制）是集群中管理用户、服务账户与资源之间权限关系的标准机制。理解 RBAC 的四个核心原语——Role、ClusterRole、RoleBinding、ClusterRoleBinding——是调试 RBAC Operator 的前提。本节从概念、差异到请求链路，系统梳理这些基础。
1.1 核心概念对比
| 原语 | 作用域 | 绑定目标 | 典型用途 |
|---|---|---|---|
| Role | 单个 Namespace | — | 定义某命名空间内 Pod、Service、Deployment 等资源的读写权限 |
| ClusterRole | 集群全局 | — | 定义集群级别资源（Node、PV、CSR）或跨命名空间资源的权限 |
| RoleBinding | 单个 Namespace | User / Group / ServiceAccount | 将 Role 授予某命名空间内的主体 |
| ClusterRoleBinding | 集群全局 | User / Group / ServiceAccount | 将 ClusterRole 授予集群级别的主体 |
调试提示： 当 RBAC Operator 创建的权限未生效时，首先检查 作用域 是否匹配。例如，在 Namespace
dev 中创建了 RoleBinding，但绑定的 ClusterRole 引用了集群范围的资源（如 Node），则该绑定不会生效——必须使用 ClusterRoleBinding。
1.2 工作原理：请求鉴权链路
当用户或服务账户向 API Server 发起请求时，RBAC 鉴权模块按以下顺序处理：
- 身份认证：API Server 从证书、 或 Basic Auth 中提取请求者身份（User / Group / ServiceAccount）。
- 请求解析：提取请求的 Verb（get、list、create、update、delete）、Resource（pods、deployments）、Subresource（status、log）、Namespace。
- 策略匹配：遍历所有与请求者关联的 RoleBinding / ClusterRoleBinding，收集绑定的 Role / ClusterRole 中的规则（rules）。
- 规则检查：逐条匹配规则中的 apiGroups、resources、verbs、resourceNames。若有一条完全匹配，则允许请求；否则继续检查下一条。
- 最终决策：若所有规则均不匹配，则拒绝请求（Deny）。
关键点： RBAC 是 白名单机制——未显式授予的权限默认被拒绝。调试时，若权限不足，优先检查绑定是否遗漏，而非怀疑规则冲突。
1.3 RBAC 鉴权流程 SVG 图
1.4 规则（Rules）结构详解
每个 Role 或 ClusterRole 包含一组 rules，每条规则由以下字段组成：
- apiGroups：API 组列表，如
[""]（核心组）、["apps"]、["batch"]。使用["*"]匹配所有组。 - resources：资源类型列表，如
["pods"]、["deployments"]、["services"]。 - verbs：操作动词列表，如
["get", "list", "watch", "create", "update", "patch", "delete"]。 - resourceNames（可选）：限定特定资源实例的名称列表。若指定，则仅允许操作这些名称的资源。
常见调试陷阱： 规则中
apiGroups 为空字符串 "" 表示核心 API 组（如 pods、services），而非“所有组”。若误写为 ["*"] 但意图是核心组，可能导致权限范围意外扩大或缩小。调试时务必使用 kubectl auth can-i 验证。
1.5 绑定关系与主体类型
RoleBinding 和 ClusterRoleBinding 通过 subjects 字段指定权限授予对象：
| 主体类型 | kind 值 | name 示例 | 说明 |
|---|---|---|---|
| 用户 | User |
alice |
由外部认证系统（如 OIDC、证书）提供 |
| 组 | Group |
developers |
用于批量授权，减少绑定数量 |
| 服务账户 | ServiceAccount |
my-sa |
Pod 内进程使用的身份，需指定 namespace |
调试技巧： 使用
kubectl describe rolebinding <name> -n <ns> 查看绑定详情，确认 subjects 列表是否包含预期的 ServiceAccount。若绑定正确但权限仍不足，检查 ServiceAccount 是否在正确的 Namespace 中。
1.6 Role 与 ClusterRole 的绑定组合规则
理解以下组合规则有助于快速定位权限问题：
- Role + RoleBinding：权限仅作用于绑定所在的 Namespace。
- ClusterRole + RoleBinding：ClusterRole 的权限被“裁剪”到该 Namespace 内（仅适用于命名空间级资源）。
- ClusterRole + ClusterRoleBinding：权限作用于整个集群，包括所有 Namespace 和集群级资源。
- Role + ClusterRoleBinding：不允许。ClusterRoleBinding 只能绑定 ClusterRole，不能绑定 Role。
1.7 聚合 ClusterRole
Kubernetes 1.9+ 支持通过 aggregationRule 动态组合多个 ClusterRole 的规则。这在 Operator 调试中常见：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: aggregate-admin
aggregationRule:
clusterRoleSelectors:
- matchLabels:
rbac.authorization.k8s.io/aggregate-to-admin: "true"
rules: [] # 规则由匹配的 ClusterRole 自动合并
调试提示： 当 RBAC Operator 使用聚合 ClusterRole 时，若权限缺失，检查被聚合的 ClusterRole 是否带有正确的标签。使用
kubectl get clusterrole --show-labels 快速验证。
1.8 常用调试命令速查
| 命令 | 用途 |
|---|---|
kubectl auth can-i <verb> <resource> --as <user> |
模拟指定用户的操作权限 |
kubectl auth can-i <verb> <resource> --as-system-serviceaccount=<ns>:<sa> |
模拟指定 ServiceAccount 的操作权限 |
kubectl describe role <name> -n <ns> |
查看 Role 的规则详情 |
kubectl describe clusterrole <name> |
查看 ClusterRole 的规则详情 |
kubectl get rolebinding,clusterrolebinding --all-namespaces |
列出所有绑定关系 |
1.9 RBAC 对象关系 SVG 图
1.10 本节小结
RBAC 的核心在于四个原语的正确组合：Role/ClusterRole 定义“能做什么”，RoleBinding/ClusterRoleBinding 定义“谁能做”。调试 RBAC Operator 时，始终从以下三个维度排查：
- 作用域：权限是命名空间级还是集群级？绑定是否匹配？
- 规则精度：apiGroups、resources、verbs 是否覆盖了目标操作？
- 主体身份：请求者是否在绑定的 subjects 列表中？ServiceAccount 的 namespace 是否正确？