📚 课程目录第3章 RBAC核心对象

3. RBAC核心对象：Role与ClusterRole的定义、区别与适用场景

在Kubernetes基于角色的访问控制（RBAC）体系中，Role和ClusterRole是定义权限集合的两个核心资源对象。它们是权限规则的载体，决定了某个主体（User、Group或ServiceAccount）可以对哪些资源执行哪些操作。理解两者的定义、作用域差异以及适用场景，是进行控制平面权限审计的基础。

3.1 Role：命名空间级别的权限集合

Role 是一组权限规则的集合，其作用域被严格限定在单个命名空间（Namespace）内。一个Role只能授予对其所在命名空间内资源的访问权限，无法跨命名空间生效。

定义方式：通过 rules 字段定义一组操作（verbs）和资源（resources）。
作用范围：仅限创建该Role时指定的命名空间。
典型用途：为某个应用、团队或微服务授予其所在命名空间内的Pod、Service、ConfigMap等资源的操作权限。

  审计要点：在控制平面审计中，应重点检查Role是否遵循了“最小权限原则”。例如，一个仅需读取Pod日志的ServiceAccount，不应被授予包含 delete pods 或 create deployments 权限的Role。

3.2 ClusterRole：集群级别的权限集合

ClusterRole 与Role类似，也是一组权限规则，但其作用域为整个集群。ClusterRole可以授予对集群范围资源（如Node、PersistentVolume、ClusterRole本身）的访问权限，也可以用于授权对所有命名空间中特定资源的访问。

定义方式：与Role相同的 rules 结构，但资源类型可以包含集群范围资源。
作用范围：整个集群，或通过RoleBinding绑定到特定命名空间后，在该命名空间内生效。
典型用途：集群管理员权限、节点监控、跨命名空间的资源查看（如查看所有命名空间的Pod）、以及为聚合API服务器定义权限。

安全风险：ClusterRole的权限范围远大于Role。在审计中，任何绑定到ClusterRole的ClusterRoleBinding都应被视为高敏感对象。特别是那些包含 *（通配符）或 cluster-admin 等内置ClusterRole的绑定，必须严格审查其必要性。

3.3 核心区别对比

下表从多个维度清晰对比了Role与ClusterRole的关键差异，便于在审计过程中快速区分和评估风险。

对比维度	Role	ClusterRole
作用域	单个命名空间	整个集群（所有命名空间）
可授权资源	命名空间内资源（Pod、Service、Deployment等）	集群范围资源（Node、PV、CSIDriver等） + 所有命名空间资源
绑定方式	必须通过RoleBinding绑定	可通过RoleBinding（限定命名空间）或ClusterRoleBinding（全局）绑定
非资源型URL	不支持	支持（如 `/healthz`、`/api`）
审计优先级	中（关注命名空间内权限滥用）	高（关注集群级权限扩散）

3.4 适用场景与选择原则

在实际的集群部署和权限审计中，选择Role还是ClusterRole应遵循以下原则：

优先使用Role：如果权限需求仅局限于一个命名空间，始终优先创建Role。这符合最小权限原则，能有效限制权限爆炸的风险。
谨慎使用ClusterRole：仅在需要访问集群范围资源（如Node、PV）或需要跨命名空间操作（如查看所有命名空间的Deployment状态）时，才考虑使用ClusterRole。
利用ClusterRole复用：对于需要在多个命名空间中授予相同权限的场景（例如，每个命名空间都有一个“只读”角色），可以创建一个ClusterRole，然后在每个命名空间中通过RoleBinding引用它。这既实现了权限复用，又避免了在每个命名空间重复定义。

审计技巧：在审计报告中，建议将ClusterRoleBinding列为最高风险等级。一个常见的误配置是：为了图方便，将ServiceAccount通过ClusterRoleBinding直接绑定到 view 或 edit 等内置ClusterRole，导致该ServiceAccount获得了查看或修改所有命名空间资源的权限，远超其实际需求。

3.5 权限作用域关系图

下面的SVG图直观展示了Role与ClusterRole在集群中的不同作用域，以及它们与RoleBinding、ClusterRoleBinding的绑定关系。

3.6 代码示例：定义Role与ClusterRole

以下YAML清单展示了如何定义一个命名空间级别的Role和一个集群级别的ClusterRole，以及它们对应的绑定方式。

# 示例1: 定义一个命名空间级别的 Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]   # 核心 API 组
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
# 示例2: 定义一个集群级别的 ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
---
# 示例3: 将 Role 绑定到 ServiceAccount (命名空间内)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: ServiceAccount
  name: app-sa
  namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
---
# 示例4: 将 ClusterRole 绑定到 ServiceAccount (跨命名空间)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: view-nodes
  namespace: staging
subjects:
- kind: ServiceAccount
  name: monitor-sa
  namespace: staging
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: rbac.authorization.k8s.io

  审计检查点：在审查上述代码时，审计员应特别关注 roleRef 字段。如果 kind 是 ClusterRole，但 kind 是 RoleBinding，则权限被限制在 RoleBinding 的命名空间内。如果 kind 是 ClusterRoleBinding，则权限作用于整个集群。这是审计中判断权限影响范围的关键逻辑。