Admission Webhook 是 Kubernetes 中实施镜像安全规范最直接灵活的机制，支持验证型（拒绝不合规请求）和变异型（自动修正请求），需通过 ValidatingWebhookConfiguration 或 MutatingWebhookConfiguration 注册，强制使用 TLS 并设 failurePolicy: Fail。
在 Kubernetes 中，Admission Webhook 是实施容器镜像安全规范最直接、最灵活的机制之一。它不依赖修改 kube-apiserver 二进制，也不需要重启控制平面，只需部署一个可验证或可变更的 Webhook 服务，并注册对应配置，就能在 Pod 创建前完成策略拦截。
明确要强制的镜像安全规范
策略必须具体、可判定，否则 Webhook 无法稳定执行。常见且可落地的规范包括：
- 禁止使用 latest 标签（如
nginx:latest） - 仅允许来自可信仓库域名（如只允
harbor.example.com/或registry.internal/） - 要求镜像必须带摘要（digest），例如
redis@sha256:abc123... - 拒绝未签名或未通过 Cosign/Sigstore 验证的镜像（需配合签名验证服务）
选择验证型还是变异型 Webhook
根据目标行为决定类型：
- Validating Admission Webhook：用于“拒绝不符合规范”的请求。适合强制禁止 latest、拦截不可信仓库等场景。一旦任一校验失败，整个 API 请求被拒绝，Pod 不会创建。
-
Mutating Admission Webhook：用于“自动修正”请求。例如将
nginx:1.21自动补全为nginx:1.21.6（需有版本映射服务），或将无 digest 的镜像拉取策略从IfNotPresent强制改为Always。注意：Mutating Webhook 必须先于 Validating Webhook 执行，且不能在所有资源上都触发（需精确匹配rules）。
开发与部署 Webhook 服务
核心是实现一个 HTTPS 服务，能接收 AdmissionReview 请求并返回合规响应。关键点：
- 必须使用 TLS：Webhook 配置中指定的
caBundle是服务端证书的 CA 公钥 Base64 编码，API Server 用它验证服务身份 - 推荐用 Go 或 Python 实现（Kubernetes 官方 client 库支持完善），避免语言层 TLS 配置错误
- 对镜像字段解析要健壮：区分
image字符串中的 registry、repository、tag、digest（参考containers/image库的ParseNormalizedNamed） - 示例逻辑（Go 片段）：
if strings.HasSuffix(container.Image, ":latest") { reject("latest tag not allowed") }
注册并启用 Webhook 配置
通过 Kubernetes 原生资源注册，无需改动 apiserver 启动参数：
- 创建
ValidatingWebhookConfiguration或MutatingWebhookConfiguration资源 - 其中
webhooks[].clientConfig.service指向你部署的 Webhook Service（需在同一集群内，或通过 Ingress + TLS 终止暴露） - 设置
failurePolicy: Fail确保网络异常或 Webhook 故障时默认拒绝请求（生产环境强烈推荐） - 用
rules精确限定作用范围，例如只对core/v1, Kind=Pod的CREATE和UPDATE操作生效
不复杂但容易忽略的是：Webhook 的可用性直接影响集群稳定性。上线前务必做灰度测试，监控其延迟与拒绝率，并确保有应急绕过机制（如临时 patch webhook 配置的 failurePolicy: Ignore）。
