2. Kubernetes API 访问控制全景：认证、授权、准入控制三层架构，RBAC在授权层的作用
Kubernetes 控制平面的安全核心在于对 API Server 的访问控制。所有对集群状态的查询与变更（通过 kubectl、客户端库、Pod 内 ServiceAccount 或直接 REST 调用）都必须经过 API Server 的三层安全防线：认证（Authentication） → 授权（Authorization） → 准入控制（Admission Control）。理解这三层架构是进行 RBAC 权限审计的前提。
2.1 三层架构总览：认证 → 授权 → 准入
下图展示了请求到达 API Server 后依次经过的三个安全阶段。每一层都独立负责一个安全决策，只有全部通过，请求才会被持久化到 etcd 并返回响应。
2.2 第一层：认证（Authentication）
认证层负责确认“你是谁”。API Server 支持多种认证模块，按顺序尝试，只要有一个模块验证通过即完成认证。认证通过后，请求中会携带用户的身份信息（Username、UID、Groups）。
| 认证模块 | 典型场景 | 身份来源 |
|---|---|---|
| X.509 客户端证书 | kubeconfig 中的 client-certificate | CN → Username，O → Groups |
| 静态令牌（Static ） | ServiceAccount 的 Secret | 令牌文件中的用户名 |
| Bootstrap | kubeadm 初始化时的节点加入 | system:bootstrappers 组 |
| OpenID Connect (OIDC) | 企业 SSO 集成（如 Dex、Keycloak） | ID 中的 claims |
| Webhook | 自定义认证服务 | 外部服务返回的身份 |
| 匿名请求 | 未配置认证信息的请求 | system:anonymous 用户 |
--anonymous-auth=false）。生产环境应禁用匿名访问，或严格限制其权限。
2.3 第二层：授权（Authorization）—— RBAC 的核心战场
授权层负责确认“你能做什么”。在认证通过后，API Server 根据请求者的身份（User、Group、ServiceAccount）和请求的操作（Verb、Resource、Namespace）来决定是否允许该请求。Kubernetes 支持多种授权模式，其中 RBAC（Role-Based Access Control） 是生产环境最常用、也是安全审计最关注的标准模式。
2.3.1 授权模式对比
| 授权模式 | 工作原理 | 适用场景 | 审计复杂度 |
|---|---|---|---|
| RBAC | 基于 Role/ClusterRole + RoleBinding/ClusterRoleBinding | 生产标准，细粒度权限控制 | 中（需审计绑定关系） |
| ABAC | 基于 JSON 策略文件，属性匹配 | 已弃用，不推荐 | 高（策略文件难以维护） |
| Webhook | 调用外部 REST 服务做授权决策 | 企业自定义策略引擎 | 高（依赖外部系统） |
| Node | 专门授权 kubelet 的节点相关操作 | 节点自身权限 | 低（内置规则） |
| AlwaysDeny / AlwaysAllow | 全部拒绝或全部允许 | 测试/开发环境 | 无 |
2.3.2 RBAC 在授权层中的角色
当 API Server 的授权模块设置为 --authorization-mode=RBAC 时，所有请求都会经过 RBAC 评估器。RBAC 的核心逻辑可以概括为：
# 伪代码：RBAC 授权决策逻辑
if 请求者 (User/Group/SA) 通过 RoleBinding/ClusterRoleBinding
关联了某个 Role/ClusterRole:
且该 Role/ClusterRole 包含匹配请求 (Verb, Resource, Namespace) 的规则:
→ 允许 (Allow)
else:
→ 拒绝 (Deny)2.4 第三层：准入控制（Admission Control）
准入控制层在请求被持久化之前执行，负责确认“请求是否符合集群策略”。与认证和授权不同，准入控制器可以修改（Mutating）或验证（Validating）请求对象。Mutating 控制器先执行（如自动注入 Sidecar），Validating 控制器后执行（如检查资源配额）。
PodSecurityPolicy、ValidatingAdmissionWebhook）可以绕过 RBAC 的限制。例如，即使 RBAC 允许创建 Pod，但 PSP 拒绝特权容器，则 Pod 创建仍会失败。审计时需同时检查 RBAC 和准入控制器的配置。
2.5 三层架构与 RBAC 审计的关系
在进行 RBAC 权限审计时，必须将三层架构作为一个整体来考虑：
- 认证层：确认所有用户身份来源可靠，没有匿名或弱认证方式。
- 授权层（RBAC）：检查 Role/ClusterRole 的规则是否最小权限，绑定关系是否合理。
- 准入控制层：确认没有控制器绕过 RBAC 的限制，或引入额外的安全风险。