Kubernetes 准入控制器
Kubernetes 准入控制器 是什么?
Kubernetes 准入控制器准入控制器是 Kubernetes API server 的插件,在已认证的请求被持久化前进行拦截,按照策略对对象进行校验、变更或拒绝。
Kubernetes 准入位于 API server 请求流水线中,处于认证和授权之后,但在对象写入 etcd 之前。它按顺序分两个阶段运行:mutating 控制器可以改写对象(填充默认值、注入 Istio/Envoy sidecar),随后 validating 控制器接受或拒绝该对象。内置控制器包括 NamespaceLifecycle、ResourceQuota、ServiceAccount、PodSecurity 和 ImagePolicyWebhook。外部策略引擎注册为 MutatingWebhookConfiguration/ValidatingWebhookConfiguration,接收 AdmissionReview JSON 负载,并返回允许/拒绝的裁决——这就是 OPA Gatekeeper 和 Kyverno 的接入点。自 1.30(GA)起,ValidatingAdmissionPolicy 将 CEL 表达式直接嵌入 API server,省去了到 webhook 的网络跳转。
准入是供应链与工作负载策略的核心强制点:镜像签名验证(Sigstore/cosign)、Pod Security Standards 以及标签规范。这也使 webhook 本身成为攻击目标。2025 年 3 月的 IngressNightmare(CVE-2025-1974,CVSS 9.8,以及 CVE-2025-1097/1098/24514)让未认证的攻击者能够访问 ingress-nginx 的 admission 端点并注入 NGINX 指令,在控制器 Pod 中实现 RCE 并可能导致集群范围的机密窃取——这有力地提醒我们:准入端点绝不能暴露到网络上。
在运维方面,failurePolicy: Fail 搭配一个不可达的 webhook 可能会使集群瘫痪,因此要用 namespaceSelector 限定 webhook 的范围、设置较小的 timeoutSeconds,并排除 kube-system。
flowchart LR
U[kubectl / 客户端] --> API[API server]
API --> AUTHN[认证]
AUTHN --> AUTHZ[授权 RBAC]
AUTHZ --> MUT[Mutating 准入 -> 注入 / 默认值]
MUT --> SCH[Schema 与对象校验]
SCH --> VAL[Validating 准入 + VAP CEL]
VAL --> D{是否允许?}
D -->|拒绝| ERR[向客户端返回拒绝]
D -->|允许| ETCD[(Persist to etcd)]
VAL -.policy.-> ENG[OPA Gatekeeper / Kyverno]● 示例
- 01
mutating webhook 在带标签的命名空间中为每个新建 Pod 注入 Istio/Envoy sidecar。
- 02
ValidatingAdmissionPolicy 拒绝未设置 runAsNonRoot 的 Deployment。
● 常见问题
Kubernetes 准入控制器 是什么?
准入控制器是 Kubernetes API server 的插件,在已认证的请求被持久化前进行拦截,按照策略对对象进行校验、变更或拒绝。 它属于网络安全的 云安全 分类。
Kubernetes 准入控制器 是什么意思?
准入控制器是 Kubernetes API server 的插件,在已认证的请求被持久化前进行拦截,按照策略对对象进行校验、变更或拒绝。
如何防御 Kubernetes 准入控制器?
针对 Kubernetes 准入控制器 的防御通常结合技术控制与运营实践,详见上方完整定义。
Kubernetes 准入控制器 还有哪些其他名称?
常见的别称包括: Admission webhook, ValidatingAdmissionPolicy。