3. Role与ClusterRole：作用域与创建管理

在 Kubernetes RBAC 体系中，Role 和 ClusterRole 是定义权限集合的核心资源对象。两者的本质区别在于作用域：Role 作用于特定的命名空间（Namespace），而 ClusterRole 作用于整个集群。理解这一差异是正确设计权限模型的前提。

3.1 作用域对比：Namespace 级别 vs 集群级别

对比维度 Role（命名空间级别） ClusterRole（集群级别）
作用范围 仅限单个 Namespace 整个集群（所有 Namespace）
可授权资源 Namespace 内的资源（Pod、Service、Deployment 等） 集群级资源（Node、PV、Namespace、ClusterRole 等） + 所有 Namespace 资源
非资源型 URL 不支持 支持（如 /healthz、/api 等）
典型用途 应用团队权限隔离、微服务环境 集群管理员、监控组件、跨 Namespace 访问
绑定方式 RoleBinding（同 Namespace） ClusterRoleBinding（集群范围）或 RoleBinding（降级到 Namespace）
关键理解：ClusterRole 可以通过 RoleBinding 绑定到特定 Namespace，此时其权限被“降级”为仅在该 Namespace 内生效。这一机制使得 ClusterRole 成为可复用的权限模板。

3.2 作用域可视化：Role 与 ClusterRole 的边界

下图展示了 Role 和 ClusterRole 在集群中的不同作用范围，以及它们与 RoleBinding、ClusterRoleBinding 的绑定关系。

Role 与 ClusterRole 作用域对比 Kubernetes 集群 Namespace: production Namespace: staging Role: pod-reader 作用域：仅 production 资源：Pod（get, list, watch） RoleBinding: pod-reader-binding 绑定用户：dev-user ClusterRole: node-viewer 作用域：整个集群 资源：Node（get, list） ClusterRoleBinding: node-viewer-binding 绑定用户：cluster-admin ClusterRole: pv-admin 作用域：集群（PV 管理） 通过 RoleBinding 降级到 staging RoleBinding: pv-admin-binding 绑定 ClusterRole 到 staging 命名空间 Role（Namespace 级别） ClusterRole（集群级别） ClusterRole 降级使用 ClusterRoleBinding

3.3 创建与管理方法

3.3.1 使用 kubectl 命令创建

创建 Role（命名空间级别）：

# 在 production 命名空间创建 Role，允许读取 Pod
kubectl create role pod-reader \
  --namespace=production \
  --verb=get,list,watch \
  --resource=pods

# 创建 Role 并指定多个资源
kubectl create role service-admin \
  --namespace=production \
  --verb=create,delete,update \
  --resource=services,endpoints

创建 ClusterRole（集群级别）：

# 创建 ClusterRole，允许读取集群节点
kubectl create clusterrole node-viewer \
  --verb=get,list \
  --resource=nodes

# 创建 ClusterRole，允许管理 PV 和 StorageClass
kubectl create clusterrole storage-admin \
  --verb=* \
  --resource=persistentvolumes,storageclasses

3.3.2 使用 YAML 清单创建

Role YAML 示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list"]

ClusterRole YAML 示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list"]
- nonResourceURLs: ["/healthz", "/version"]
  verbs: ["get"]
关键字段说明：
  • apiGroups：API 组，空字符串 "" 表示核心 API 组（如 Pod、Service）。
  • resources：资源类型，支持通配符 "*" 表示所有资源。
  • verbs：操作动词，包括 get、list、watch、create、update、patch、delete、deletecollection。
  • resourceNames：可选字段，限制到特定资源实例。
  • nonResourceURLs：仅 ClusterRole 支持，用于非资源型端点。

3.3.3 管理操作清单

操作 命令示例 说明
查看 Role kubectl get roles -n production 列出指定 Namespace 的 Role
查看 ClusterRole kubectl get clusterroles 列出所有 ClusterRole
查看详情 kubectl describe role pod-reader -n production 查看 Role 的详细规则
编辑 Role kubectl edit role pod-reader -n production 在线编辑 YAML
删除 Role kubectl delete role pod-reader -n production 删除后关联的 RoleBinding 失效
导出 YAML kubectl get role pod-reader -n production -o yaml 导出为 YAML 格式

3.4 最佳实践与避坑指南

常见错误：
  • 作用域混淆：在 ClusterRole 中定义 Namespace 级别资源（如 Pod），却使用 ClusterRoleBinding 绑定，导致权限扩散到所有 Namespace。
  • 权限过度：使用 verbs: ["*"] 或 resources: ["*"] 时未仔细评估影响范围。
  • 遗漏 apiGroups：对于 Deployment、StatefulSet 等资源，必须指定 apiGroups: ["apps"]，否则规则不生效。
推荐策略：
  1. 最小权限原则：始终从最具体的 verb 和 resource 开始，按需扩展。
  2. 复用 ClusterRole：将通用权限（如只读访问）定义为 ClusterRole，通过 RoleBinding 降级到各 Namespace。
  3. 命名规范：Role 名称使用 <资源>-<操作> 格式（如 pod-reader），ClusterRole 使用 <范围>-<资源>-<操作> 格式（如 cluster-node-viewer）。
  4. 定期审计：使用 kubectl describe clusterrolebinding 和 kubectl describe rolebinding 检查绑定关系。

3.5 创建与绑定流程

下图展示了从创建 Role/ClusterRole 到完成绑定的完整工作流，以及不同绑定方式对应的权限范围。

Role/ClusterRole 创建与绑定流程 步骤 1：定义权限 编写 YAML 或使用命令 指定 apiGroups/resources/verbs 步骤 2：选择作用域 Role → 指定 Namespace ClusterRole → 集群范围 步骤 3：创建资源 kubectl apply -f 或 kubectl create 选择绑定方式（决定最终权限范围） 选项 A：RoleBinding 绑定 Role 或 ClusterRole 权限限制在单个 Namespace 选项 B：ClusterRoleBinding 仅绑定 ClusterRole 权限覆盖整个集群 最终效果 RoleBinding + Role → Namespace 级别权限 | RoleBinding + ClusterRole → 降级为 Namespace 级别权限 | ClusterRoleBinding + ClusterRole → 集群级别权限

3.6 实战案例：多环境权限隔离

假设一个团队管理三个环境：dev、staging、production。要求：

  • 开发人员：在 dev 命名空间拥有 Pod 和 Deployment 的完整操作权限。
  • 测试人员：在 staging 命名空间拥有只读权限。
  • 运维人员：在 production 命名空间拥有 Pod 和 Service 的管理权限。

推荐方案：

# 1. 创建 ClusterRole 作为权限模板
kubectl create clusterrole dev-full-access \
  --verb=* \
  --resource=pods,deployments

kubectl create clusterrole readonly-access \
  --verb=get,list,watch \
  --resource=pods,services,deployments

kubectl create clusterrole ops-manage \
  --verb=create,delete,update,patch \
  --resource=pods,services

# 2. 通过 RoleBinding 降级到对应 Namespace
kubectl create rolebinding dev-binding \
  --namespace=dev \
  --clusterrole=dev-full-access \
  --user=dev-user

kubectl create rolebinding staging-binding \
  --namespace=staging \
  --clusterrole=readonly-access \
  --user=test-user

kubectl create rolebinding prod-binding \
  --namespace=production \
  --clusterrole=ops-manage \
  --user=ops-user
方案优势：
  • 模板复用：ClusterRole 定义一次，通过 RoleBinding 在不同 Namespace 复用。
  • 权限隔离：每个 Namespace 的权限独立管理，互不干扰。
  • 审计清晰：通过 kubectl describe rolebinding -n <namespace> 可快速查看每个 Namespace 的绑定关系。
← 上一章 📖 返回目录 下一章 →