3. 控制平面核心功能：资源编排、权限管理、审计日志、策略引擎

控制平面是 IDP 自助门户的“大脑”，它向下管理基础设施资源，向上暴露标准化的 API 接口。在自助门户的每一次接口调用背后，控制平面都会依次执行四个核心功能：资源编排、权限管理、审计日志和策略引擎。这四个功能协同工作，确保开发者能够安全、合规、可追溯地自助获取所需资源。

3.1 功能全景与调用链路

当开发者在自助门户上点击“创建环境”或“申请数据库”时，控制平面会按照固定的顺序触发以下四个核心模块。下图展示了在一次典型的接口调用中，四个功能的协作关系与数据流向。

3.2 资源编排：基础设施即代码的执行引擎

资源编排是控制平面最核心的“动手”能力。它接收来自上层（如策略引擎和权限管理校验通过后的请求），并将其转换为对底层基础设施的实际操作。在 IDP 场景中，资源编排通常基于 基础设施即代码（IaC） 理念实现。

3.2.1 编排流程

1. 模板解析：从 Catalog 中获取对应的资源模板（如 Terraform、Crossplane、Pulumi 等）。
2. 参数注入：将开发者提交的请求参数（如环境名称、规格、区域）注入模板。
3. 状态计算：对比当前实际状态与期望状态，生成变更计划（Plan）。
4. 执行变更：调用底层 API（如 Kubernetes、云服务商 API）执行资源创建、更新或删除。
5. 状态回写：将执行结果（成功/失败、资源 ID、连接信息）写回控制平面的状态存储。

3.2.2 常见编排引擎对比

3.3 权限管理：细粒度的访问控制

权限管理模块负责验证“谁可以做什么”。在 IDP 自助门户中，权限管理不仅仅是简单的用户认证，更关键的是资源级和操作级的授权。常见的实现方式包括 RBAC（基于角色的访问控制） 和 ABAC（基于属性的访问控制）。

3.3.1 权限模型对比

3.3.2 接口调用中的权限校验流程

// 伪代码：权限校验核心逻辑
func CheckPermission(ctx, userID, action, resourceARN) bool {
    // 1. 获取用户角色
    roles := getRolesForUser(ctx, userID)
    // 2. 获取资源所属项目/环境
    project := getResourceProject(ctx, resourceARN)
    // 3. 遍历角色，检查是否有匹配的权限策略
    for _, role := range roles {
        if hasPolicy(role, action, project) {
            return true
        }
    }
    // 4. 记录拒绝日志
    auditLog(ctx, "PERMISSION_DENIED", userID, action, resourceARN)
    return false
}

3.4 审计日志：不可篡改的操作记录

审计日志是控制平面的“黑匣子”。每一次接口调用、每一次资源变更、每一次权限拒绝，都必须被完整、不可篡改地记录下来。审计日志不仅是合规审计的需要，也是故障排查和安全事件溯源的关键依据。

3.4.1 审计日志的核心字段

3.4.2 审计日志的存储与查询

• 存储后端：推荐使用 对象存储（如 S3、MinIO） + 时序数据库（如 Elasticsearch、ClickHouse） 的组合。对象存储用于长期归档，时序数据库用于快速检索。
• 不可篡改性：采用 日志哈希链 或 写入 WORM（Write Once Read Many） 存储，防止日志被篡改。
• 查询接口：控制平面应提供 REST API 或 GraphQL 接口，支持按时间、操作者、资源类型、操作结果等维度进行过滤查询。

3.5 策略引擎：动态准入控制

策略引擎是控制平面的“守门员”。它在资源编排执行之前，对请求进行动态准入控制。策略引擎确保所有资源变更都符合组织定义的规则，例如：禁止在非生产环境使用高规格实例、强制所有资源必须包含 owner 标签、限制每个项目的最大资源数量等。

3.5.1 策略引擎的工作模式

1. 输入：接收来自 API 网关的请求上下文（用户信息、请求参数、目标资源类型）。
2. 评估：将请求与预定义的策略规则进行匹配。策略规则通常使用 Rego（OPA）、CEL（Common Expression Language） 或 JSON Schema 编写。
3. 决策：返回 allow、deny 或 warn。如果返回 deny，控制平面将直接拒绝请求，并附带拒绝原因。
4. 副作用：部分策略引擎支持在允许请求的同时，自动注入或修改请求参数（如自动添加标签）。

3.5.2 策略示例（使用 OPA Rego）

# 策略：禁止在非生产环境使用 gpu 实例
package idp.resources

default allow = false

allow {
    input.resource.type == "compute"
    input.resource.spec.instance_type != "gpu.*"
}

allow {
    input.resource.type == "compute"
    input.resource.spec.instance_type == "gpu.*"
    input.context.environment == "production"
}

# 拒绝原因
deny_reason = "GPU instances are only allowed in production environment" {
    input.resource.spec.instance_type == "gpu.*"
    input.context.environment != "production"
}

3.6 四个功能的协同关系

下表总结了四个核心功能在接口调用中的职责、执行顺序与关键输出，帮助理解它们如何共同保障 IDP 自助门户的稳定与安全。