3. 核心RBAC对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding的定义与关系
Kubernetes RBAC 的权限模型由四个核心 API 对象构成，它们两两配对，分别解决“授予什么权限”和“授予给谁”的问题。理解这四个对象的定义及其关系，是掌握 RBAC 配置的基础。
3.1 对象定义与职责
| 对象名称 | 作用域 | 核心职责 | 典型用途 |
|---|---|---|---|
| Role | 命名空间（Namespace） | 定义一组权限规则，指定可以对哪些资源（如 Pod、Service）执行哪些操作（如 get、list、create） | 授予某个命名空间内的应用或用户特定操作权限 |
| ClusterRole | 集群（Cluster） | 定义一组权限规则，作用范围可以是整个集群、所有命名空间，或非命名空间资源（如 Node、PersistentVolume） | 授予集群管理员权限、查看所有命名空间 Pod 的权限 |
| RoleBinding | 命名空间（Namespace） | 将 Role 或 ClusterRole 绑定到一个或多个主体（User、Group、ServiceAccount），且绑定仅在当前命名空间生效 | 将某个命名空间的 Role 授予给该命名空间内的 ServiceAccount |
| ClusterRoleBinding | 集群（Cluster） | 将 ClusterRole 绑定到一个或多个主体，绑定在整个集群范围内生效 | 将集群管理员权限授予给某个用户或 ServiceAccount |
关键区分：Role 和 RoleBinding 是命名空间级别的，ClusterRole 和 ClusterRoleBinding 是集群级别的。一个 ClusterRole 可以被 RoleBinding 引用，从而实现跨命名空间的权限复用，但绑定效果仍局限于该 RoleBinding 所在的命名空间。
3.2 对象关系与绑定逻辑
四个对象通过“绑定”操作形成权限链路。下图展示了 Role 与 ClusterRole 如何通过不同的 Binding 对象作用于主体。
3.3 权限聚合与生效规则
当一个主体（如 ServiceAccount）被多个 RoleBinding 或 ClusterRoleBinding 绑定时，其最终权限是所有绑定权限的并集。Kubernetes RBAC 遵循“默认拒绝，显式允许”的原则，不存在“否定权限”的概念。
权限聚合规则：
- 同一命名空间内多个 RoleBinding 授予的权限自动合并。
- ClusterRoleBinding 授予的权限与命名空间内的 RoleBinding 权限合并。
- 如果多个 Role 或 ClusterRole 对同一资源定义了不同操作，所有操作均被允许。
- 不存在“优先级”或“覆盖”关系，所有有效绑定都会增加权限。
3.4 典型配置示例
以下示例展示如何创建一个 Role 并将其绑定到 ServiceAccount。
# 1. 创建一个 Role，允许对 Pod 执行 get、list、watch 操作
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
---
# 2. 创建一个 RoleBinding，将 pod-reader Role 绑定到 my-sa ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: default
name: read-pods
subjects:
- kind: ServiceAccount
name: my-sa
namespace: default
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
注意：roleRef 字段一旦创建即不可修改。如果需要更改绑定的 Role，必须删除并重新创建 RoleBinding。这是 Kubernetes 的安全设计，防止权限被意外篡改。
3.5 对象选择决策矩阵
在实际配置中，选择使用哪种对象组合取决于权限的作用范围和复用需求。下表总结了常见场景下的推荐选择。
| 场景 | 权限定义 | 绑定方式 | 说明 |
|---|---|---|---|
| 仅需访问单个命名空间内的资源 | Role | RoleBinding | 最常用组合，权限隔离在命名空间内 |
| 需要访问所有命名空间的同一类资源 | ClusterRole | ClusterRoleBinding | 例如：集群范围的 Pod 查看者 |
| 需要访问非命名空间资源（如 Node） | ClusterRole | ClusterRoleBinding | 非命名空间资源只能由 ClusterRole 授权 |
| 复用同一套权限到多个命名空间 | ClusterRole | RoleBinding（每个命名空间一个） | 避免在每个命名空间重复定义相同的权限规则 |
| 授予集群管理员权限 | ClusterRole（如 cluster-admin） | ClusterRoleBinding | 系统预置的 cluster-admin ClusterRole 拥有最高权限 |
3.6 对象关系总结
四个核心 RBAC 对象构成了一个清晰的权限模型：Role/ClusterRole 定义“能做什么”，RoleBinding/ClusterRoleBinding 定义“谁能做”。通过灵活组合，可以实现从细粒度命名空间隔离到全局集群管理的完整权限控制。