2. K8s RBAC 基础：Role、ClusterRole、RoleBinding、ClusterRoleBinding 核心对象

Kubernetes RBAC（基于角色的访问控制）是平台安全的第一道防线。在集群生命周期运维中，无论是发布包校验、节点扩缩容还是审计追溯，都依赖 RBAC 精确控制“谁（主体）能对哪些资源（对象）执行什么操作（动词）”。本章深入拆解四个核心 API 对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding。

2.1 核心概念与层级关系

RBAC 模型围绕三个要素构建：

  • 主体（Subject）：User、Group、ServiceAccount。
  • 资源（Resource）：Pod、Service、Deployment、Node 等 API 对象。
  • 动词（Verb）：get、list、watch、create、update、patch、delete。

Role 与 ClusterRole 定义“权限集合”，RoleBinding 与 ClusterRoleBinding 将权限集合绑定到主体。区别在于作用域：

对象 作用域 适用场景
Role 单个 Namespace 应用级权限隔离，如只允许某 SA 操作 default 命名空间的 Pod
ClusterRole 集群全局（所有 Namespace + 非资源端点） 集群管理员权限、PV/Node 操作、查看所有 Namespace 资源
RoleBinding 绑定 Role 到主体，作用域与 Role 一致 将某 Role 授予某 Namespace 内的 ServiceAccount
ClusterRoleBinding 绑定 ClusterRole 到主体，作用域全局 将 cluster-admin 权限授予某用户
关键原则：RoleBinding 可以引用 ClusterRole，但权限范围会被限制在 RoleBinding 所在的 Namespace 内。这是实现“全局角色，局部授权”的常用模式。

2.2 对象定义与字段解析

2.2.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"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list"]

2.2.2 ClusterRole 示例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-admin
rules:
- apiGroups: [""]
  resources: ["nodes", "nodes/status"]
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: [""]
  resources: ["persistentvolumes"]
  verbs: ["*"]

2.2.3 RoleBinding 示例

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: production
  name: read-pods-binding
subjects:
- kind: ServiceAccount
  name: ci-bot
  namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

2.2.4 ClusterRoleBinding 示例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-binding
subjects:
- kind: User
  name: ops-admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
⚠️ 常见错误：RoleBinding 的 roleRef 一旦创建即不可变更 kind 和 name。如需修改，必须删除重建。这是 Kubernetes 的安全设计，防止权限被意外篡改。

2.3 权限聚合与资源子路径

ClusterRole 支持通过 aggregationRule 自动聚合多个 ClusterRole 的规则，常用于 Operator 或自定义控制器动态扩展权限。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregate-view
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-view: "true"
rules: []  # 规则由匹配的 ClusterRole 自动合并

资源子路径（Subresource）通过 resources 字段的 / 分隔符指定，例如 pods/log、pods/exec、nodes/proxy。运维发布包校验中，常需要限制 pods/log 的读取权限，避免敏感日志泄露。

2.4 四类对象关系图

下图展示 Role / ClusterRole 与 RoleBinding / ClusterRoleBinding 的绑定关系及作用域边界：

RBAC 四类对象关系与作用域 Role 作用域：单个 Namespace 例：production/pod-reader ClusterRole 作用域：集群全局 例：node-admin RoleBinding 绑定到 Namespace 内主体 例：read-pods-binding ClusterRoleBinding 绑定到全局主体 例：admin-binding 引用（同 Namespace） 引用（权限限制到 Namespace） 引用（全局生效） 核心规则 RoleBinding 只能引用同 Namespace 的 Role，但可以引用 ClusterRole（权限降级到 Namespace） ClusterRoleBinding 只能引用 ClusterRole，不能引用 Role

2.5 常用 Verb 与资源组合速查

运维发布包校验场景中，最常校验的权限组合如下：

场景 API 组 资源 常用 Verb
查看 Pod 状态 "" pods get, list, watch
读取 Pod 日志 "" pods/log get
操作 Deployment apps deployments get, list, create, update, patch, delete
查看集群节点 "" nodes get, list, watch
管理 PV/PVC "" persistentvolumes, persistentvolumeclaims get, list, create, delete
查看事件 "" events get, list, watch
访问非资源端点 "" 非资源 URL（如 /healthz） get

2.6 发布包校验中的 RBAC 检查点

在集群生命周期运维发布包校验流程中，RBAC 配置的正确性直接影响发布成败。以下为关键检查项：

  1. ServiceAccount 是否存在：发布包中引用的 SA 必须在目标 Namespace 内已创建。
  2. Role/ClusterRole 规则是否覆盖所需操作：例如，CI/CD 系统需要 create 和 update Deployment，但只授予了 get 权限。
  3. RoleBinding 的 roleRef 是否指向正确的 Role：避免因名称拼写错误导致绑定失效。
  4. ClusterRoleBinding 是否误绑到 Namespace 级主体：全局权限应谨慎授予。
  5. 聚合规则是否生效：使用 aggregationRule 时，需确认标签选择器匹配了预期的 ClusterRole。
校验命令速记：
kubectl auth can-i --list --as=system:serviceaccount:ns:sa-name 可快速验证某 SA 的实际权限。
kubectl describe rolebinding <name> -n <ns> 查看绑定详情。
kubectl describe clusterrolebinding <name> 查看全局绑定详情。

2.7 最佳实践与避坑指南

  • 最小权限原则：只授予发布包运行所需的最小 Verb 集合，避免使用 ["*"]。
  • 优先使用 Role + RoleBinding：除非确实需要跨 Namespace 或操作集群级别资源，否则不要使用 ClusterRoleBinding。
  • 避免直接绑定 User：生产环境推荐使用 ServiceAccount 作为主体，便于轮换和审计。
  • 定期审计绑定：使用 kubectl get rolebindings --all-namespaces 和 kubectl get clusterrolebindings 检查是否存在冗余或过度授权的绑定。
  • 资源子路径单独授权：例如，授予 pods/exec 权限应单独评估，避免通过 pods 的 * 权限意外开放。
← 上一章 📖 返回目录 下一章 →