## 一、准入是唯一能看到对象内容的一关

![adm-1-boundary.png](https://developer.qcloudimg.com/http-save/yehe-11479707/1e86371a285051e9e38438eb39385c01.png)

*图 1：认证看凭证，鉴权看请求属性，准入看完整对象——这条边界决定了策略该写在哪一层。*

| 阶段 | 拿到什么 | 能判断什么 |
| --- | --- | --- |
| 认证 | 凭证 | 你是谁 |
| 鉴权 | `user.Info` + 请求属性（verb / resource / namespace / name） | 你能不能做这个动作 |
| **准入** | **完整对象 + oldObject + operation + dryRun** | **这次改动的具体内容合不合规** |

准入发生在对象反序列化、默认值填充之后，写 etcd 之前。所以它能看到 `spec.containers[0].image`、`securityContext`、`resources.requests` 这些字段——鉴权层永远看不到。

这也决定了它的定位：**鉴权回答"能不能做"，准入回答"做成这样行不行"**。

## 二、为什么鉴权不够用

五个真实场景，全部只能由准入解决：

1. **镜像来源**：鉴权允许你 create pod，但管不了你的镜像是 `nginx` 还是 `evil.registry/x`。
2. **配额**：要算这个 Pod 的 requests 总和，必须先看到对象。
3. **安全基线**：`privileged: true`、`hostPath`、`hostNetwork` 这些字段，都是内容层面的判断。
4. **默认值**：你没写 `resources.limits`、没写 `imagePullSecrets`、没写 tolerations——得有人补。
5. **不可变字段**：更新时对比 oldObject 和 newObject，比如禁止改 `spec.nodeName`。

## 三、Mutating 与 Validating：顺序不能反

![adm-2-order.png](https://developer.qcloudimg.com/http-save/yehe-11479707/231035084c3c9cd8dad1a2e0c36afb52.png)

*图 2：改完之后的形态，才是被校验的形态。*

```
解码 + 默认值 → Mutating 准入 → 字段校验 → Validating 准入 → 写 etcd
```

**为什么 mutating 必须在前？**
因为它会改对象。改完之后的形态才是要校验的形态。如果反过来，校验看到的是"改之前"的版本，等于没校验。

**为什么 validating 必须在后？**
它只能看、不能改，所以必须看到最终形态。

这里有个很多人不知道的事实：**你 Pod 里的一些字段，是准入插件悄悄加的**。

| 内置插件 | 类型 | 干了什么 |
| --- | --- | --- |
| ServiceAccount | mutating | 挂载 token volume、设置 `imagePullSecrets`、处理 `automountServiceAccountToken` |
| LimitRanger | mutating + validating | 给没写 requests/limits 的容器补默认值，同时校验是否越界 |
| DefaultTolerationSeconds | mutating | 加 `not-ready` / `unreachable` 的默认容忍 |
| PriorityClass | mutating | 把 `priorityClassName` 解析成 `priority` 数值 |
| DefaultStorageClass | mutating | 给没写 storageClassName 的 PVC 补默认值 |
| ResourceQuota | validating | 检查命名空间配额 |
| PodSecurity | validating | 按 namespace 的 label 执行 PSS 基线 |
| NamespaceLifecycle | validating | 阻止往正在删除的 namespace 写对象 |

所以 `kubectl get pod -o yaml` 里那些你没写过的字段，一大半是准入补的。

## 四、Webhook：把准入做成可编程

![adm-3-webhook.png](https://developer.qcloudimg.com/http-save/yehe-11479707/7b4a97779bdcf75f26e7767964904cfb.png)

*图 3：一次同步调用；超时走 failurePolicy，而默认值是 Fail。*

内置插件覆盖不到的，用 webhook。API Server 会发一个 `AdmissionReview` 过去：

```yaml
# 请求（简化）
kind: AdmissionReview
request:
  uid: 705ab4f5-6393-11e8-b7cc-42010a800002
  operation: CREATE
  kind: {group: "", version: "v1", kind: "Pod"}
  resource: {group: "", version: "v1", resource: "pods"}
  namespace: prod
  userInfo: {username: "alice", groups: ["system:authenticated"]}
  object: {...完整的 Pod...}
  oldObject: null
  dryRun: false
```

```yaml
# 响应（简化）
response:
  uid: 705ab4f5-...
  allowed: false
  status: {message: "image must come from registry.corp.com"}
  patch: "W3sib3AiOiJyZXBsYWNlIi..."   # 仅 mutating 用，JSONPatch 的 base64
  patchType: JSONPatch
```

关键字段和它们的默认值，决定了这个 webhook 在故障时的行为：

| 字段 | 默认 | 含义 |
| --- | --- | --- |
| `failurePolicy` | **Fail** | webhook 不可达时，请求直接失败 |
| `timeoutSeconds` | 10（上限 30） | 超时即按 failurePolicy 处理 |
| `sideEffects` | 必填 | `None` / `NoneOnDryRun`，dry-run 时不能有副作用 |
| `matchPolicy` | Equivalent | 注册了 `apps/v1` 也匹配等价的旧版本 |
| `reinvocationPolicy` | Never | 其他 webhook 又改了对象时，要不要再调一次 |
| `namespaceSelector` / `objectSelector` | 空 | 缩小匹配范围 |

**排序规则**：同一阶段内，webhook 按**名字的字典序**执行。所以 `00-global.` 开头的会比 `zz-` 先跑，命名本身就是排序手段。内置插件和 webhook 在同一个有序链里，mutating webhook 排在内置 mutating 插件之后。

## 五、失败语义：webhook 是集群级单点

`failurePolicy` 默认是 `Fail`，意味着：**你的 webhook 服务挂了，所有匹配它的写请求都会失败**。

这是很典型的事故画面：

```
Error from server (InternalError): Internal error occurred:
failed calling webhook "policy.example.com": Post "https://policy...":
context deadline exceeded
```

所有 Deployment、Pod 创建全部超时，集群看起来"挂了"，但其实是准入在等一个不存在的服务。

设计建议：

- 能在 `rules` 里缩小的范围就别用 `*`；
- 能用 `namespaceSelector` 排除 `kube-system` 就排除；
- 对非关键策略用 `failurePolicy: Ignore` + 告警，而不是 Fail；
- webhook 服务本身要有 PDB、要多副本、要独立于业务命名空间。

## 六、从 webhook 到内置策略：PSA 与 VAP

webhook 的问题不只是可用性，还有**性能**和**可审计性**：每个写请求多一次网络调用，策略逻辑藏在集群外，审计日志里只看到"某个 webhook 拒了"。

所以出现了两次"收编"：

**PodSecurity Admission（1.23 beta / 1.25 GA）**：把最常用的安全基线做成内置插件，按 namespace 的 label 执行，不再需要部署一个 webhook。

**ValidatingAdmissionPolicy（1.26 alpha / 1.28 beta / 1.30 GA）**：用 CEL 表达式写校验，编译进 apiserver，零网络调用：

```yaml
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
spec:
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      resources: ["pods"]
      operations: ["CREATE", "UPDATE"]
  validations:
  - expression: "object.spec.containers.all(c, !c.image.endsWith(':latest'))"
    message: "不允许使用 :latest 标签"
```

这是趋势：**能用内置表达的策略，就不要用 webhook**。1.32 起 `MutatingAdmissionPolicy` 也进入 alpha，补上了"改对象"那一半。

## 七、配额不是事务

ResourceQuota 是 validating 准入，但它用的是 informer 缓存 + 乐观更新，不是事务。并发创建时，可能短暂超过配额，靠 controller 事后修正。

理解这一点很重要：**准入保证的是"单次请求看起来合规"，不是"全局永远不超"**。所有依赖强一致的计数，都不能只靠 quota。

## 八、版本时间线

| 时间 | 版本 | 变化 |
| --- | --- | --- |
| 2015 | 1.0 | 内置准入插件 |
| 2017 | 1.8 / 1.9 | Mutating / Validating Admission Webhook alpha |
| 2018 | 1.10 | `--admission-control` 改名 `--enable-admission-plugins` |
| 2019 | 1.16 | `admissionregistration.k8s.io/v1` GA |
| 2021 | 1.23 | PodSecurity Admission beta |
| 2022 | 1.25 | PSA GA |
| 2022 | 1.26 | ValidatingAdmissionPolicy alpha |
| 2023 | 1.28 | VAP beta |
| 2024 | 1.30 | VAP GA |
| 2024 | 1.32 | MutatingAdmissionPolicy alpha |

## 九、排障清单

| 现象 | 先查什么 |
| --- | --- |
| 所有写请求超时 | `kubectl get mutatingwebhookconfigurations` / `validatingwebhookconfigurations`，看 rules 和 service |
| `failed calling webhook ... context deadline exceeded` | webhook 服务不可达、证书过期、网络策略拦截 |
| `admission webhook denied the request: ...` | 这是策略主动拒绝，看 message |
| dry-run 报 `sideEffects` 相关错误 | webhook 没声明 `sideEffects: None / NoneOnDryRun` |
| 对象莫名其妙多了字段 | 内置 mutating 插件或 mutating webhook 改的，用 `--v=6` 看审计 |
| VAP 不生效 | 检查 `policyName` 绑定、`matchConstraints`、以及 CEL 编译错误 |

## 十、设计追问

**1. 为什么分 mutating 和 validating 两个阶段？**
因为"能改"和"只能看"是两种权限。分开之后，validating 插件可以被信任为"不会篡改数据"，审计也清晰：谁改了、谁拒了。

**2. 为什么 webhook 是同步阻塞的？**
因为准入的结果决定这次写要不要落库。异步就等于"先写再撤销"，那会破坏 etcd 的一致性保证。

**3. 为什么 failurePolicy 默认 Fail？**
安全默认值：策略不知道是否满足时，宁可拒绝。代价是可用性——所以生产上要根据策略的关键程度显式选择。

**4. 为什么还要 VAP，webhook 不够吗？**
webhook 有三次成本：网络往返、外部服务可用性、策略逻辑不可审计。VAP 把"看字段"的规则编译进 apiserver，用 CEL 表达，零调用、可版本化、审计可见。

**5. 为什么准入不能改 status？**
主资源和 status 子资源是分开鉴权的。准入能改对象，但改 status 需要单独的更新路径——否则一个 mutating webhook 就能伪造控制器状态。

---

**一句话收尾**：认证回答"你是谁"，鉴权回答"你能不能做"，准入回答"做成这样行不行"。前两关只看请求，第三关才看内容——所以它是策略的最后一公里，也是可用性风险最集中的地方。

---

## 参考资料

1. Kubernetes 官方文档：[Using Admission Controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)、[Validating Admission Policy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/)
2. Kubernetes 源码（v1.34.0）：`staging/src/k8s.io/apiserver/pkg/admission/`、`staging/src/k8s.io/api/admissionregistration/v1/types.go`
3. KEP：ValidatingAdmissionPolicy、MutatingAdmissionPolicy、PodSecurity Admission

> 本文为原创内容，基于 Kubernetes v1.34.0 源码整理；版本号以对应 release note 为准。

图 1：认证看凭证，鉴权看请求属性，准入看完整对象——这条边界决定了策略该写在哪一层。

kubernetes 进阶知识-API Server 准入：策略的最后一公里

认证回答"你是谁"，鉴权回答"你能不能做"，准入回答"做成这样行不行"。
前两关只看请求，第三关才看内容——所以镜像来源、安全基线、配额、不可变字段，全都压在这一关。它也是这三关里可用性风险最集中的地方：一个 webhook 挂掉，可能让整个集群写不进去。源码引用基于 Kubernetes v1.34.0。

运维开发工程师

运维

Kubernetes准入控制是安全策略的最后一公里，覆盖认证与鉴权无法触及的完整对象校验场景。本文解析准入如何看见Pod镜像、配额、安全基线等字段，区分Mutating与Validating阶段顺序，并详解Webhook的故障语义、PSA与VAP内置化趋势及排障清单，助你精准设计集群策略。

代码解释

Kubernetes

容器

Nginx

4核4G3M云服务器 新用户低至38元/年！

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

kubernetes 进阶知识-API Server 准入：策略的最后一公里-腾讯云开发者社区-腾讯云

kubernetes 进阶知识-API Server 准入：策略的最后一公里

kubernetes 进阶知识-API Server 准入：策略的最后一公里

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐