4. Kubernetes 中的鉴权机制：RBAC、ServiceAccount、Role、ClusterRole、RoleBinding

在分布式事务鉴权拦截系统中，Kubernetes 原生的鉴权机制是保障微服务间调用安全、控制资源访问权限的核心基础设施。本章深入剖析 Kubernetes 基于角色的访问控制（RBAC）体系，涵盖 ServiceAccount、Role、ClusterRole 及 RoleBinding 等关键概念，为后续实现鉴权拦截的热更新设计奠定基础。

4.1 RBAC 鉴权模型概述

RBAC（Role-Based Access Control）是 Kubernetes 默认且推荐的鉴权模式。其核心思想是将“权限”授予“角色”，再将“角色”绑定到“用户”或“服务账户”。这种解耦设计使得权限管理更加灵活、可审计。

Kubernetes RBAC 的鉴权流程可概括为以下步骤：

1. 认证：识别请求发起方的身份（User、Group 或 ServiceAccount）。
2. 授权：根据绑定到该身份的角色规则，判断是否允许执行请求的操作。
3. 准入控制：在对象持久化前，通过 Admission Webhook 进行额外校验或修改。

4.2 ServiceAccount：Pod 的身份标识

ServiceAccount 是 Kubernetes 中为 Pod 提供身份标识的资源对象。与普通用户不同，ServiceAccount 主要用于集群内部进程（如微服务容器）与 API Server 之间的交互。

4.3 Role 与 ClusterRole：权限规则的定义

Role 和 ClusterRole 是 RBAC 中定义权限规则的资源对象。两者的区别在于作用域：Role 作用于特定 Namespace，而 ClusterRole 作用于整个集群。

4.3.1 Role（命名空间级别）

Role 用于在单个 Namespace 内定义一组权限规则。以下示例定义了一个允许对 Pod 和 Deployment 进行读写操作的 Role：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: transaction-system
  name: transaction-manager-role
rules:
- apiGroups: [""]          # 核心 API 组
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: ["txn.example.com"]
  resources: ["transactionrecords"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

4.3.2 ClusterRole（集群级别）

ClusterRole 可以跨 Namespace 生效，常用于定义集群范围的资源权限（如 Node、PersistentVolume）或作为聚合角色被多个 Namespace 引用。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: global-transaction-viewer
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["txn.example.com"]
  resources: ["transactionrecords"]
  verbs: ["get", "list", "watch"]

4.4 RoleBinding 与 ClusterRoleBinding：权限的绑定

RoleBinding 和 ClusterRoleBinding 将 Role/ClusterRole 中定义的权限授予指定的 Subject（User、Group 或 ServiceAccount）。

4.4.1 RoleBinding 示例

将 transaction-manager-role 绑定到 transaction-manager-sa ServiceAccount：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: transaction-manager-binding
  namespace: transaction-system
subjects:
- kind: ServiceAccount
  name: transaction-manager-sa
  namespace: transaction-system
roleRef:
  kind: Role
  name: transaction-manager-role
  apiGroup: rbac.authorization.k8s.io

4.4.2 ClusterRoleBinding 示例

将 global-transaction-viewer ClusterRole 绑定到所有 Namespace 中的审计 ServiceAccount：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: global-audit-binding
subjects:
- kind: ServiceAccount
  name: audit-sa
  namespace: transaction-system
- kind: ServiceAccount
  name: audit-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: global-transaction-viewer
  apiGroup: rbac.authorization.k8s.io

4.5 鉴权拦截与热更新的结合点

在分布式事务鉴权拦截系统中，RBAC 机制与热更新设计的结合主要体现在以下方面：

• 动态权限调整：通过更新 Role 或 ClusterRole 的 rules 字段，可以实时调整微服务对事务状态 CRD 的访问权限，无需重启 Pod 或 API Server。
• ServiceAccount 隔离：每个事务参与者（如协调器、参与者、补偿服务）使用独立的 ServiceAccount，通过 RoleBinding 精确控制其可访问的资源范围。
• Webhook 集成：在鉴权拦截器中，可以结合 SubjectAccessReview API 动态查询当前请求是否具有执行特定操作的权限，实现细粒度的访问控制。
• 配置热更新载体：RBAC 规则本身可以存储在 ConfigMap 中，通过控制器监听 ConfigMap 变更，自动更新对应的 Role/ClusterRole 资源，实现鉴权策略的热加载。