RBAC 基础回顾：Kubernetes RBAC 核心概念

在深入 Serverless 控制面之前，必须重新夯实 Kubernetes RBAC 的四个核心构建块。它们是所有策略命中率与误报分析的底层语言。理解这些原语之间的绑定关系与作用域差异，是后续进行策略审计与复核的前提。

2.1 核心资源对象：Role 与 ClusterRole

Role 和 ClusterRole 定义了“能做什么”——即一组权限规则集合。两者的区别仅在于作用域：Role 作用于特定命名空间，ClusterRole 作用于整个集群（包括所有命名空间与集群级别资源）。

2.2 绑定机制：RoleBinding 与 ClusterRoleBinding

绑定是连接“权限集合”（Role/ClusterRole）与“身份”（Subject）的桥梁。绑定决定了谁获得这些权限。

• RoleBinding：将 Role 或 ClusterRole 授予 Subject，且权限范围限定在 RoleBinding 所在的命名空间。即使绑定了 ClusterRole，权限也会被限制在该命名空间内。
• ClusterRoleBinding：仅能将 ClusterRole 授予 Subject，且权限范围覆盖整个集群。不能绑定 Role。

# RoleBinding 示例：将集群级别的 ClusterRole 限制到特定命名空间
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: serverless-pod-reader
  namespace: tenant-alpha
subjects:
- kind: ServiceAccount
  name: serverless-worker
  namespace: tenant-alpha
roleRef:
  kind: ClusterRole
  name: pod-reader        # 全局定义的 ClusterRole
  apiGroup: rbac.authorization.k8s.io

2.3 Subject 类型与识别

Subject 是“谁”在请求权限。Kubernetes RBAC 支持三种 Subject 类型：

• User：通常由外部身份提供商（OIDC、LDAP）管理，Kubernetes 本身不创建 User 对象。
• Group：一组用户的逻辑集合，常用于绑定组织角色（如 system:serviceaccounts）。
• ServiceAccount：由 Kubernetes 管理的命名空间级身份，是 Pod 内进程的默认身份。Serverless 控制面中 90% 的请求来自 ServiceAccount。

2.4 Resource 规则与请求匹配逻辑

RBAC 策略的命中判定基于请求属性与规则字段的精确匹配。一个典型的规则包含以下维度：

# 一个典型的 Serverless 控制面 ClusterRole 规则片段
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["serverless.example.com"]
  resources: ["functions", "functions/status"]
  verbs: ["create", "update", "patch", "delete"]

2.5 核心概念关系图

下图展示了 RBAC 四个核心对象之间的绑定关系与作用域传递路径：

2.6 策略命中率与误报的根源

基于上述核心概念，可以归纳出 RBAC 策略审计中常见的两类问题：

• 命中率偏低：通常因为 Role/ClusterRole 中定义的 resources 或 verbs 与请求不匹配（如缺少子资源 pods/log），或 resourceNames 限制过严。
• 误报高发：静态分析工具常忽略 RoleBinding 对 ClusterRole 的作用域降级语义，将“全局可读”误判为“越权访问”；此外，system:authenticated 等隐式 Group 绑定也容易被遗漏。