4. 准入权限模型：Kubernetes RBAC 与 Kyverno 策略的交互关系
Kubernetes 的准入控制链中，RBAC（基于角色的访问控制）与 Kyverno 策略引擎 分别承担不同层级的权限校验。RBAC 决定“谁可以执行操作”，而 Kyverno 决定“操作是否符合安全与合规要求”。两者在 API 请求处理流程中按顺序执行，形成互补的权限防线。
4.1 准入控制链中的执行顺序
当 API 请求到达 kube-apiserver 时，经过认证 → 授权（RBAC） → 准入控制（含 Kyverno）三个阶段。Kyverno 作为动态准入 Webhook，在 RBAC 授权通过后介入，因此 Kyverno 策略无法绕过 RBAC 的权限检查，但可以补充 RBAC 无法覆盖的细粒度约束。
关键理解： RBAC 是“门禁”，Kyverno 是“安检”。门禁放行后，安检仍可拦截违规物品。
4.2 RBAC 与 Kyverno 的职责边界
| 维度 | Kubernetes RBAC | Kyverno 策略 |
|---|---|---|
| 控制对象 | 用户 / ServiceAccount / Group | API 请求的 object（资源内容） |
| 决策依据 | 动词（get/list/create/update/delete）+ 资源类型 + 命名空间 | 资源字段值、标签、注解、镜像来源、Pod 安全上下文等 |
| 粒度 | 粗粒度（资源级别） | 细粒度（字段级别、跨资源关联） |
| 变更能力 | 无（仅授权判断） | 支持 Mutating Webhook 自动注入/修改资源 |
| 执行时机 | 认证后、准入前 | RBAC 授权通过后、etcd 写入前 |
| 典型场景 | 限制某用户只能读取 default 命名空间的 Pod | 强制所有 Pod 必须设置 readOnlyRootFilesystem: true |
4.3 交互风险：权限提升与绕过
RBAC 与 Kyverno 的交互存在三类典型风险，策略评审时需要重点关注：
- RBAC 放行但 Kyverno 未覆盖： 用户拥有 create Pod 权限，但 Kyverno 未对 privileged 容器做限制，导致提权。
- Kyverno 变更导致 RBAC 失效： Kyverno 自动注入 sidecar 或修改资源标签，可能使原本匹配的 RBAC 规则失效（例如变更命名空间标签导致 RoleBinding 不匹配）。
- ServiceAccount 提权链： 用户通过 RBAC 创建 ServiceAccount 并绑定高权限 Role，Kyverno 若未限制 ServiceAccount 的创建或绑定，可绕过原有权限控制。
⚠️ 风险提示： 当 Kyverno 策略使用
mutate 修改资源的 metadata.labels 或 metadata.annotations 时，务必评估是否会影响现有 RBAC 绑定的选择器匹配。建议在策略中添加 preconditions 避免意外覆盖。
4.4 策略评审中的权限检查清单
在评审 Kyverno 策略时，应同步检查以下 RBAC 相关项：
- 策略作用范围： 策略是否匹配了超出预期命名空间的资源？是否与 RBAC 的命名空间隔离设计冲突？
- 变更影响： Mutating 策略修改了哪些字段？这些字段是否被 RBAC 的
resourceNames或标签选择器引用？ - ServiceAccount 管控： 是否有策略限制 ServiceAccount 的创建或 RoleBinding/ClusterRoleBinding 的绑定？
- 特权容器： 是否通过策略禁止
privileged: true、hostPID、hostNetwork等危险配置？ - 匿名访问： 策略是否对
system:anonymous或system:unauthenticated用户生效？
4.5 最佳实践：分层防御模型
推荐采用“RBAC + Kyverno + OPA/Gatekeeper”三层防御，但至少确保 RBAC 与 Kyverno 形成互补：
💡 评审建议： 在 Kyverno 策略的
background: true 模式下，策略引擎会扫描已有资源。此时需注意：RBAC 已放行的存量资源可能被 Kyverno 标记为违规，但不会自动删除——需要人工或自动化工具处理。