📚 课程目录第2章 RBAC基础概念

2. RBAC 基础概念：Role 与 ClusterRole、RoleBinding 与 ClusterRoleBinding、Subjects 类型

Kubernetes 基于角色的访问控制（RBAC）是控制面授权的核心机制。理解 RBAC 的四个基本构件——Role、ClusterRole、RoleBinding、ClusterRoleBinding——以及 Subjects 的类型，是进行策略调优的前提。本节从概念、作用范围到绑定关系，逐一拆解。

2.1 核心概念对比

RBAC 的授权模型可以概括为：谁（Subject）能对哪些资源（Resource）执行什么操作（Verb）。Role 和 ClusterRole 定义“能做什么”，Binding 将“谁”与“能做什么”关联起来。

构件	作用范围	适用场景	示例
Role	单个命名空间（Namespace）	限制某用户只能操作特定命名空间内的 Pod、Service	`role-"pod-reader" in "default"`
ClusterRole	整个集群（所有命名空间 + 集群级资源）	管理节点、PV、Namespace 等集群资源，或跨命名空间授权	`clusterrole-"cluster-admin"`
RoleBinding	单个命名空间	将 Role 绑定到某命名空间内的用户/服务账号	`rolebinding-"read-pods"`
ClusterRoleBinding	整个集群	将 ClusterRole 绑定到全局用户/组，授予集群级权限	`clusterrolebinding-"admin-all"`

关键区别：Role 和 RoleBinding 是命名空间级别的；ClusterRole 和 ClusterRoleBinding 是集群级别的。一个 ClusterRole 可以被 RoleBinding 引用，从而在特定命名空间内生效，这是实现“跨命名空间复用权限集”的常用模式。

2.2 Role 与 ClusterRole：定义权限规则

Role 和 ClusterRole 的 YAML 结构几乎相同，唯一区别是 kind 字段。它们都包含一组 rules，每条规则由 apiGroups、resources、verbs 组成。

# Role 示例：只允许读取 default 命名空间的 Pod
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]               # 核心 API 组
  resources: ["pods"]           # 资源类型
  verbs: ["get", "list", "watch"]  # 允许的操作

# ClusterRole 示例：允许读取所有命名空间的 Pod 以及 Nodes
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: global-pod-and-node-reader
rules:
- apiGroups: [""]
  resources: ["pods", "nodes"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]       # 子资源
  verbs: ["get"]

  权限规则编写要点：
  apiGroups："" 表示核心组（Pod、Service、Node 等）；"apps" 表示 Deployment、StatefulSet；"batch" 表示 Job、CronJob。
resources：支持子资源，如 pods/log、deployments/status。
verbs：常用 get、list、watch（只读）；create、update、patch、delete（写操作）。
resourceNames：可选字段，进一步限制到特定资源实例。

2.3 RoleBinding 与 ClusterRoleBinding：建立绑定关系

Binding 将 Subject（用户、组、服务账号）与 Role/ClusterRole 关联。RoleBinding 只能引用同一命名空间的 Role，但可以引用 ClusterRole（此时 ClusterRole 的权限被限制在该命名空间内）。

# RoleBinding 示例：将 pod-reader 角色绑定到用户 alice
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: alice-pod-reader
  namespace: default
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

# ClusterRoleBinding 示例：将 cluster-admin 角色绑定到整个运维组
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ops-admin-binding
subjects:
- kind: Group
  name: ops-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

绑定陷阱：RoleBinding 的 roleRef 一旦创建即不可更改（不可变字段）。要修改绑定关系，必须删除并重建 RoleBinding。这是 Kubernetes 的安全设计，防止权限被意外篡改。

2.4 Subjects 类型：谁在请求访问

Subjects 是 RBAC 中的“主体”，代表发起 API 请求的实体。Kubernetes 支持三种 Subject 类型：

Subject 类型	kind 字段值	典型用途	示例名称
User	`User`	自然人管理员、开发者（通常通过证书或 OIDC 认证）	`alice`、`john.doe@example.com`
Group	`Group`	用户组，简化批量授权（如 LDAP 组、OIDC 组）	`ops-team`、`developers`
ServiceAccount	`ServiceAccount`	Pod 内进程的身份，用于 Pod 与 API Server 交互	`default`、`my-app-sa`

服务账号最佳实践：每个应用应使用独立的 ServiceAccount，而非共享 default 账号。通过 automountServiceAccountToken: false 可关闭不需要 API 访问的 Pod 的令牌自动挂载。

2.5 授权流程与绑定关系图

下图展示了 RBAC 从请求到授权的完整链路，以及 Role/ClusterRole 与 Binding 的匹配逻辑。

2.6 常见授权模式与避坑指南

以下列出生产环境中常见的 RBAC 授权模式及其注意事项：

最小权限原则：永远从 get、list、watch 开始，按需添加 create、update、delete。避免直接使用 cluster-admin 或通配符 *。
跨命名空间授权：使用 ClusterRole + RoleBinding 组合，将集群级权限集限制到特定命名空间。例如，ClusterRole 定义 pods/* 的读写，RoleBinding 在 production 命名空间引用它。
聚合 ClusterRole：通过 aggregationRule 将多个 ClusterRole 合并，适合按功能模块组织权限（如 admin、edit、view）。
避免绑定到 system:authenticated 组：该组包含所有经过认证的用户，绑定后可能导致权限过度扩散。
定期审计：使用 kubectl auth can-i --list --as=USER 或审计日志检查实际权限，确保无冗余或越权绑定。

快速验证命令：

# 检查当前用户能否在 default 命名空间创建 Pod
kubectl auth can-i create pods --namespace default

# 模拟用户 alice 的权限
kubectl auth can-i list pods --as alice --namespace default

# 列出所有 RoleBinding 及其绑定的 Subject
kubectl get rolebinding --all-namespaces -o wide