Gatekeeper中Dryrun模式与操作类型检查的注意事项

在Kubernetes策略管理工具Gatekeeper的实际使用过程中，开发人员可能会遇到一个典型场景：当约束策略中包含了针对操作类型（如CREATE、UPDATE）的条件检查时，Dryrun模式的审计功能将无法正常显示违规资源。这个现象背后涉及Gatekeeper审计机制与准入控制的关键差异。

核心问题分析

Gatekeeper的约束策略通过Rego语言编写，其中可以访问请求上下文中的operation字段来判断操作类型。在准入控制阶段（如webhook拦截CREATE/UPDATE请求时），这个字段会被正常填充。然而在审计模式下，Kubernetes原生机制无法提供操作类型信息，这直接导致包含操作类型检查的策略在审计时失效。

典型场景还原

假设我们有一个约束模板，要求特定资源必须包含CICD系统标注才能被创建或更新。策略中通过以下Rego代码检查操作类型：

allowed_operation := { "CREATE","UPDATE" }
operation := { input.review.operation }
continue_operation := allowed_operation & operation
count(continue_operation) > 0

当这个约束设置为Dryrun模式时，虽然预期会记录违规资源，但实际上审计结果为空。这是因为审计扫描现有资源时，input.review.operation字段为空，导致条件判断失败。

解决方案与最佳实践

1. 审计专用策略设计：如果需要审计功能，应避免在策略中依赖操作类型检查。可以将操作类型检查作为准入控制的专属逻辑。

2. 条件编译思路：通过注释区分不同执行场景的代码块，例如：

   # 准入控制专用检查
   # audit_mode := { "AUDIT" }
   # operation := { input.review.operation | "" }  # 空值处理
   

3. 字段存在性验证：在访问input.review前增加存在性检查，例如：

   has_field(review, "operation") {
     input.review.operation
   }
   

深层原理

这种现象源于Kubernetes审计机制的设计本质。审计是对集群现有状态的扫描，不携带操作上下文。而Gatekeeper的Dryrun模式本质上仍依赖审计机制来发现违规，因此继承了这种限制。理解这个原理有助于开发更健壮的策略逻辑。

总结

在Gatekeeper策略开发中，需要特别注意审计模式与准入控制模式的差异。对于需要同时支持两种场景的策略，建议将操作类型相关的检查作为可选逻辑，或通过单独的约束模板来实现。这也提醒我们，在编写策略时应该充分考虑不同执行上下文的环境差异。

通过这个案例，我们可以更深入地理解Gatekeeper的工作机制，避免在实际使用中陷入类似的陷阱。对于关键业务场景的策略，建议在测试环境中充分验证各种模式下的行为表现。