📚 课程目录第3章资源模型基础

3. 资源模型基础：定义、类型、属性与关系图

资源模型是 OPA 与日志平台组件拓扑权限设计的核心抽象层。它将物理或逻辑的组件（如 Pod、Service、Namespace）统一建模为可被策略引擎理解的结构化实体。理解资源模型的定义、类型、属性及关系图，是构建细粒度、可扩展权限策略的前提。

3.1 资源模型的定义

资源模型（Resource Model）是对系统中所有可被授权或审计的实体进行形式化描述的一套规范。在云原生环境中，资源模型通常遵循以下原则：

统一性：所有组件（计算、网络、存储、策略）均以相同结构表达。
可嵌套性：资源可以包含子资源（如 Namespace 包含 Pod）。
可标识性：每个资源实例拥有全局唯一的标识符（UID）。
可查询性：资源属性支持按路径或标签进行检索。

设计要点：资源模型不应与具体实现耦合。例如，日志平台中的“日志流”资源，既可以对应 Kafka Topic，也可以对应 Elasticsearch Index，但模型层统一抽象为 logstream 类型。

3.2 资源类型

资源类型（Resource Type）定义了资源的类别。在日志平台拓扑中，常见的资源类型如下表所示：

资源类型	标识符	示例实例	层级
集群	`cluster`	`prod-cluster-01`	顶层
命名空间	`namespace`	`logging-system`	集群下
工作负载	`workload`	`fluentbit-daemonset`	命名空间下
日志流	`logstream`	`app-audit-log`	工作负载下
存储后端	`storage`	`es-data-hot`	日志流下
策略绑定	`policybinding`	`audit-readonly-binding`	跨层级

  类型扩展性：资源类型应支持自定义扩展。例如，当引入新的日志采集器（如 Vector）时，只需注册 vector-agent 类型，无需修改核心模型。

3.3 资源属性

每个资源实例都包含一组属性（Attributes），用于描述其状态、标签、元数据和访问控制信息。属性分为三类：

标识属性：id（全局唯一）、name（可读名称）、type（资源类型）。
拓扑属性：parent_id（父资源 ID）、path（从根到当前节点的路径，如 /cluster/ns/workload）。
策略属性：labels（键值对标签）、annotations（非结构化元数据）、owner（所属团队）。

以下是一个资源实例的 JSON 表示示例：

{
  "id": "logstream:prod-cluster-01/logging-system/fluentbit-daemonset/app-audit-log",
  "name": "app-audit-log",
  "type": "logstream",
  "parent_id": "workload:prod-cluster-01/logging-system/fluentbit-daemonset",
  "path": "/cluster/prod-cluster-01/namespace/logging-system/workload/fluentbit-daemonset/logstream/app-audit-log",
  "labels": {
    "environment": "production",
    "data_classification": "audit",
    "retention_days": "90"
  },
  "annotations": {
    "description": "Application audit log stream",
    "source": "fluentbit-tail"
  },
  "owner": "security-team"
}

3.4 资源关系图

资源关系图（Resource Relationship Graph）描述了资源之间的父子、依赖和引用关系。它是 OPA 策略评估时进行路径遍历和上下文推导的基础。

下图展示了日志平台组件拓扑中的核心资源关系：

关系图的关键特征：

树形结构：从集群到存储后端形成严格的父子层级，每个子资源只有一个父资源。
跨层级引用：策略绑定（policybinding）可以引用任意层级的资源，实现灵活的权限控制。
路径唯一性：每个资源实例的 path 属性在图中唯一确定其位置。

3.5 资源模型在 OPA 策略中的应用

OPA 策略通过 input.resource 获取当前请求的资源实例，然后利用资源模型进行路径匹配和属性检查。以下是一个基于资源路径的授权策略示例：

package platform.authz

# 允许安全团队访问所有 audit 分类的日志流
default allow = false

allow {
    input.resource.type == "logstream"
    input.resource.labels.data_classification == "audit"
    input.user.team == "security-team"
}

# 允许运维团队访问其所属命名空间下的所有资源
allow {
    input.resource.path =~ sprintf("/cluster/%s/namespace/%s/*", [input.user.cluster, input.user.namespace])
    input.user.role == "ops"
}

注意：资源模型的路径匹配应使用前缀匹配或正则表达式，避免硬编码完整路径。OPA 的 glob.match 或 re_match 函数可用于高效路径模式匹配。

3.6 资源模型设计检查清单

在定义资源模型时，建议对照以下清单进行验证：

检查项	说明	通过标准
类型完备性	所有需要授权的组件是否都有对应资源类型	无遗漏
属性可扩展性	是否支持通过 labels/annotations 添加自定义属性	支持
路径唯一性	每个资源实例的 path 是否全局唯一	是
关系图无环	父子关系是否构成有向无环图（DAG）	是
策略可表达性	是否能用资源模型表达所有预期的权限规则	覆盖 90%+ 场景

通过以上定义、类型、属性和关系图的系统设计，资源模型为 OPA 策略引擎提供了结构化的数据基础，使得日志平台组件拓扑的权限控制既精确又灵活。