2. Kubernetes RBAC 基础回顾：Role、ClusterRole、RoleBinding、ClusterRoleBinding、ServiceAccount 与用户组

在深入容器运行时治理控制面的 RBAC 策略命中率与误报复核之前，必须牢固掌握 Kubernetes 原生的授权模型。RBAC（Role-Based Access Control）是 Kubernetes 1.8+ 的默认授权模式，它通过 角色（Role）、绑定（Binding） 和 主体（Subject） 三个核心概念，精确控制谁可以对哪些资源执行什么操作。

2.1 核心资源对象与作用域

Kubernetes RBAC 将权限控制分为 命名空间级别 和 集群级别 两个作用域。下表清晰对比了四个核心 RBAC 资源对象：

资源对象 作用域 授权资源 典型用途
Role 命名空间（Namespace） Pod、Service、Deployment 等命名空间资源 限制某团队只能操作指定命名空间内的 Pod
ClusterRole 集群（Cluster） Node、PV、ClusterRole 等集群资源 + 所有命名空间资源 授予管理员查看所有命名空间 Pod 的权限
RoleBinding 命名空间（Namespace） 将 Role/ClusterRole 绑定到主体 将“只读角色”绑定给开发人员
ClusterRoleBinding 集群（Cluster） 将 ClusterRole 绑定到主体 将“集群管理员”角色绑定给运维团队
关键原则： Role 只能授予命名空间内的资源访问权限；ClusterRole 可以授予集群级资源权限，也可以被 RoleBinding 引用，从而在单个命名空间内生效。这种设计实现了权限的灵活复用与精细隔离。

2.2 主体类型：ServiceAccount 与用户组

RBAC 中的 主体（Subject） 是权限的接收方，Kubernetes 支持三种主体类型：

  • ServiceAccount：Kubernetes 内置的命名空间资源，用于为 Pod 中的进程提供身份。每个 Pod 必须关联一个 ServiceAccount（默认是 default）。
  • User：代表真实的人类用户，通常由外部身份提供商（如 OIDC、LDAP）管理，Kubernetes 本身不创建 User 对象。
  • Group：一组用户的集合，用于批量授权。常见的组包括 system:masters（超级管理员组）、system:nodes（节点组）等。
实践建议： 在容器运行时治理场景中，优先使用 ServiceAccount 作为 Pod 的身份凭证，避免使用共享的 User 或 Group。每个微服务或治理组件应拥有独立的 ServiceAccount，便于审计和策略命中率分析。

2.3 RBAC 策略的语法结构

一个完整的 RBAC 策略由 规则（rules） 定义，每条规则包含三个核心字段：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]          # 核心 API 组，"" 表示 core
  resources: ["pods"]      # 资源类型
  verbs: ["get", "list", "watch"]  # 允许的操作

规则中的 verbs 决定了主体可以执行的操作类型，常见动词包括：

  • get / list / watch：读取操作
  • create / update / patch：写入操作
  • delete / deletecollection：删除操作
  • impersonate：模拟其他用户（高危权限）

2.4 绑定关系与权限聚合

下图展示了 RoleBinding 和 ClusterRoleBinding 如何将角色与主体关联，形成最终的权限集合：

RBAC 绑定关系与权限聚合示意图 主体 (Subject) ServiceAccount / User / Group 绑定 (Binding) RoleBinding / ClusterRoleBinding 角色 (Role) Role / ClusterRole 权限聚合结果 主体拥有的最终权限 = 所有绑定中角色的规则并集 命名空间作用域 Role + RoleBinding 仅影响指定 Namespace 集群作用域 ClusterRole + ClusterRoleBinding 影响整个集群

2.5 常见 RBAC 策略模式

在容器运行时治理场景中，以下四种 RBAC 模式最为常见：

模式 角色类型 绑定类型 适用场景
命名空间只读 Role RoleBinding 开发人员查看指定命名空间的 Pod 日志
命名空间读写 Role RoleBinding CI/CD 工具在测试命名空间部署应用
集群只读 ClusterRole ClusterRoleBinding 监控系统查看所有命名空间的资源状态
集群管理员 ClusterRole ClusterRoleBinding 平台运维团队管理节点和集群级资源
误报风险提示： 在策略命中率审计中，ClusterRole 被 RoleBinding 引用 的模式最容易产生误报。例如，一个 ClusterRole 定义了“读取所有 Pod”的权限，但被 RoleBinding 绑定到特定命名空间后，审计系统可能误判为“该主体拥有集群级 Pod 读取权限”，导致命中率统计偏差。后续章节将详细讲解如何通过 kubectl auth can-i 和审计日志消除此类误报。

2.6 ServiceAccount 与 Pod 身份绑定

ServiceAccount 是容器运行时治理中最常使用的主体类型。每个 Pod 在创建时可以通过 spec.serviceAccountName 字段指定使用的 ServiceAccount：

apiVersion: v1
kind: Pod
metadata:
  name: runtime-agent
  namespace: kube-system
spec:
  serviceAccountName: runtime-scanner-sa
  containers:
  - name: scanner
    image: runtime-scanner:latest

当 Pod 中的进程向 API Server 发起请求时，Kubernetes 会自动挂载 ServiceAccount 的 JWT ，API Server 通过 中的身份信息进行 RBAC 鉴权。这一机制是后续策略命中率分析的数据基础。

2.7 用户组与系统预置角色

Kubernetes 内置了多个系统用户组和预置 ClusterRole，理解它们有助于避免误报：

  • system:masters：绑定到 cluster-admin ClusterRole，拥有集群最高权限。
  • system:nodes：节点组，绑定到 system:node ClusterRole，允许 kubelet 访问节点相关资源。
  • system:serviceaccounts：所有 ServiceAccount 的组，可用于批量授权。
  • system:authenticated：所有经过认证的用户自动加入的组。
审计要点： 在复核 RBAC 策略命中率时，务必区分 直接绑定 和 组继承绑定。例如，一个 ServiceAccount 可能没有直接绑定任何角色，但因为它属于 system:authenticated 组，可能通过组绑定获得了某些权限。忽略组继承关系是导致误报的常见原因之一。
← 上一章 📖 返回目录 下一章 →