1. OPA Gatekeeper 概述
在云原生安全体系中，Kubernetes 的准入控制是保障集群安全的第一道防线。OPA Gatekeeper 正是将开放策略代理（OPA）的策略引擎能力与 Kubernetes 的准入控制机制深度整合的解决方案。本章将系统阐述 OPA 与 Gatekeeper 的关系、Gatekeeper 在 Kubernetes 中的角色定位、核心组件构成以及完整的工作流程。
1.1 OPA 与 Gatekeeper 的关系
OPA（Open Policy Agent）是一个通用的、开源的策略引擎，它将策略从软件中解耦出来，提供统一的策略即代码（Policy-as-Code）框架。而 Gatekeeper 是 OPA 在 Kubernetes 生态中的原生集成实现，是 OPA 与 Kubernetes 之间的桥梁。
| 维度 | OPA | Gatekeeper |
|---|---|---|
| 定位 | 通用策略引擎，适用于微服务、CI/CD、Kubernetes 等多种场景 | Kubernetes 专用的准入控制器与策略管理框架 |
| 策略语言 | Rego（OPA 原生策略语言） | Rego（完全兼容 OPA 语法） |
| 部署方式 | 独立进程、Sidecar、库嵌入 | Kubernetes 原生 CRD + Webhook 模式 |
| 数据源 | 外部文档（JSON/YAML） | Kubernetes 资源对象 + 集群状态 |
| 策略生命周期 | 手动管理 | 通过 CRD 声明式管理，支持版本化与审计 |
核心理解：OPA 是策略引擎的“内核”，Gatekeeper 是 OPA 在 Kubernetes 中的“适配层”。Gatekeeper 将 OPA 的通用策略评估能力转化为 Kubernetes 原生的准入控制体验，使得集群管理员可以通过声明式 CRD 来定义、部署和审计策略。
1.2 Gatekeeper 在 Kubernetes 中的角色
Gatekeeper 在 Kubernetes 集群中扮演着策略执行网关的角色，它位于 API Server 的准入控制链中，对所有资源的创建、更新和删除操作进行策略校验。
- 准入控制器（Admission Controller）：以 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 的形式注册到 API Server，拦截资源请求。
- 策略定义者（Policy Definer）：通过
ConstraintTemplate和Constraint两种 CRD 来定义和实例化策略。 - 审计者（Auditor）：定期对集群中已有资源进行策略合规性检查，生成审计结果。
- 数据同步器（Data Sync）：将集群中的资源状态同步到 OPA 引擎，使策略可以基于实时集群状态做出决策。
角色定位提示：Gatekeeper 不是替代 Kubernetes RBAC 或 Pod Security Standards 的工具，而是在这些基础安全机制之上提供更灵活、更细粒度的策略控制层。它特别适合需要自定义合规基线、多租户隔离、资源命名规范等场景。
1.3 核心组件与架构
Gatekeeper 的架构由控制平面组件和数据平面组件两部分构成，通过 Kubernetes CRD 机制实现策略的声明式管理。
1.4 工作流程详解
Gatekeeper 的工作流程可以分为策略定义阶段和请求处理阶段两个主要环节，下面通过一个完整的资源创建请求来展示其运作过程。
1.4.1 策略定义阶段
- 创建 ConstraintTemplate：管理员编写 Rego 策略模板，定义策略的逻辑结构和参数占位符。
- 创建 Constraint：通过 Constraint CRD 实例化模板，传入具体的参数值（如允许的命名空间列表、资源配额上限等）。
- 控制器处理：ConstraintTemplate 控制器和 Constraint 控制器将 CRD 对象转换为 OPA 引擎可识别的策略规则。
1.4.2 请求处理阶段
- 请求到达 API Server：用户通过 kubectl 或客户端发送资源创建/更新请求。
- 准入控制拦截：API Server 根据 ValidatingWebhookConfiguration 配置，将请求转发给 Gatekeeper Webhook。
- OPA 策略评估：Webhook 将请求对象和集群缓存数据传递给 OPA 引擎，引擎执行所有已激活的 Constraint 策略。
- 决策返回：
- 允许（Allow）：所有策略通过，请求继续执行。
- 拒绝（Deny）：任一策略失败，返回详细的拒绝原因和违规字段。
- 警告（Warn）：策略配置为警告模式时，允许请求但记录审计日志。
- 审计循环：审计控制器定期扫描集群中已有资源，与当前策略进行比对，发现违规资源并生成审计事件。
关键注意事项：Gatekeeper 的 Webhook 配置需要谨慎设置
failurePolicy 和 timeoutSeconds。如果 Gatekeeper 服务不可用，failurePolicy 为 Fail 会导致整个集群的写入操作被阻塞；建议在关键生产环境中使用 Ignore 并配合监控告警。
1.5 核心组件清单
| 组件名称 | 类型 | 功能描述 |
|---|---|---|
| gatekeeper-controller-manager | Deployment | 主控制器，管理 CRD 的同步、策略编译、审计循环 |
| gatekeeper-audit | Deployment | 专门负责审计任务的控制器，定期检查集群资源合规性 |
| gatekeeper-webhook | Service | 暴露 Webhook 端点，接收 API Server 的准入请求 |
| ConstraintTemplate | CRD | 定义 Rego 策略模板，包含策略逻辑和参数 schema |
| Constraint | CRD | 策略的实例化对象，指定作用范围、参数值和执行模式 |
| Config | CRD | 配置 Gatekeeper 的同步资源类型、日志级别、排除命名空间等 |
1.6 策略执行模式
Gatekeeper 支持三种策略执行模式，管理员可以根据策略的严格程度和业务需求灵活选择：
- Deny（拒绝模式）：违反策略的资源请求直接被拒绝，返回 403 错误。适用于安全基线、合规红线等不可妥协的策略。
- Dryrun（试运行模式）：违反策略的请求仍然被允许，但会在审计日志中记录违规信息。适用于新策略上线前的灰度验证阶段。
- Warn（警告模式）：违反策略的请求被允许，但 API Server 会向客户端返回警告信息。适用于建议性规范，如命名规范、标签要求等。
最佳实践：建议新策略先以
Dryrun 模式部署，观察对现有资源的影响范围；确认无误后切换为 Warn 模式，给用户一段适应期；最终转为 Deny 模式强制执行。这种渐进式策略发布方式可以有效避免因策略误判导致的业务中断。