3. OPA 与 Gatekeeper 介绍
在 Kubernetes 集群中实施细粒度的准入控制，需要一种能够将策略决策与策略执行分离的通用框架。OPA（Open Policy Agent）正是为此而生，而 Gatekeeper 则是 OPA 在 Kubernetes 生态中的原生集成方案。本节将系统介绍 OPA 的核心概念、Rego 策略语言基础以及 Gatekeeper 的项目架构。
3.1 OPA（Open Policy Agent）简介
OPA 是一个开源的、通用策略引擎，它将策略决策从软件的业务逻辑中解耦出来。无论你的服务是微服务、CI/CD 流水线还是 Kubernetes 集群，OPA 都能提供统一的策略即代码（Policy as Code）能力。
OPA 的关键特性
| 特性 | 说明 |
|---|---|
| 策略即代码 | 使用声明式语言 Rego 编写策略，支持版本控制、测试和自动化部署。 |
| 上下文感知 | 决策不仅依赖请求本身，还可以查询外部数据（如集群状态、用户属性）。 |
| 高性能 | 支持策略预编译和缓存，单次决策延迟通常在微秒级。 |
| 平台无关 | 可作为 Sidecar、库或独立服务运行，与 Kubernetes、Envoy、Kafka 等集成。 |
| 细粒度控制 | 支持 allow/deny、mutate（修改请求）、warn（告警）等多种决策类型。 |
3.2 Rego 语言概述
Rego 是 OPA 的专用查询语言，灵感来源于 Datalog。它是一种声明式语言，意味着你只需要描述“策略应该是什么”，而不需要描述“如何实现策略”。Rego 的核心是规则（Rules）和查询（Queries）。
Rego 基础语法
- 包（Package）： 每个 Rego 文件以
package关键字开头，用于组织策略。 - 规则（Rule）： 使用
rule_name { condition }定义，条件为真时规则成立。 - 默认值（Default）： 使用
default allow = false设置规则的默认值。 - 迭代（Iteration）： 使用
some关键字遍历集合或数组。 - 内置函数： 提供
count()、split()、regex.match()等丰富函数。
latest 标签。
package kubernetes.admission
import data.kubernetes.namespaces
# 默认拒绝所有请求
default deny = false
# 定义拒绝规则：如果任何容器镜像标签为 "latest"，则拒绝
deny[msg] {
input.request.kind.kind == "Pod"
some container in input.request.object.spec.containers
endswith(container.image, ":latest")
msg := sprintf("容器 %v 使用了禁止的 latest 标签", [container.name])
}Rego 与 JSON 的交互
Rego 原生支持 JSON 数据结构。OPA 将输入（Input）和外部数据（Data）都视为 JSON 文档，Rego 规则通过点号（.）或方括号（[]）访问这些文档的字段。
| 概念 | Rego 表示 | 说明 |
|---|---|---|
| 输入 | input.request.object.metadata.name |
访问被审查的 K8s 资源名称 |
| 数据 | data.kubernetes.namespaces |
访问集群中的命名空间列表 |
| 迭代 | some container in input.request.object.spec.containers |
遍历 Pod 中的所有容器 |
| 集合操作 | { "a", "b" } == { "b", "a" } |
集合无序比较，结果为 true |
some 关键字显式声明迭代变量。
3.3 Gatekeeper 项目架构
Gatekeeper 是 OPA 在 Kubernetes 生态中的官方集成项目，由 Google 和微软联合维护，现为 CNCF 毕业项目。它将 OPA 作为准入 Webhook 部署在集群中，并通过 CRD（Custom Resource Definition）提供声明式的策略管理接口。
核心组件
- Gatekeeper Controller： 管理 CRD 资源（ConstraintTemplate、Constraint），并负责 OPA 策略的生命周期。
- OPA Sidecar： 与 Controller 同 Pod 运行，提供策略评估引擎。
- Admission Webhook： 注册到 API Server，拦截
CREATE、UPDATE等操作。 - Audit 组件： 定期对集群中已有资源进行策略合规性检查，生成审计结果。
Gatekeeper 架构图
关键 CRD 资源
| CRD 名称 | 作用 | 示例 |
|---|---|---|
| ConstraintTemplate | 定义 Rego 策略模板，描述“如何检查” | K8sRequiredLabels 模板检查必填标签 |
| Constraint | 实例化模板，定义“检查什么”和“参数” | required-labels-prod 约束要求生产命名空间必须有 env: prod 标签 |
| Config | 配置 Gatekeeper 的全局行为，如排除特定命名空间 | 排除 kube-system 命名空间 |
Gatekeeper 与原生 OPA 的对比
| 维度 | 原生 OPA | Gatekeeper |
|---|---|---|
| 部署方式 | 需手动部署 OPA 服务并配置 Webhook | Operator 模式，一键部署，自动配置 Webhook |
| 策略管理 | 通过 ConfigMap 或 API 管理策略 | 通过 CRD（ConstraintTemplate + Constraint）管理，原生 K8s 体验 |
| 审计能力 | 需自行实现审计逻辑 | 内置审计组件，自动检查已有资源 |
| 社区生态 | 通用引擎，社区库较少 | CNCF 毕业项目，提供丰富的预置策略库（Gatekeeper Library） |
| 适用场景 | 需要高度自定义策略引擎的场景 | Kubernetes 原生策略管理，开箱即用 |
3.4 本章小结
OPA 提供了强大的策略即代码能力，Rego 语言以其声明式特性简化了复杂策略的编写。Gatekeeper 作为 OPA 在 Kubernetes 中的官方集成，通过 CRD 和 Webhook 机制，将策略管理完全融入 K8s 原生生态。理解这三者的关系，是后续学习准入控制策略编写与调度器参数调优的基础。