本文定位：面向需要把镜像来源、权限边界、资源配置、安全基线和合规要求前移到 Kubernetes 资源创建阶段的平台、安全和运维团队。
Kubernetes准入控制的价值，在于把“上线后发现问题”变成“进入集群前就阻断或修正”。当团队规模扩大后，平台很难靠人工审查每一份 YAML。Admission Webhook、内置 Admission Controller 和策略引擎可以在 API Server 接收请求时统一检查镜像、权限、标签、资源限制、命名空间边界和安全上下文。
如果你正在建设 Kubernetes 安全基线，可以先结合 Kubernetes审计日志配置 建立操作留痕，再用本文的准入策略把高风险配置前置拦截；敏感信息治理则可以参考 Kubernetes Secret管理 的权限和轮换思路。
准入控制处在 Kubernetes 请求链路的哪个位置
一次 Kubernetes 写请求进入 API Server 后，会经历认证、鉴权、准入控制、对象持久化等阶段。准入控制发生在认证和 RBAC 之后、对象写入 etcd 之前，因此它适合处理“已经有权限操作，但操作内容不符合平台策略”的问题。
它通常处理三类事情：
- 变更对象：Mutating Admission Webhook 可以补默认标签、注入 sidecar、设置安全上下文。
- 校验对象：Validating Admission Webhook 可以拒绝特权容器、未签名镜像、缺少资源限制的工作负载。
- 统一策略：策略引擎可以把镜像仓库、Namespace、资源配额和安全基线变成可复用规则。
图1：Kubernetes准入控制在API请求链路中的位置
内置 Admission Controller 与 Webhook 怎么分工
Kubernetes 内置了很多 Admission Controller，例如 NamespaceLifecycle、ResourceQuota、LimitRanger、PodSecurity 等。它们适合处理通用能力和 Kubernetes 自身已经定义好的规则。Admission Webhook 更适合企业自定义策略，例如镜像仓库白名单、标签规范、业务线命名约束和安全例外审批。
| 能力 | 更适合内置控制器 | 更适合 Webhook 或策略引擎 |
|---|---|---|
| 命名空间生命周期 | 是 | 否 |
| 资源配额与默认限制 | 是 | 可补充 |
| Pod 安全基线 | 是 | 可增强 |
| 镜像仓库白名单 | 否 | 是 |
| 业务标签规范 | 否 | 是 |
| 合规例外审批 | 否 | 是 |
不要把所有规则都塞进自研 Webhook
Webhook 很灵活，但也会引入可用性和维护成本。能用内置控制器稳定解决的，不要重复开发；需要跨业务、跨集群统一治理的，再引入策略引擎或 Webhook。
策略治理要先分级，而不是一次全拦截
很多准入控制失败，是因为一开始就把所有规则设置成强拒绝。结果测试环境、历史应用、第三方组件和临时修复都被卡住，业务团队很快会要求关闭策略。
更稳妥的策略分级是：
- 观察模式：只记录违规，不拦截，用于评估影响范围。
- 告警模式：对新增违规发通知，推动团队修复。
- 软阻断：只在高风险命名空间或新增应用中拒绝。
- 强阻断：对核心安全底线强制拒绝，例如特权容器、未授权镜像源。
准入策略上线不是单纯的技术动作，更像一次平台规则发布。每条规则都应说明目的、作用范围、例外流程和回滚方式。
图2：准入策略从观察到强阻断的上线阶梯
Admission Webhook 的可用性设计不能忽视
准入控制位于 API Server 写请求链路中，一旦 Webhook 不可用、超时或错误配置，可能影响工作负载创建、控制器更新甚至自动扩缩容。因此企业落地时必须设计故障兜底。
关键配置包括：
- failurePolicy：高风险安全底线可使用 Fail，非关键补充规则可考虑 Ignore。
- timeoutSeconds：超时时间要短，避免 API 请求被长时间阻塞。
- namespaceSelector：先限定范围，避免一条规则影响全站所有命名空间。
- objectSelector：对特定对象或标签生效，降低误伤面。
- matchPolicy：明确不同 API 版本匹配方式，避免升级后规则失效。
如果策略服务依赖外部系统，也要考虑外部系统不可用时是否会阻塞集群写入。准入控制的目标是降低风险，不是制造新的单点故障。
常见策略场景与落地方式
| 策略场景 | 检查点 | 建议动作 |
|---|---|---|
| 镜像来源治理 | 镜像仓库、tag、签名状态 | 先告警未授权仓库，再强制拒绝 |
| 安全上下文 | privileged、hostPath、root 用户 | 对高风险字段强阻断 |
| 资源规范 | requests、limits、探针 | 观察后按命名空间逐步强制 |
| 标签规范 | owner、app、env、cost-center | 可用 mutating webhook 补默认值 |
| 命名空间边界 | 租户、环境、系统命名空间 | 用 selector 缩小策略范围 |
策略要能解释，不能只返回“拒绝”
对应用团队来说，最糟糕的体验是提交资源后只看到一条模糊报错。准入策略返回信息应包含违规字段、原因、修复建议和例外申请入口。这样才能减少平台团队的人工解释成本。
图3：准入策略治理闭环
审计与回滚是准入策略的安全阀
准入控制需要和审计日志、变更管理、策略版本管理配套。否则一条错误规则上线后，团队很难判断它影响了哪些对象，也很难快速回退。
上线前至少检查：
- 规则版本：策略文件进入 Git，变更经过评审。
- 影响评估：观察模式下统计命中对象、命名空间和团队。
- 例外机制：明确哪些场景可临时放行，谁审批，何时过期。
- 回滚路径：策略服务、WebhookConfiguration 和策略文件都能快速回退。
- 审计留痕：每次拒绝、例外和策略变更都能追踪。
准入控制越靠近核心链路，越需要稳妥上线。强规则不是越多越好，而是要覆盖真正高风险、可解释、可执行的底线。
小结
Kubernetes准入控制是企业集群安全治理的重要前置关口。它能在资源写入前统一执行镜像、安全上下文、标签、资源和命名空间策略，但也会直接影响 API 写请求链路。落地时应先分清内置控制器和 Webhook 的职责，再用观察、告警、软阻断、强阻断逐步上线，并配套审计、例外和回滚机制。这样准入策略才能成为平台治理能力，而不是阻碍交付的黑盒规则。
FAQ
Kubernetes 准入控制和 RBAC 有什么区别？
RBAC 判断“谁能做这个操作”，准入控制判断“这个操作的内容是否符合策略”。一个用户可能有创建 Pod 的权限，但准入控制仍可拒绝特权容器、未授权镜像源或缺少资源限制的 Pod。
Admission Webhook 会不会影响集群稳定性？
会有影响，所以必须谨慎设计。Webhook 位于 API 写请求链路中，如果服务不可用或超时，可能阻塞资源创建。建议先限定命名空间范围、设置合理 timeout，并按规则重要性选择 failurePolicy。
准入策略应该先拦截哪些问题？
建议先拦截高风险且容易解释的问题，例如特权容器、hostPath 滥用、未授权镜像仓库、生产命名空间缺少必要标签。资源 requests/limits、标签规范等可以先观察再逐步强制。
OPA、Kyverno 和自研 Webhook 怎么选？
如果团队希望用声明式策略、减少自研维护成本，可以优先评估成熟策略引擎；如果需要强业务定制或接入内部审批系统，自研 Webhook 更灵活，但要承担可用性、升级和安全维护成本。
权威参考资料
- Kubernetes Admission Controllers
- Kubernetes Dynamic Admission Control
- Kubernetes Pod Security Admission
