📚 课程目录第4章 Cilium准入控制机制

4. Cilium 准入控制机制：ValidatingAdmissionPolicy 与 MutatingAdmissionWebhook

Cilium 的准入控制是保障服务目录平台策略合规的核心防线。在 Kubernetes 资源（如 Pod、Service）被持久化到 etcd 之前，准入控制器会拦截请求，执行策略检查或修改。Cilium 通过两种标准 Kubernetes 机制实现这一目标：ValidatingAdmissionPolicy（验证性准入策略）和 MutatingAdmissionWebhook（变更性准入 Webhook）。

4.1 准入控制机制概念对比

特性	ValidatingAdmissionPolicy	MutatingAdmissionWebhook
执行时机	在对象被持久化之前，仅做验证	在对象被持久化之前，可修改对象
核心能力	拒绝不符合策略的请求	注入 Sidecar、修改标签、调整安全上下文
策略定义	使用 CEL（Common Expression Language）编写规则	使用 Webhook 服务（通常是 Go 或 Python）处理
性能开销	低，内置于 kube-apiserver	中等，需要调用外部 HTTP 服务
Cilium 使用场景	验证网络策略标签合规、禁止特权容器	自动注入 Cilium Sidecar、设置 eBPF 钩子

关键理解：ValidatingAdmissionPolicy 是“守门员”，只说不；MutatingAdmissionWebhook 是“装修队”，先进来改造再放行。Cilium 通常组合使用两者：先 Mutate 注入必要配置，再 Validate 确保最终状态合规。

4.2 Cilium 如何利用准入控制实现策略合规

Cilium 的准入控制体系围绕 CiliumNetworkPolicy 和 CiliumClusterwideNetworkPolicy 的合规性展开。在服务目录平台中，每个微服务上线前，必须通过准入控制验证其网络策略是否符合安全基线。

4.2.1 基于 ValidatingAdmissionPolicy 的标签合规检查

以下示例展示如何使用 CEL 表达式验证 Pod 必须包含 app.kubernetes.io/name 标签，且不能使用 hostNetwork: true：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: cilium-pod-label-policy
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: "has(object.metadata.labels) && has(object.metadata.labels['app.kubernetes.io/name'])"
      message: "Pod 必须包含 app.kubernetes.io/name 标签"
    - expression: "!has(object.spec.hostNetwork) || object.spec.hostNetwork != true"
      message: "禁止使用 hostNetwork 模式"

  平台集成效果：当开发者在流水线中部署服务时，如果 Pod 缺少必要标签或尝试使用 hostNetwork，kube-apiserver 会直接拒绝请求，错误信息会返回给 CI/CD 流水线，阻断发布。

4.2.2 基于 MutatingAdmissionWebhook 的 Sidecar 注入

Cilium 的 MutatingWebhook 可以在 Pod 创建时自动注入 Cilium 的 Envoy Sidecar 代理，用于实现 L7 策略和可观测性。Webhook 配置示例：

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: cilium-sidecar-injector
webhooks:
  - name: sidecar.cilium.io
    clientConfig:
      service:
        name: cilium-sidecar-injector
        namespace: kube-system
        path: /mutate
      caBundle: <base64-encoded-ca-cert>
    rules:
      - operations: ["CREATE"]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
    admissionReviewVersions: ["v1"]
    sideEffects: None
    namespaceSelector:
      matchLabels:
        cilium-sidecar-injection: enabled

注入逻辑通常包括：

添加 initContainers 用于配置 eBPF 程序
添加 containers 运行 Envoy 代理
修改 Pod 安全上下文以允许 eBPF 系统调用
注入环境变量用于服务网格标识

4.3 准入控制流程架构

下图展示了 Cilium 在服务目录平台中完整的准入控制流程：

4.4 策略合规的准入控制清单

在服务目录平台中，Cilium 准入控制通常覆盖以下合规检查项：

检查类别	具体规则	实现方式
标签合规	必须包含 `app`、`tier`、`environment` 标签	ValidatingAdmissionPolicy
安全上下文	禁止 `privileged: true`、禁止 `hostPID`	ValidatingAdmissionPolicy
网络策略绑定	Pod 必须匹配至少一个 CiliumNetworkPolicy	ValidatingAdmissionPolicy + CEL
Sidecar 注入	为特定命名空间的 Pod 自动注入 Envoy	MutatingAdmissionWebhook
资源限制	必须设置 CPU/Memory requests 和 limits	MutatingAdmissionWebhook（默认值注入）

重要提醒：准入控制是策略合规的最后一道防线，但不能替代流水线中的早期检查。建议在 CI 阶段使用 cilium connectivity test 和 kubectl dry-run 提前发现问题，减少准入拒绝导致的流水线重跑。

4.5 流水线集成最佳实践

策略即代码：将 ValidatingAdmissionPolicy 和 MutatingWebhookConfiguration 的 YAML 文件存储在 Git 仓库中，通过 GitOps 流程管理变更。
灰度发布：使用 namespaceSelector 和 objectSelector 控制准入控制的作用范围，先在测试命名空间启用，验证无误后再推广到生产。
审计日志：启用 Kubernetes 审计日志，记录所有被准入控制拒绝的请求，用于安全分析和策略调优。
性能监控：监控 Webhook 的响应时间（P99 < 100ms），避免准入控制成为集群性能瓶颈。