📚 课程目录第2章 Kubernetes RBAC基础

2. Kubernetes RBAC 基础：Role、ClusterRole、RoleBinding、ClusterRoleBinding

在 Helm Chart 接入集群的权限边界设计中，RBAC（基于角色的访问控制）是 Kubernetes 原生的授权机制。理解 Role、ClusterRole、RoleBinding、ClusterRoleBinding 四个核心资源，是构建最小权限原则和审计链路的基础。本节从资源作用域、绑定关系、权限聚合三个维度展开。

2.1 核心概念与作用域

Kubernetes RBAC 将权限分为两个维度：资源作用域（命名空间级 vs 集群级）和权限主体（User、Group、ServiceAccount）。四个资源的关系如下表：

资源类型	作用域	定义权限	绑定目标	典型用途
Role	命名空间（Namespace）	对特定命名空间内资源的操作规则	同一命名空间内的主体	限制 Chart 部署的 Pod 只能读写本命名空间的 ConfigMap
ClusterRole	集群全局	对集群范围资源（Node、PV、ClusterRole 等）或跨命名空间资源的操作规则	集群级别或通过 RoleBinding 限定命名空间	Helm 安装器需要读取所有命名空间的 StorageClass
RoleBinding	命名空间	将 Role 或 ClusterRole 绑定到主体，权限仅在该命名空间生效	User / Group / ServiceAccount	将只读 Role 授予 Chart 中的 ServiceAccount
ClusterRoleBinding	集群全局	将 ClusterRole 绑定到主体，权限在整个集群生效	User / Group / ServiceAccount	为集群管理员 ServiceAccount 授予超级权限

关键区别：RoleBinding 引用 ClusterRole 时，权限会被“裁剪”到该命名空间内——即主体只能操作该命名空间下的资源，即使 ClusterRole 定义了集群范围的权限。这是 Helm Chart 实现多租户隔离的常用模式。

2.2 权限对象关系图

下图展示了四种 RBAC 资源之间的绑定关系与作用域边界：

2.3 权限规则定义语法

Role 和 ClusterRole 使用相同的 rules 字段结构，区别仅在于资源作用域。以下是一个 Helm Chart 中常见的只读 Role 定义：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-app
  name: my-app-reader
rules:
- apiGroups: [""]          # 核心 API 组
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets"]
  verbs: ["get", "list"]

ClusterRole 示例——允许读取集群范围的节点和存储类：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-storage-viewer
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes"]
  verbs: ["get", "list"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list"]

2.4 绑定关系与主体映射

RoleBinding 和 ClusterRoleBinding 将权限授予主体。主体可以是：

User：外部认证用户（如 OIDC 登录用户），通常用于集群管理员审计。
Group：用户组，用于批量授权。
ServiceAccount：Kubernetes 内部身份，是 Helm Chart 中最常用的主体类型。

以下是将只读 Role 绑定到 Chart 中 ServiceAccount 的 RoleBinding：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-app-read-binding
  namespace: my-app
subjects:
- kind: ServiceAccount
  name: my-app-sa
  namespace: my-app
roleRef:
  kind: Role
  name: my-app-reader
  apiGroup: rbac.authorization.k8s.io

使用 ClusterRoleBinding 将集群管理员权限授予外部用户：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-binding
subjects:
- kind: User
  name: "ops-admin@example.com"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

2.5 权限聚合与 Helm Chart 最佳实践

在 Helm Chart 中，RBAC 资源通常放在 templates/ 目录下，通过 .Values.rbac 控制是否创建。以下是权限聚合的三种模式：

模式	适用场景	实现方式	审计要点
最小权限模式	普通应用 Chart	只创建 Role + RoleBinding，限定在 Chart 所在命名空间	检查 verbs 是否包含不必要的 create/delete
跨命名空间模式	监控、日志收集器	创建 ClusterRole + RoleBinding（在每个目标命名空间创建）	确认 RoleBinding 只绑定到需要的命名空间
集群管理模式	Operator、控制器	创建 ClusterRole + ClusterRoleBinding	严格限制主体为特定 ServiceAccount，避免使用 cluster-admin

安全警告：Helm Chart 中避免使用 cluster-admin 或包含 resources: ["*"]、verbs: ["*"] 的 ClusterRole。如果必须使用，应在 values.yaml 中显式声明并默认禁用，同时通过审计日志记录每次绑定操作。

2.6 审计链路中的 RBAC 关键字段

Kubernetes 审计日志会记录每次 RBAC 资源的创建、更新、删除操作。审计事件中的关键字段如下：

user.username：执行操作的用户或 ServiceAccount 名称。
objectRef.resource：操作的目标资源类型（如 roles、rolebindings）。
objectRef.namespace：目标资源所在的命名空间（ClusterRole/ClusterRoleBinding 为空）。
responseStatus.code：操作结果（201 创建成功，403 权限拒绝）。
requestObject：提交的 RBAC 资源定义，包含 rules 和 subjects 详情。

通过审计日志可以追溯：谁在何时、为哪个 ServiceAccount 授予了哪些权限。这是 Helm Chart 权限边界合规审计的核心数据源。