策略即代码在准入控制环节的落地，本质是把安全与合规规则写成可执行代码，通过Kubernetes准入控制器在资源真正落库前自动拦截违规请求。 云原生环境里手工检查YAML的日子已经跟不上节奏,策略即代码让规则从会议纪要变成集群里的硬约束。
策略即代码是什么意思：准入控制为什么需要它
策略即代码（Policy as Code，PaC）不是新概念，但放到Kubernetes准入控制环境里，它指的是一种明确的工作方式：用版本化的代码表达“集群允许创建什么、拒绝什么”,而不是依赖人工评审或文档约定。
准入控制器的触发位置
Kubernetes API Server收到创建、更新、删除请求后，会经过认证、授权，然后进入准入控制阶段,准入控制器分两类：
- 变更型（Mutating）：先修改请求内容,例如注入Sidecar。
- 验证型（Validating）：只检查是否合规,不合规直接拒绝。
策略即代码主要落地在验证型准入控制器，也能配合变更型做默认值修正，这样规则在资源写入etcd前生效，不会留下“先违规后整改”的空窗。
传统手工审批为什么撑不住
- 集群资源数量暴增,靠人看YAML容易漏。
- 合规要求变化快,文档更新跟不上实际。
- 开发与运维对“安全”理解不一致,口口相传产生偏差。
把策略写进代码后，每次资源请求都会经过同一套判断逻辑，结果可预测、可回放。
Kubernetes准入控制最佳实践：先选对执行引擎
Kubernetes原生只提供Admission Webhook接口，不负责规则语言本身，真正落地时通常要接一个策略引擎，行业共识认为，选择策略引擎不能只看功能多少,还要看团队现有技术栈和维护成本。
常见的两种路线
- OPA Gatekeeper：用Rego语言写规则，生态成熟,适合复杂策略。
- Kyverno：用Kubernetes风格的YAML写策略，学习门槛低,适合以平台团队为主的场景。
Kyverno和OPA对比：一张表看懂差异
| 对比维度 | OPA Gatekeeper | Kyverno |
|---|---|---|
| 规则语言 | Rego，偏函数式，有一定学习曲线 | YAML，接近Kubernetes资源写法 |
| 审计能力 | 通过Constraint和审计结果查看 | 原生支持PolicyReport |
| 变更能力 | 以验证为主，变更需额外配置 | 原生支持mutate和generate |
| 资源开销 | 较多组件，适合大规模统一治理 | 单组件，部署简单 |
| 适合团队 | 有平台工程能力，需要复杂策略 | 运维与开发协作，追求上手速度 |
这张表不是绝对优劣，多数情况下取决于你是否愿意维护Rego代码库，如果团队里没人熟悉Rego，Kyverno更省心；如果已有OPA生态或需要跨系统复用策略,Gatekeeper更适合。
策略即代码落地案例：一条禁止特权容器的规则
下面以Kyverno为例，展示一条“禁止创建特权容器”的ClusterPolicy，这个策略直接落在准入控制环节,任何Pod请求都会被检查。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: no-privileged-containers
spec:
validationFailureAction: Enforce
background: true
rules:
- name: reject-privileged
match:
any:
- resources:
kinds:
- Pod
validate:
message: "特权容器被禁止创建"
deny:
conditions:
any:
- key: "{{ request.object.spec.containers[].securityContext.privileged }}"
operator: AnyIn
value: true
执行部署：
kubectl apply -f no-privileged-containers.yaml
部署后测试：
kubectl run test-pod --image=nginx --privileged
请求会被拒绝，返回策略中定义的message，这个例子不需要懂Rego，规则本身就是Kubernetes YAML,正好说明策略即代码不一定等于重学一门语言。
用OPA表达同样规则时为什么更绕
如果用OPA Gatekeeper，需要先写ConstraintTemplate定义Rego逻辑，再写Constraint绑定资源范围，步骤更多，但换来的是对复杂条件、跨字段判断更强的控制力，只允许来自指定镜像仓库且tag不为latest”，Rego写起来更直接，选择哪种,取决于规则复杂度而不是流行度。
准入控制器怎么配置：从部署到验证的路径
很多团队卡在“准入控制器怎么配置”这一步，不是因为原理难，而是没有把部署、接入、回滚串成一条可验证的链路。
分步操作
- 先确定策略引擎与Kubernetes版本兼容，不同引擎对Kubernetes API版本要求不同,部署前先查官方兼容表。
- 安装引擎到集群，Kyverno通常用Helm一条命令安装，OPA Gatekeeper也提供官方清单或Helm。
- 先开审计模式，把validationFailureAction设为Audit，让策略只记录不拦截,观察几天误报率。
- 逐步切换到强制模式，对核心命名空间先放行，仅对测试命名空间Enforce,稳定后再扩大范围。
- 接入GitOps流程，策略YAML放入Git仓库，通过Argo CD或Flux同步,改策略必须走代码评审。
验证与回滚
- 用kubectl dry-run模拟请求,不要拿真实业务做实验。
- 保留上一个版本策略，出问题时直接回滚Git提交,比手动改集群更快。
- 检查PolicyReport或审计日志,确认拒绝原因与预期一致。
配置到位后，准入控制器就是一条稳定流水线,而不是偶尔上线围观的门卫。
策略即代码落地时容易踩的三个坑
策略即代码落地案例看着简单，实际放进生产环境会遇到不少具体场景问题,以下三个坑来自常见团队实践。
只拦Pod不拦更高层资源
不少团队在策略里只匹配Pod，却漏掉Deployment、StatefulSet、Job等资源，攻击者或误操作通过Deployment创建Pod时，可能绕过直接针对Pod的拦截，正确做法是把策略绑定到更高层资源，或要求引擎对Pod所有者进行追溯审计，Kyverno支持match资源为Pod，但有些场景需要同时处理控制器,OPA则需要明确match所有相关Kind。
把Audit当成Enforce
Audit模式只记录违规不阻止创建，容易造成“已经生效”的错觉，一定要在测试命名空间验证Enforce，确认API Server确实返回拒绝，而不是只看日志，这个坑在“准入控制器怎么配置”的搜索里经常被忽略。
策略没有版本管理
直接kubectl apply到集群的策略，时间一长没人知道谁改了什么，策略即代码的价值有一半在版本管理和评审流程，策略文件不进Git，回滚和审计都无从谈起，把策略变更纳入CI，跑一些基础YAML用例验证拒绝逻辑,能减少策略漂移。
策略即代码在准入控制环节的落地不是装一个工具就结束，而是把安全规则从口头约束变成可执行、可评审、可回滚的工程资产，选对策略引擎、先审计后强制、覆盖全资源类型，这三点做到位,准入控制才会从纸面要求变成集群的默认行为。
策略即代码在准入控制环节怎么落地？
先确定要治理的对象，例如Pod安全、镜像来源、资源配额，再选择一个策略引擎写入规则，先在Audit模式运行观察，没有误伤后切到Enforce，规则文件放进Git仓库，通过CI或GitOps部署,最终用kubectl测试请求验证准入控制器确实返回拒绝。
准入控制器怎么配置才能不误伤业务？
从Audit开始，只对测试命名空间做强约束，策略里写清楚排除项，例如kube-system、基础设施组件所在命名空间，上线前用dry-run模拟资源请求，检查审计日志，保留旧策略版本，一旦出现大量拒绝,先回滚策略提交而不是紧急放宽规则。
Kyverno和OPA对比后选哪个更省心？
如果团队以YAML和Kubernetes为主，不熟悉函数式编程，Kyverno上手成本更低，原生mutate和generate能力让策略更贴近运维语言，如果需要跨平台复用策略、处理复杂条件组合，OPA的Rego表达力更强，没有绝对答案,多数集群从Kyverno起步即可覆盖常见安全需求。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/641636.html
