2. 核心概念：RBAC 模型基础、角色、权限、用户与服务账户

在构建云原生平台门户的配置缓存命中巡检功能时，权限控制是保障数据安全与操作合规的基石。Kubernetes 原生的 RBAC（基于角色的访问控制） 模型提供了声明式的授权机制，允许管理员通过预定义的角色与绑定关系，精确控制不同身份对集群资源的访问能力。本节将系统梳理 RBAC 的核心概念，为后续设计巡检专用的权限策略奠定理论基础。

2.1 RBAC 模型基础

RBAC 模型的核心思想是：权限不直接授予用户，而是通过“角色”作为中间层进行间接授权。这种设计极大简化了权限管理，当组织架构或人员变动时，只需调整角色绑定，无需逐个修改用户权限。

Kubernetes RBAC 模型包含四个核心实体：

2.2 角色（Role）与权限（Permission）

角色是权限的集合。在 Kubernetes 中，角色分为两种作用域：

• Role（命名空间级别）：权限仅作用于特定命名空间内的资源。
• ClusterRole（集群级别）：权限作用于整个集群，包括所有命名空间、集群范围的资源（如 Node、PersistentVolume）以及非资源端点（如 /healthz）。

权限由三个要素构成：

# 示例：为缓存巡检创建的 Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: portal-system
  name: cache-inspector-role
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list"]
  resourceNames: ["portal-cache-config"]
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]
- apiGroups: ["metrics.k8s.io"]
  resources: ["pods"]
  verbs: ["get", "list"]

2.3 用户（User）与服务账户（ServiceAccount）

在 Kubernetes RBAC 中，用户和服务账户是两种不同的身份主体，它们的认证方式和典型用途有显著差异：

2.4 绑定关系：将角色赋予身份

角色定义完成后，需要通过绑定将其与用户或服务账户关联。绑定也分为两种：

• RoleBinding：在指定命名空间内，将 Role 或 ClusterRole 绑定到主体。
• ClusterRoleBinding：在整个集群范围内，将 ClusterRole 绑定到主体（不能绑定 Role）。

绑定关系支持以下主体类型：

• User：通过 subjects.kind: User 指定用户名。
• Group：通过 subjects.kind: Group 指定用户组。
• ServiceAccount：通过 subjects.kind: ServiceAccount 指定服务账户名称。

# 示例：将巡检角色绑定到服务账户
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: portal-system
  name: cache-inspector-binding
subjects:
- kind: ServiceAccount
  name: cache-inspector-sa
  namespace: portal-system
roleRef:
  kind: Role
  name: cache-inspector-role
  apiGroup: rbac.authorization.k8s.io

2.5 RBAC 核心概念关系图

下图展示了 RBAC 模型中四个核心实体之间的关联关系，以及权限流动的方向：

2.6 巡检场景中的身份选择

在云原生平台门户的配置缓存命中巡检功能中，推荐使用 ServiceAccount 作为巡检组件的身份。原因如下：

1. 自动化运行：巡检组件通常以 CronJob 或 DaemonSet 形式部署在集群内，无需人工交互。
2. 权限隔离：每个巡检任务可拥有独立的 ServiceAccount，避免权限混用。
3. 令牌自动轮换：Kubernetes 1.21+ 支持 ServiceAccount 令牌的自动轮换，降低密钥泄露风险。
4. 命名空间级作用域：ServiceAccount 隶属于命名空间，天然适合按业务模块隔离巡检权限。