4. OPA 部署模式：Sidecar、独立服务与 Kubernetes 集成

OPA（Open Policy Agent）在云原生环境中的部署方式直接影响策略执行的延迟、可用性以及运维复杂度。根据控制面与数据面的耦合程度，OPA 主要支持三种部署模式：Sidecar 模式、独立服务模式以及Kubernetes 原生集成模式。每种模式适用于不同的安全准入场景，尤其是在 Knative 服务流水线中，选择正确的部署模式决定了策略执行的实时性与可靠性。

4.1 三种部署模式对比

4.2 模式一：OPA 作为 Sidecar

Sidecar 模式将 OPA 容器与业务容器部署在同一个 Pod 内，业务进程通过 localhost 调用 OPA 的 REST API 进行策略评估。该模式消除了网络延迟和外部依赖，适合对延迟敏感的策略执行场景。

• 通信方式：业务容器通过 http://localhost:8181/v1/data 查询策略决策。
• 策略更新：通过 ConfigMap 挂载或 OPA 的 Bundle API 热加载。
• 资源隔离：每个 Pod 拥有独立的 OPA 实例，故障域最小。
• 典型用例：Knative Service 中每个 Pod 的请求头校验、JWT 验证、参数白名单。

# OPA Sidecar 注入示例（Pod 片段）
apiVersion: v1
kind: Pod
metadata:
  name: knative-service-pod
spec:
  containers:
  - name: app
    image: my-app:latest
    env:
    - name: OPA_URL
      value: "http://localhost:8181/v1/data"
  - name: opa-sidecar
    image: openpolicyagent/opa:latest
    args:
      - "run"
      - "--server"
      - "--addr=:8181"
      - "--config-file=/config/opa-config.yaml"
    volumeMounts:
    - name: opa-policy
      mountPath: /config
  volumes:
  - name: opa-policy
    configMap:
      name: opa-policy-cm

4.3 模式二：OPA 作为独立服务

独立服务模式将 OPA 部署为一个独立的 Deployment，通过 ClusterIP Service 暴露策略查询端点。集群内的所有服务（包括 Knative 的各个组件）均可通过 DNS 名称调用 OPA 进行策略评估。该模式适合策略逻辑需要被多个不相关的微服务共享的场景。

• 通信方式：业务服务通过 http://opa-service.namespace.svc.cluster.local:8181/v1/data 查询。
• 高可用：可配置多副本 + 负载均衡，避免单点故障。
• 策略中心：所有策略集中管理，更新后对所有消费者即时生效。
• 典型用例：Knative 流水线中多个阶段共享的全局合规策略、跨命名空间的资源配额校验。

# OPA 独立服务 Deployment 示例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: opa-service
  namespace: opa-system
spec:
  replicas: 3
  selector:
    matchLabels:
      app: opa
  template:
    metadata:
      labels:
        app: opa
    spec:
      containers:
      - name: opa
        image: openpolicyagent/opa:latest
        args:
          - "run"
          - "--server"
          - "--addr=:8181"
          - "--bundle"
          - "/bundles/"
        volumeMounts:
        - name: opa-bundle
          mountPath: /bundles
      volumes:
      - name: opa-bundle
        configMap:
          name: opa-bundle-cm
---
apiVersion: v1
kind: Service
metadata:
  name: opa-service
  namespace: opa-system
spec:
  selector:
    app: opa
  ports:
  - port: 8181
    targetPort: 8181

4.4 模式三：OPA 与 Kubernetes 集成（Admission Webhook）

Kubernetes 集成模式通过 ValidatingAdmissionWebhook 或 MutatingAdmissionWebhook 将 OPA 嵌入到 API Server 的资源处理流程中。当用户创建、更新或删除 Kubernetes 资源时，API Server 会向 OPA 发送 AdmissionReview 请求，OPA 根据预定义策略返回允许或拒绝的决策。这是 Knative 服务安全准入控制中最常用的模式。

• 集成方式：部署 OPA 作为 Webhook 后端，配置 ValidatingWebhookConfiguration 资源。
• 策略触发：支持按资源类型（如 Pod、Service、Knative Service）和操作（CREATE、UPDATE、DELETE）过滤。
• 决策结果：OPA 返回 allowed: true/false，并可附带拒绝原因和警告信息。
• 典型用例：禁止 Knative Service 使用特权容器、强制设置资源请求/限制、校验镜像仓库白名单。

# ValidatingWebhookConfiguration 示例
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: opa-validating-webhook
webhooks:
- name: opa.kubernetes.admission
  clientConfig:
    service:
      name: opa-webhook-service
      namespace: opa-system
      path: /v1/admission
    caBundle: <base64-encoded-ca-cert>
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["serving.knative.dev"]
    apiVersions: ["v1"]
    resources: ["services", "configurations", "revisions"]
    scope: "Namespaced"
  admissionReviewVersions: ["v1"]
  sideEffects: None
  timeoutSeconds: 5

4.5 部署模式选择矩阵

在 Knative 服务流水线的不同阶段，三种部署模式各有侧重。下表总结了在典型流水线环节中的推荐选择：