2. 准入策略基础：什么是准入策略、为什么需要准入策略、常见的准入控制场景
在云原生控制平面（如 Kubernetes API Server）中，准入策略（Admission Policy） 是请求处理链路上的一道关键安全闸门。它位于认证（Authentication）与授权（Authorization）之后，对象持久化（etcd 存储）之前，负责对请求进行最后的校验与变更。
2.1 什么是准入策略
准入策略是一组在资源对象被持久化之前执行的校验或修改规则。它拦截所有对 API Server 的写请求（Create、Update、Delete），并决定：
- 是否允许该请求通过（Validating）
- 是否需要修改请求内容（Mutating）
在 Kubernetes 架构中，准入控制被实现为 Admission Controller（编译进 API Server 的插件）或 Webhook（外部 HTTP 回调）。其核心位置如下图所示：
2.2 为什么需要准入策略
在云原生环境中，仅依赖 RBAC（基于角色的访问控制）无法满足细粒度的安全与合规需求。准入策略解决了以下核心问题：
| 需求维度 | 问题描述 | 准入策略的解决方案 |
|---|---|---|
| 安全加固 | 用户可能创建特权容器、挂载敏感主机路径、使用高危镜像 | 通过 Validating 策略拒绝不符合 Pod Security Standards 的 Pod |
| 合规审计 | 需要确保所有资源都包含特定标签（如环境、团队、成本中心） | 通过 Mutating 策略自动注入缺失的标签或注解 |
| 资源管控 | 用户可能忘记设置资源请求/限制，导致集群资源分配不均 | 通过 Mutating 策略自动注入默认资源配额 |
| 运维一致性 | 不同团队可能使用不同的 Sidecar 版本或日志采集配置 | 通过 Mutating 策略统一注入 Sidecar 容器或环境变量 |
| 策略即代码 | 安全策略分散在文档中，难以强制执行和版本管理 | 将策略声明为 Kubernetes 资源（如 ValidatingAdmissionPolicy），纳入 GitOps 流程 |
实践建议： 准入策略应遵循“最小权限”原则。只对必要的资源类型和操作（Create/Update）设置准入控制，避免对 Delete 或 Get 操作进行拦截，以减少 API Server 的延迟开销。
2.3 常见的准入控制场景
根据控制平面架构的不同，准入策略的实现方式分为两大类：内置准入控制器 和 动态准入 Webhook。以下列出生产环境中最高频的 6 个场景：
2.3.1 场景分类与对比
| 场景 | 类型 | 典型实现 | 作用阶段 |
|---|---|---|---|
| Pod 安全标准（PSS） | Validating | PodSecurity 准入控制器 | Pod 创建/更新 |
| 默认资源注入 | Mutating | MutatingWebhookConfiguration | Pod 创建 |
| Sidecar 自动注入 | Mutating | Istio/Linkerd 注入 Webhook | Pod 创建 |
| 镜像签名验证 | Validating | Cosign + Webhook | Pod 创建 |
| 标签/注解合规 | Mutating + Validating | Kyverno / OPA Gatekeeper | 所有资源创建/更新 |
| 网络策略强制 | Validating | 自定义 ValidatingWebhook | NetworkPolicy 创建/更新 |
2.3.2 典型场景流程：Sidecar 自动注入
以服务网格 Sidecar 注入为例，展示 Mutating Webhook 的完整工作流程：
2.4 准入策略的两种类型对比
| 特性 | Mutating（变更型） | Validating（校验型） |
|---|---|---|
| 执行顺序 | 先执行 | 后执行 |
| 核心能力 | 修改请求对象（注入、替换、删除字段） | 校验请求对象（拒绝不符合规则的请求） |
| 典型用例 | 默认值注入、Sidecar 注入、标签自动补全 | 安全策略校验、资源配额校验、合规检查 |
| 幂等性要求 | 必须幂等（多次调用结果一致） | 无特殊要求 |
| 失败行为 | 默认失败关闭（Fail Closed） | 默认失败关闭（Fail Closed） |
注意： 如果同时配置了 Mutating 和 Validating Webhook，API Server 会先执行所有 Mutating Webhook，再执行所有 Validating Webhook。这意味着 Validating Webhook 看到的是经过 Mutating 修改后的最终对象。设计策略时需考虑这一执行顺序，避免校验逻辑与变更逻辑冲突。