3. OPA（Open Policy Agent）架构：组件、部署模式与Kubernetes集成
Open Policy Agent（OPA）是一个开源的、通用策略引擎，它将策略决策与业务逻辑执行分离。在云原生生态中，OPA 是 策略即代码（Policy-as-Code） 的核心实现。理解 OPA 的架构是编写 Rego 规则并将其集成到 Helm Chart 中的前提。
3.1 OPA 核心组件
OPA 采用客户端-服务器（C/S）架构，主要由以下三个核心组件构成：
| 组件 | 角色 | 说明 |
|---|---|---|
| OPA Agent（服务端） | 策略决策点（PDP） | 加载 Rego 策略和数据，对外提供 REST/gRPC 接口，接收查询并返回决策结果。 |
| OPA Client（客户端） | 策略执行点（PEP） | 嵌入在应用（如 Kubernetes API Server、Envoy、Ingress Controller）中，向 OPA Agent 发起查询并执行返回的决策。 |
| Rego 策略包 | 策略定义 | 使用 Rego 语言编写的策略文件（.rego），定义了“允许/拒绝”规则、数据过滤逻辑等。 |
关键概念： OPA 本身不执行策略，它只负责评估策略。执行动作（如拒绝 Pod 创建、修改请求头）由客户端（PEP）完成。
3.2 OPA 部署模式
OPA 支持多种部署模式，以适应不同的场景和性能要求。以下是三种主流模式：
- Sidecar 模式（本地代理）
将 OPA Agent 作为 Sidecar 容器与主应用容器部署在同一个 Pod 中。查询通过 localhost 完成，延迟极低，适合对性能敏感的场景（如 API 网关、微服务）。 - DaemonSet 模式（节点代理）
在每个 Kubernetes 节点上部署一个 OPA Agent 实例。节点上的所有 Pod 共享该 Agent，减少资源消耗，适合集群级别的策略执行（如 Pod 安全策略）。 - 独立服务模式（集中式）
将 OPA Agent 部署为独立的 Service，所有客户端通过网络访问。便于统一管理和更新策略，但会增加网络延迟，适合策略变更频繁或需要集中审计的场景。
| 模式 | 延迟 | 资源消耗 | 管理复杂度 | 典型场景 |
|---|---|---|---|---|
| Sidecar | 极低 | 高（每 Pod 一个） | 低 | 微服务 API 策略、Envoy 外部授权 |
| DaemonSet | 低 | 中（每节点一个） | 中 | Kubernetes 准入控制、节点级安全 |
| 独立服务 | 中 | 低（全局一个） | 高 | 集中策略管理、跨集群策略 |
推荐： 在 Helm Chart 集成中，DaemonSet 模式 是最常见的部署方式。它平衡了性能与资源，且与 Kubernetes 原生组件（如 kube-apiserver）的集成最为自然。
3.3 与 Kubernetes 的集成方式
OPA 与 Kubernetes 的集成主要通过 准入控制器（Admission Controller） 实现。Kubernetes 在 API 请求持久化之前，会调用外部 Webhook 进行验证或修改。OPA 通过 ValidatingAdmissionWebhook 和 MutatingAdmissionWebhook 两种方式介入。
3.3.1 集成架构
- ValidatingAdmissionWebhook：OPA 接收 AdmissionReview 请求，根据 Rego 策略返回“允许”或“拒绝”决策。用于强制合规性检查（如禁止特权容器）。
- MutatingAdmissionWebhook：OPA 接收 AdmissionReview 请求，返回 JSON Patch 来修改资源对象。用于自动注入 Sidecar、添加标签等。
3.3.2 集成配置示例（Helm Values）
在 Helm Chart 中，我们通常通过 values.yaml 配置 OPA 的 Webhook 集成。以下是一个典型的配置片段：
# values.yaml
opa:
enabled: true
webhook:
# 启用 ValidatingAdmissionWebhook
validatingWebhook:
enabled: true
failurePolicy: Fail
rules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["pods"]
# 启用 MutatingAdmissionWebhook
mutatingWebhook:
enabled: false
# Rego 策略配置
policies:
- name: deny-privileged
rego: |
package kubernetes.admission
deny[msg] {
input.request.object.spec.containers[_].securityContext.privileged == true
msg := "Privileged containers are not allowed"
}
注意： 在生产环境中，务必为 OPA Webhook 配置 TLS 证书，并设置合理的
failurePolicy（建议初始阶段使用 Ignore 避免集群不可用）。Helm Chart 可以通过 cert-manager 或预置 Secret 自动管理证书。