平台工程里的政策：少做关卡，多做护栏

2026年10月1日，CNCF Ambassador Koray Oksay 在 CNCF 博客写了平台政策系列第二篇，核心判断很干脆：很多平台团队嘴上说 guardrails（护栏），手里做的仍是 gates（关卡）；差别不在换词，而在开发者是绕开平台，还是愿意走平台。[1]

关卡心态从哪来

Kubernetes 生态里，最出名的 OPA 系工具就叫 Gatekeeper；Admission 控制器的动词是 block，策略语言里常见 deny；Kyverno 的 validationFailureAction: Enforce 听起来中性，失败形态仍是平台对开发者说「不行」。作者认为，这种命名反射出集体心智：把政策当成门禁。结果是熟悉的循环——平台先建起来，安全事后塞规则，开发者撞上看不懂的拦截，工单堆成申诉庭，有人再拉一套「临时」旁路集群，采用率反而掉下去。[1]

护栏和关卡差在提问方式

关卡默认关闭，成功指标是拦下了多少；护栏贴着路跑，成功时你几乎感觉不到它，只在快冲出路面时把你托回车道。换到平台团队的问题上：关卡派问「怎么拦下这次错误配置」；护栏派问「怎么让正确配置自动出现」。两套问题会做出完全不同的平台，也会塑造不同的平台—研发关系。[1]

政策引擎的四件事，哪些像护栏

作者沿用自己在 Kyverno / CEL 文中的四分法，并重新贴标签：[1]

1. 校验（validate）：仍可当护栏——同样拒绝，若错误信息写清「缺资源限制、该补哪段 YAML、为什么要」，体验就和冷冰冰的 Denied 不同。

2. 变更（mutate）：铺路。缺安全上下文就补默认值，Docker Hub 镜像改写到内网镜像，可观测标签自动注入。开发者写最小清单，平台静默补齐要求。

3. 生成（generate）：脚手架。新建命名空间时自动带上 NetworkPolicy、Quota、LimitRange、RoleBinding，「完工」的样子由平台先摆好。

4. 镜像校验（verify）：信任边界，这一项本来就偏硬关卡，作者认为应当故意保留，而不是默认姿势。

他观察到的反差是：多数 Kyverno / Gatekeeper 配置里约 90% 都在做校验；而开发者愿意用的平台，往往重 mutation / generation，校验只留给真正要硬答案的地方。[1]

组织上谁该拥有政策

关卡模型里，安全拥有政策、平台只负责执行，研发容易把平台看成远处规章的执法队。护栏模型里，平台团队拥有政策，安全是强硬且不可缺席的利益相关方：安全要的风险目标仍要达成，但错误信息、默认值、灰度节奏、例外流程，由更在乎研发体验的一方来设计。政策还应被当成产品——有版本、有用户、有废弃时间表，按 audit → warn → enforce 推进，例外变成可见、会过期的债务，而不是没人记得的永久豁免。[1]

一句话对照：关卡停住人，护栏帮人到达。盘点自己的策略 YAML 时，可以先数一数 mutation / generation 占比，再决定下一步是加一条拒绝规则，还是先把「正确默认」写进平台。

说明：概念梳理据 CNCF 博文，具体策略引擎选型与落地以各团队安全合规要求为准。

来源

[1] Guardrails, not gates: rethinking policy in platform teams，Koray Oksay，CNCF Blog，2026年10月1日。

#平台工程 #护栏 #Kyverno #Gatekeeper #策略 #科普解读