4. Cilium 准入控制机制：ValidatingAdmissionPolicy 与 MutatingAdmissionWebhook 的角色
Cilium 在 Kubernetes 集群中不仅承担数据平面与网络策略执行者的角色，更通过 准入控制机制 成为策略治理的“守门员”。在平台门户集成场景下，Cilium 利用 Kubernetes 原生的准入控制扩展点，在资源被持久化到 etcd 之前完成策略校验与自动修正。本章聚焦 ValidatingAdmissionPolicy 与 MutatingAdmissionWebhook 两种机制在 Cilium 中的具体角色与协作模式。
4.1 准入控制机制概览
Kubernetes 准入控制分为两个阶段：变更（Mutating） 与 验证（Validating）。Cilium 同时部署了两种类型的准入控制器，分别承担不同的策略职责：
| 准入类型 | Kubernetes 资源 | Cilium 中的角色 | 执行时机 |
|---|---|---|---|
| MutatingAdmissionWebhook | MutatingWebhookConfiguration | 自动注入 Cilium 边车、修正 Pod 安全上下文、附加网络策略标签 | 资源验证之前 |
| ValidatingAdmissionPolicy | ValidatingWebhookConfiguration | 校验 CiliumNetworkPolicy / CiliumClusterwideNetworkPolicy 语法与语义 | 资源变更之后、持久化之前 |
关键认知： Mutating 阶段负责“补全与修正”，Validating 阶段负责“拒绝与拦截”。Cilium 将两者组合使用，形成完整的策略准入闭环。
4.2 Cilium 准入控制架构
下图展示了 Cilium 准入控制机制在 Kubernetes API 请求处理流程中的位置与交互关系：
架构要点：
- API Server 在收到资源请求后，先调用 MutatingWebhook 进行资源变更，再调用 ValidatingWebhook 进行最终校验。
- Cilium Agent 同时注册两种 Webhook，但处理逻辑分离：Mutating 侧重边车注入与标签修正，Validating 侧重网络策略语法与语义校验。
- 只有通过两个阶段的资源才会被写入 etcd，确保集群状态始终符合 Cilium 策略模型。
4.3 MutatingAdmissionWebhook：自动注入与修正
Cilium 的 MutatingAdmissionWebhook 主要承担以下职责：
- Cilium 边车自动注入：为特定命名空间或标签匹配的 Pod 自动注入 Cilium Agent 边车容器，用于实现高级网络功能（如 L7 策略、可观测性）。
- Pod 安全上下文修正：自动添加必要的
securityContext.capabilities，确保 Pod 能够加载 BPF 程序或访问网络命名空间。 - 网络策略标签附加：根据命名空间默认策略或全局策略，自动为 Pod 附加
io.cilium.k8s.policy.clusterwide等标签，简化策略匹配。 - 资源注解标准化：统一注入
cilium.io/skip-identity-resolution等注解，控制 Cilium 身份解析行为。
注意： MutatingWebhook 的配置必须谨慎。错误的注入规则可能导致 Pod 启动失败或网络中断。建议在平台门户中提供“注入策略预览”功能，让用户提前查看变更效果。
4.4 ValidatingAdmissionPolicy：策略语法与语义校验
ValidatingAdmissionPolicy 是 Cilium 策略安全性的最后一道防线。其核心校验逻辑包括：
| 校验维度 | 校验内容 | 拒绝示例 |
|---|---|---|
| 语法正确性 | YAML/JSON 结构、字段类型、必填字段 | 缺少 endpointSelector 的 CiliumNetworkPolicy |
| 语义一致性 | 规则冲突检测、CIDR 格式、端口范围 | 同时允许和拒绝同一端口的规则 |
| 安全约束 | 禁止通配符出口、禁止高危端口暴露 | toPorts: [0-65535] 的过度开放策略 |
| 集群范围合规 | 跨命名空间策略引用、全局策略冲突 | CiliumClusterwideNetworkPolicy 与同名 Namespace 策略冲突 |
4.5 两种机制的协作流程
在平台门户集成场景下，用户提交一条 CiliumNetworkPolicy 时，准入控制链的完整执行流程如下：
- 用户提交：通过平台门户 UI 或 kubectl 创建 CiliumNetworkPolicy 资源。
- Mutating 阶段：Cilium MutatingWebhook 自动补全缺失的
labels、annotations，并修正endpointSelector的命名空间限定。 - Validating 阶段：Cilium ValidatingWebhook 执行语法解析、规则冲突检测、安全约束检查。
- 结果反馈：
- 通过 → 资源写入 etcd，Cilium Agent 下发 BPF 规则。
- 拒绝 → API Server 返回 403 Forbidden，平台门户展示具体错误原因。
最佳实践： 在平台门户中，建议将 ValidatingAdmissionPolicy 的拒绝信息直接映射为前端表单校验提示，帮助用户快速定位策略编写错误，减少反复提交。
4.6 平台门户集成要点
将 Cilium 准入控制机制集成到平台门户时，需关注以下关键点：
- Webhook 配置管理：平台门户应提供 MutatingWebhookConfiguration 与 ValidatingWebhookConfiguration 的查看与状态监控界面。
- 策略预览与模拟：在提交前，调用 Cilium 的
cilium policy validate命令或直接调用 Webhook 接口进行预校验。 - 审计日志集成：记录每次准入控制的决策结果（允许/拒绝/变更），便于事后审计与策略合规追溯。
- 故障隔离：当 Webhook 服务不可用时，Kubernetes 默认行为是拒绝所有资源操作。平台门户应提供 Webhook 健康检查与熔断机制。
总结： Cilium 的 MutatingAdmissionWebhook 与 ValidatingAdmissionPolicy 分别承担“自动修正”与“严格校验”的角色，两者协同工作，确保平台门户中提交的每一条网络策略在进入集群前都经过完整的合规检查。理解这一机制，是后续章节中实现策略移植适配与验证的基础。