📚 课程目录第2章 Kubernetes RBAC架构

2. Kubernetes RBAC 架构：API Server 认证授权流程与核心关系

本章深入解析 Kubernetes 控制平面的安全访问机制。理解 API Server 的认证授权流程、RBAC 在控制平面中的位置以及 RBAC 与 ServiceAccount 的关系，是构建安全云原生运行基线的第一步。只有掌握这些底层架构，才能精准配置权限，避免越权与配置漂移。

2.1 K8s API Server 认证授权流程

所有对 Kubernetes 集群的操作（kubectl、Pod 内部请求、控制器循环）都必须经过 API Server 的请求处理管道。该管道分为三个严格顺序的阶段：认证（Authentication）→ 授权（Authorization）→ 准入控制（Admission Control）。

  核心原则： 认证确定“你是谁”，授权确定“你能做什么”，准入控制确定“你做的内容是否符合集群策略”。三个阶段任一失败，请求即被拒绝。

下图展示了 API Server 对一次 kubectl 请求的完整处理流程：

审计合规提示： 在安全基线核验中，必须检查 API Server 的 --authorization-mode 参数。生产集群应设置为 Node,RBAC，确保 RBAC 是主要的授权模式，且 Node 授权仅用于 kubelet 自身通信。

2.2 RBAC 在控制平面中的位置

RBAC（基于角色的访问控制）是 Kubernetes 控制平面中默认且推荐的授权模块。它位于 API Server 内部的授权阶段，作为一组内置的 Authorizer 运行。

控制平面组件与 RBAC 的交互关系如下表所示：

控制平面组件	与 API Server 通信方式	RBAC 管控范围
kube-apiserver	自身进程内调用	作为授权引擎，对所有请求执行 RBAC 检查
kube-controller-manager	使用 ServiceAccount 或 kubeconfig	控制器循环的读写操作受 RBAC 约束
kube-scheduler	使用 ServiceAccount 或 kubeconfig	调度器绑定 Pod 等操作受 RBAC 约束
etcd	仅通过 API Server 访问	不直接受 RBAC 管控，但 API Server 的 RBAC 策略间接保护 etcd 数据
kubelet	使用 TLS 证书 + Node 授权	Node 授权 + RBAC 共同决定 kubelet 的 API 访问权限

RBAC 在控制平面中的位置可以概括为：API Server 是唯一与 etcd 交互的组件，RBAC 是 API Server 内部授权阶段的核心决策者。所有组件（包括控制器、调度器、kubelet）对集群资源的操作，最终都通过 API Server 的 RBAC 检查。

常见配置陷阱： 不要为 kube-controller-manager 和 kube-scheduler 授予 cluster-admin 权限。它们只需要操作特定资源的权限（如 Pod、Node、Endpoint）。过度授权会扩大攻击面，一旦组件被攻陷，攻击者即可获得集群控制权。

2.3 RBAC 与 ServiceAccount 的关系

ServiceAccount 是 Kubernetes 中为 Pod 内运行的进程提供身份的机制。RBAC 与 ServiceAccount 的关系可以总结为：ServiceAccount 是身份载体，RBAC 是权限控制策略。两者通过 RoleBinding / ClusterRoleBinding 绑定在一起。

下图展示了 ServiceAccount、Role、RoleBinding 三者之间的协作关系：

2.3.1 核心概念对比

概念	作用域	核心作用	典型使用场景
ServiceAccount	命名空间	为 Pod 提供身份标识，用于 API Server 认证	Pod 访问 API Server、拉取镜像、与云服务交互
Role	命名空间	定义一组权限规则（如 get pods, create deployments）	限制应用只能操作本命名空间内的资源
ClusterRole	集群	定义集群级别权限（如 nodes, persistentvolumes）	集群管理员、监控组件、跨命名空间控制器
RoleBinding	命名空间	将 Role 绑定到 User/Group/ServiceAccount	将特定命名空间权限授予某个 ServiceAccount
ClusterRoleBinding	集群	将 ClusterRole 绑定到 User/Group/ServiceAccount	授予 ServiceAccount 集群级别权限

2.3.2 实战：为 Pod 配置最小权限 ServiceAccount

以下是一个完整的权限最小化配置示例，展示如何为应用 Pod 创建专用的 ServiceAccount 并绑定仅包含必要权限的 Role：

# 1. 创建专用 ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: production
---
# 2. 创建最小权限 Role（仅允许读取 Pod 和日志）
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
---
# 3. 通过 RoleBinding 将 SA 绑定到 Role
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: production
  name: my-app-read-pods
subjects:
- kind: ServiceAccount
  name: my-app-sa
  namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
---
# 4. 在 Pod 中引用该 ServiceAccount
apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
  namespace: production
spec:
  serviceAccountName: my-app-sa  # 关键：指定 SA
  containers:
  - name: my-app
    image: my-app:latest

审计核验要点： 在云原生运行基线核验中，应检查以下内容：
1. 是否每个命名空间都创建了专用的 ServiceAccount，而非使用默认的 default SA？
2. 是否每个 Role 的 verbs 和 resources 都遵循最小权限原则？
3. 是否存在 ClusterRoleBinding 将 cluster-admin 绑定到非管理员 ServiceAccount？

2.4 本章小结

API Server 请求管道：认证 → 授权（RBAC）→ 准入控制，三个阶段缺一不可。
RBAC 在控制平面中的位置：作为 API Server 内置的授权模块，管控所有组件对集群资源的访问。
RBAC 与 ServiceAccount 的关系：ServiceAccount 提供身份，RBAC 提供权限，通过 RoleBinding/ClusterRoleBinding 连接。
最小权限原则：始终为每个应用创建专用 ServiceAccount，并绑定仅包含必要操作的 Role。