3. 策略执行引擎介绍：OPA/Gatekeeper、Kyverno、KubeArmor 的原理与对比

在云原生环境中，策略执行引擎是保障集群安全与合规的核心组件。本章深入分析三种主流引擎——OPA/Gatekeeper、Kyverno 和 KubeArmor——的工作原理、架构差异及适用场景，帮助运维人员在基线核验与故障排查中精准定位策略执行异常。

3.1 OPA / Gatekeeper：策略即代码的先行者

Open Policy Agent (OPA) 是一个通用的策略引擎，使用 Rego 声明式语言定义策略。Gatekeeper 是 OPA 在 Kubernetes 上的集成实现，以 Admission Webhook 的形式拦截资源创建/更新请求。

关键组件

• OPA 引擎： 负责执行 Rego 策略，返回决策结果（allow/deny）。
• Gatekeeper 控制器： 管理 ConstraintTemplate 和 Constraint 的生命周期，将策略同步到 OPA。
• Admission Webhook： 拦截 Kubernetes API 请求，转发给 OPA 评估。
• 审计功能： 定期扫描集群现有资源，标记违反策略的对象。

典型故障场景

故障现象	可能原因	排查方向
策略未生效	ConstraintTemplate 未安装或 Rego 语法错误	检查 kubectl get constrainttemplates 状态
误拦截合法请求	Rego 规则过于宽泛或逻辑错误	使用 opa eval 本地测试策略
审计结果不一致	OPA 缓存与集群状态不同步	重启 gatekeeper-controller-manager Pod

3.2 Kyverno：Kubernetes 原生的策略引擎

Kyverno 专为 Kubernetes 设计，使用 YAML 定义策略，无需学习新语言。它支持 validate（验证）、mutate（变更）和 generate（生成）三种策略类型，同时具备后台扫描能力。

策略类型对比

类型	作用时机	典型用途	示例
validate	Admission 阶段	强制标签、限制特权容器	拒绝 privileged: true
mutate	Admission 阶段	自动注入 Sidecar、添加默认标签	自动添加 app.kubernetes.io/name
generate	资源创建后	自动创建 NetworkPolicy、Quota	为每个 Namespace 生成默认 LimitRange

故障排查要点

• 策略未触发： 检查 match 和 exclude 条件是否正确，使用 kubectl describe policy 查看状态。
• Mutate 冲突： 多个 mutate 策略可能产生冲突，Kyverno 按策略创建顺序执行，使用 spec.background: false 控制后台扫描。
• 性能问题： 大量策略或复杂正则表达式可能导致 Admission 延迟，建议使用 preconditions 提前过滤。

3.3 KubeArmor：内核级运行时安全

KubeArmor 基于 eBPF 和 LSM (Linux Security Modules) 实现，在操作系统内核层拦截系统调用，提供容器粒度的运行时安全策略。与 OPA/Gatekeeper 和 Kyverno 不同，KubeArmor 不依赖 Admission Webhook，而是直接监控和阻断进程、文件、网络行为。

KubeArmorPolicy (KSP) 结构

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: block-write-etc
spec:
  severity: high
  selector:
    matchLabels:
      app: sensitive-app
  process:
    matchPaths:
      - path: /usr/bin/wget
      - path: /usr/bin/curl
    action: Block
  file:
    matchDirectories:
      - dir: /etc/
        recursive: true
    action: Block
  network:
    matchProtocols:
      - protocol: tcp
    action: Audit

三种引擎核心对比

维度	OPA / Gatekeeper	Kyverno	KubeArmor
执行层	Admission Webhook (API 层)	Admission Webhook + 后台扫描	内核 eBPF / LSM (系统调用层)
策略语言	Rego	YAML (无新语言)	YAML (KubeArmorPolicy)
作用时机	资源创建/更新前	资源创建/更新前 + 运行时扫描	运行时持续监控
主要能力	合规验证、资源约束	验证、变更、生成、扫描	进程/文件/网络阻断与审计
适用场景	多集群策略统一管理	Kubernetes 原生策略快速落地	运行时安全、零信任执行
故障排查难点	Rego 调试复杂、审计延迟	Mutate 冲突、后台扫描性能	内核兼容性、eBPF 事件丢失

3.4 选型建议与故障排查策略

故障排查通用步骤

1. 确认策略状态： 使用 kubectl get 查看策略资源是否正常创建，检查 Controller 日志。
2. 验证策略语法： OPA 使用 opa eval 本地测试；Kyverno 使用 kyverno test；KubeArmor 使用 karmor logs 查看实时事件。
3. 检查执行日志： 定位 Admission Webhook 日志（OPA/Kyverno）或 eBPF 事件日志（KubeArmor）。
4. 测试最小策略： 创建最小化策略排除干扰，逐步增加规则复杂度。
5. 监控性能指标： 关注 Admission 延迟、策略评估次数、eBPF 事件丢失率。