📚 课程目录第2章 OPA基础概念

2. OPA基础概念：Rego语言简介、OPA架构（Input/Data/Query）、OPA与Kubernetes的集成方式

在深入云原生安全基线巡检之前，必须理解OPA（Open Policy Agent）的核心基础。OPA是一种通用的、开源的策略引擎，它将策略从软件的业务逻辑中解耦出来。本章将围绕三个核心支柱展开：策略语言Rego、运行时架构（Input/Data/Query）以及OPA与Kubernetes的集成模式。

2.1 Rego语言简介

Rego是OPA专用的声明式策略语言，灵感来源于Datalog。它并非通用的编程语言，而是专门为表达策略规则而设计。Rego的核心思想是：策略即代码，但这里的“代码”是高度声明式的，你只需要描述“策略应该是什么”，而不需要描述“如何执行策略”。

关键认知： Rego中的规则（Rule）本质上是产生布尔值或数据集的逻辑断言。当查询条件满足时，规则返回true或生成一组数据；当不满足时，规则默认返回undefined（在策略上下文中通常被视为false）。

2.1.1 Rego语法核心要素

要素	说明	示例
规则（Rule）	策略的基本单元，由头部和主体组成。	`allow { input.role == "admin" }`
变量（Variable）	不可变，一旦绑定值后不能修改。	`user := input.user`
迭代（Iteration）	通过`some`关键字遍历集合。	`some i; input.users[i].name == "alice"`
默认值（Default）	为规则设置默认布尔值，避免`undefined`。	`default allow = false`
内置函数（Built-in）	提供字符串、网络、加密等操作。	`startswith(input.path, "/api/v1")`

2.1.2 一个完整的Rego策略示例

以下策略用于检查Kubernetes Pod是否使用了允许的镜像仓库：

package kubernetes.admission

# 默认拒绝
default deny = false

# 规则：如果镜像来源不在允许列表中，则拒绝
deny {
    input.request.kind.kind == "Pod"
    some container in input.request.object.spec.containers
    not allowed_image(container.image)
}

# 辅助规则：判断镜像是否在允许列表中
allowed_image(image) {
    startswith(image, "registry.example.com/")
}

allowed_image(image) {
    image == "nginx:latest"
}

  Rego设计原则： 策略应尽量保持无状态和幂等。Rego不鼓励使用循环和副作用，所有逻辑都应基于输入（Input）和数据（Data）进行推导。

2.2 OPA架构：Input / Data / Query

OPA的运行时架构围绕三个核心概念构建：Input（输入）、Data（数据）和Query（查询）。理解这三者的关系是掌握OPA工作流的关键。

2.2.1 三个核心概念的详细对比

概念	来源	内容	生命周期
Input	外部调用方（如Kube-APIServer）	请求的原始数据（JSON对象），如Pod创建请求、HTTP请求属性	每次查询动态传入
Data	外部数据源（文件、API、Bundle）	策略依赖的静态或半静态数据，如允许的镜像列表、集群节点信息	通过`opa run`或Bundle加载，可缓存
Query	用户或系统	对OPA引擎发起的策略评估请求，通常形如`data.kubernetes.admission.deny`	每次评估独立执行

常见误区： 初学者常将input和data混淆。请记住：input是“这次请求是什么”，data是“系统已知的事实是什么”。策略规则通过组合input和data来做出决策。

2.3 OPA与Kubernetes的集成方式

OPA与Kubernetes的集成主要通过两种模式：动态准入控制（Admission Control）和边车（Sidecar）模式。在云原生安全基线巡检场景中，最常用的是动态准入控制模式。

2.3.1 集成模式对比

集成模式	部署方式	适用场景	优点	缺点
Admission Controller	作为独立服务部署，通过`ValidatingWebhookConfiguration`接入	资源创建/更新时的策略校验（如Pod安全策略、镜像校验）	集中管控，策略更新无需重启K8s组件	增加API请求延迟
Sidecar / DaemonSet	在每个节点或Pod内运行OPA实例	运行时策略执行（如文件系统访问控制、网络策略）	低延迟，支持离线场景	管理成本高，策略分发复杂
Kube-mgmt（已弃用）	通过Sidecar同步K8s资源到OPA Data	历史兼容，新项目建议使用OPA内置的K8s API	自动同步资源	功能有限，社区已不推荐

2.3.2 动态准入控制集成流程

这是OPA在Kubernetes中最主流的集成方式，也是本课程后续巡检功能的基础。

2.3.3 集成配置示例

以下是一个典型的ValidatingWebhookConfiguration配置片段，用于将Kubernetes的Pod创建请求转发到OPA服务：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: opa-validating-webhook
webhooks:
- name: pod-policy.opa.example.com
  clientConfig:
    service:
      name: opa-service
      namespace: opa-system
      path: /v1/admit
    caBundle: <base64-encoded-ca-cert>
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
  admissionReviewVersions: ["v1"]
  sideEffects: None

  集成要点： OPA服务需要暴露一个HTTP端点（如/v1/admit），接收Kubernetes的AdmissionReview请求，并返回包含allowed字段的AdmissionReview响应。OPA内部通过Rego规则解析input.request对象，做出策略决策。

2.4 本章小结

本章建立了OPA的三大基础认知：

Rego语言：声明式策略语言，通过规则（Rule）描述策略意图，核心操作是组合input和data。
OPA架构：Input（请求上下文）、Data（静态事实）、Query（评估请求）三者协同工作，输出决策结果。
Kubernetes集成：以动态准入控制（Admission Webhook）为主流模式，OPA作为独立服务接收并处理K8s资源请求。