📚 课程目录第2章 OPA与Gatekeeper基础

2. OPA 与 Gatekeeper 基础：OPA 架构、Rego 语言简介、Gatekeeper 在 K8s 中的角色

在构建云原生策略引擎时，OPA（Open Policy Agent）与 Gatekeeper 是当前 Kubernetes 生态中最主流的组合。本章从 OPA 的通用架构出发，逐步深入到 Rego 语言的策略编写范式，最后阐明 Gatekeeper 如何将 OPA 的能力无缝嵌入 Kubernetes 的准入控制链路。

2.1 OPA 架构：策略决策与数据解耦

OPA 是一个通用的、轻量级的策略引擎，其核心设计理念是将策略决策与业务逻辑完全解耦。OPA 本身不负责执行任何业务操作，它只回答一个问题：“这个请求是否被允许？”

  核心架构组件：
  Policy（策略）：使用 Rego 语言编写的规则集合，定义了“允许”或“拒绝”的逻辑。
Data（数据）：OPA 加载的 JSON 文档，可以是集群状态、用户属性、外部配置等。
Input（输入）：每次策略评估时传入的临时请求数据，例如一个 Pod 的创建请求。
Decision（决策）：OPA 根据 Policy + Data + Input 计算出的结果，通常为 allow 或 deny。

2.2 Rego 语言简介：声明式策略编写

Rego 是 OPA 的原生查询语言，专为声明式策略设计。它借鉴了 Datalog 的逻辑编程思想，允许你以“如果…那么…”的规则形式描述策略，而无需编写命令式的 if-else 分支。

2.2.1 基本语法与规则

一个 Rego 规则由头部和主体组成。头部定义规则名称，主体包含逻辑条件。当主体中的所有条件都为真时，规则被满足。

# 示例：禁止使用 latest 标签的容器镜像
package k8s.images

deny[msg] {
    input.request.operation == "CREATE"
    image := input.request.object.spec.containers[_].image
    endswith(image, ":latest")
    msg := sprintf("容器镜像 %v 禁止使用 latest 标签", [image])
}

关键语法要点：

包（package）：用于组织规则，避免命名冲突。
迭代（[_]）：下划线通配符用于遍历数组或集合。
变量绑定（:=）：将表达式结果赋值给局部变量。
消息构造（sprintf）：用于生成可读的拒绝原因。

2.2.2 数据查询与聚合

Rego 支持对嵌套 JSON 数据进行深度查询，并内置了丰富的聚合函数，如 count、sum、any、all 等。

# 查询所有使用了 hostNetwork 的 Pod
violation[msg] {
    pod := input.request.object
    pod.spec.hostNetwork == true
    msg := sprintf("Pod %v 不允许使用 hostNetwork", [pod.metadata.name])
}

2.2.3 规则类型对比

规则类型	关键字	返回值	典型用途
完整规则	`allow := true`	单个布尔值	全局允许/拒绝
部分规则	`deny[msg]`	集合	收集所有违规消息
函数规则	`is_privileged(container)`	自定义计算	复用复杂逻辑
默认规则	`default allow = false`	默认值	白名单/黑名单模式

2.3 Gatekeeper 在 K8s 中的角色：策略即代码

Gatekeeper 是 OPA 在 Kubernetes 生态中的原生集成方案，它通过 Admission Webhook 和 CRD（Custom Resource Definition） 将 OPA 的策略管理能力标准化。Gatekeeper 本身不是一个独立的策略引擎，而是 OPA 的 Kubernetes 适配器。

2.3.1 Gatekeeper 的核心组件

组件	类型	职责
ConstraintTemplate	CRD	定义 Rego 策略模板，描述“做什么检查”
Constraint	CRD 实例	实例化模板，指定“对哪些资源生效”
Gatekeeper Webhook	Deployment	接收 API Server 的 AdmissionReview 请求
OPA Sidecar	容器	内嵌 OPA 引擎，执行 Rego 策略评估

2.3.2 策略生命周期管理

Gatekeeper 将策略管理提升为声明式操作。运维人员只需通过 kubectl apply 创建或更新 ConstraintTemplate 和 Constraint 资源，即可动态调整集群的准入策略，无需重启任何组件。

注意：Gatekeeper 默认只拦截 CREATE 和 UPDATE 操作。如果需要校验 DELETE 或其他操作，需要在 Constraint 中显式配置 match 字段的 operations 列表。

2.3.3 OPA 与 Gatekeeper 的职责边界

维度	OPA	Gatekeeper
定位	通用策略引擎	K8s 原生策略控制器
策略语言	Rego	Rego（通过 ConstraintTemplate）
数据源	任意 JSON 数据	K8s 集群状态 + 外部数据
部署方式	独立服务 / Sidecar	Admission Webhook + CRD
策略分发	API / 文件加载	kubectl apply CRD
审计模式	需自行实现	内置审计（Audit）功能

通过以上架构与角色分析，可以清晰地看到：OPA 提供了强大的策略计算能力，而 Gatekeeper 则将这些能力以 Kubernetes 原生的方式暴露给集群管理员。在下一阶段，我们将基于此基础，深入探讨如何利用 Gatekeeper 对 CRD 资源变更进行精细化策略校验。