4、权限审计（RBAC Audit）基础：Kubernetes RBAC 模型、Role/ClusterRole、RoleBinding/ClusterRoleBinding、审计日志基础

4.1 Kubernetes RBAC 模型概述

RBAC（基于角色的访问控制）是 Kubernetes 默认的授权机制，用于控制用户、服务账户对集群资源的操作权限。在 GitOps 交付场景中，RBAC 的精确配置直接决定了资源配额校准与审计的合规性。

RBAC 模型的核心原则是：权限 = 角色 + 绑定。通过将权限预定义到角色中，再将角色绑定到主体（用户/组/服务账户），实现权限的灵活分配与集中管理。

核心概念关系：
  • 主体（Subject）：User、Group、ServiceAccount
  • 角色（Role/ClusterRole）：权限规则的集合
  • 绑定（RoleBinding/ClusterRoleBinding）：将角色与主体关联
Kubernetes RBAC 核心模型 主体（Subject） User Group ServiceAccount 角色（Role） Role（命名空间级） ClusterRole（集群级） 包含：apiGroups / resources / verbs 绑定（Binding） RoleBinding ClusterRoleBinding 关联主体 + 角色 工作流程： 1. 定义 Role/ClusterRole，声明对哪些资源（pods/deployments）拥有哪些操作（get/list/create/delete） 2. 创建 RoleBinding/ClusterRoleBinding，将角色绑定到 User/Group/ServiceAccount 3. 主体发起 API 请求时，RBAC 控制器检查绑定关系，决定是否授权

4.2 Role 与 ClusterRole 的差异与使用场景

对比维度 Role ClusterRole
作用范围 单个命名空间（namespace） 整个集群（所有命名空间 + 集群级资源）
可授权资源 命名空间内的资源（pods、services、deployments 等） 集群级资源（nodes、persistentvolumes、namespaces）以及所有命名空间资源
典型用途 开发团队只能操作自己命名空间的 Pod 集群管理员查看所有节点、跨命名空间读取日志
YAML 示例 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
最佳实践：在 GitOps 资源配额校准场景中，优先使用 Role + RoleBinding 将权限限制在目标命名空间内。仅当需要跨命名空间或操作集群级资源时，才使用 ClusterRole + ClusterRoleBinding。

4.3 RoleBinding 与 ClusterRoleBinding 的绑定机制

绑定是 RBAC 的“胶水层”，决定了谁拥有什么权限。绑定关系支持以下组合：

  • RoleBinding + Role：将命名空间级角色绑定到主体，权限限制在该命名空间
  • RoleBinding + ClusterRole：将集群级角色绑定到主体，但权限仍限制在该命名空间（常用做法，复用 ClusterRole 定义）
  • ClusterRoleBinding + ClusterRole：将集群级角色绑定到主体，权限覆盖整个集群
RoleBinding / ClusterRoleBinding 绑定组合 主体 User/Group/SA RoleBinding 命名空间范围 可绑定 Role 或 ClusterRole ClusterRoleBinding 集群范围 只能绑定 ClusterRole Role 命名空间级 ClusterRole 集群级 关键规则： • RoleBinding 可以绑定 ClusterRole，但权限仍限制在命名空间内 • ClusterRoleBinding 只能绑定 ClusterRole，权限覆盖整个集群

4.4 审计日志基础与 RBAC 关联

Kubernetes 审计日志记录了所有对 API 服务器的请求，是权限审计的核心数据源。在 GitOps 交付资源配额校准场景中，审计日志用于验证 RBAC 配置是否按预期生效。

4.4.1 审计日志阶段

阶段 说明 RBAC 审计用途
RequestReceived API 服务器收到请求 记录原始请求主体与操作
ResponseStarted 响应头已发送，但响应体未完成 用于流式请求的权限检查
ResponseComplete 响应体已完全发送 确认授权结果（允许/拒绝）
Panic 内部错误发生 异常权限请求的标记

4.4.2 审计日志关键字段

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "xxx-xxx-xxx",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/default/pods",
  "verb": "list",
  "user": {
    "username": "dev-user",
    "groups": ["system:authenticated"]
  },
  "sourceIPs": ["10.0.0.1"],
  "userAgent": "kubectl/v1.28.0",
  "responseStatus": {
    "code": 200
  },
  "requestReceivedTimestamp": "2025-01-15T10:00:00Z",
  "stageTimestamp": "2025-01-15T10:00:01Z"
}
审计配置注意事项：
  • 审计日志默认不开启，需在 API 服务器启动参数中配置 --audit-policy-file 和 --audit-log-path
  • 生产环境建议设置 level: RequestResponse 以记录请求和响应详情
  • 审计日志会占用大量磁盘空间，建议配置日志轮转（--audit-log-maxsize、--audit-log-maxbackup）

4.5 权限审计实践：从审计日志反推 RBAC 配置

在 GitOps 交付流程中，权限审计的典型场景是：验证资源配额校准操作是否由授权主体执行。以下是一个完整的审计流程：

  1. 收集审计日志：从 API 服务器日志或集中式日志系统（如 Elasticsearch）获取指定时间段的审计事件
  2. 过滤关键事件：按 verb（create/update/delete）、resource（resourcequotas）、responseStatus.code（403/200）过滤
  3. 关联主体与角色：从审计日志中提取 user.username，查询其绑定的 Role/ClusterRole
  4. 验证权限合规：检查主体是否拥有执行该操作所需的 verbs 和 resources
  5. 生成审计报告：记录违规操作（403 拒绝）和异常权限提升
GitOps 场景示例：当 ArgoCD 同步 ResourceQuota 变更时，审计日志会记录 ServiceAccount argocd-application-controller 的 update 操作。通过审计日志可以确认该 SA 是否绑定了正确的 Role（包含 resourcequotas 的 update 权限），从而避免权限过大或不足的问题。

4.6 本章小结

RBAC 权限审计是 Kubernetes 安全治理的基石。通过理解 Role/ClusterRole 的作用范围差异、RoleBinding/ClusterRoleBinding 的绑定机制，以及审计日志的采集与分析，运维团队可以精确控制 GitOps 交付过程中的资源配额操作权限。下一阶段将深入 Kustomize 如何与 RBAC 策略结合，实现声明式的权限管理。

← 上一章 📖 返回目录 下一章 →