跳到主要内容

从旧版鉴权策略迁移到 OPA

云开发原有的网关策略将逐步切换到 OPA。默认行为不变，平台已内置等价规则，无需任何操作。仅当在控制台上手动为角色关联过网关策略时，需参考下方手动操作或编写新策略。

一、给角色关联了预设策略​

旧版网关鉴权提供了一组预设策略（每条策略本质是「对某个 resource_type 的允许 / 拒绝」），并将其关联到内部用户/外部用户/默认用户等角色上。切换到 OPA 后，需要重新关联预设策略并保存。

对于下列旧网关策略： 旧网关策略

选择「新建策略」，为对应的资源和角色创建对应允许策略： 新策略

为每一条策略执行上述操作，检查无误后点击保存。

二、自定义策略翻译到 Rego​

对于手动编写的自定义策略，可参考下方描述迁移至新语法：

2.1 最小对照示例​

网关鉴权声明的策略：

// 关联角色：外部用户
// 含义：放通外部用户对云函数的访问
{
    "statement": [
        {
            "action": "functions:*", // action：声明作用域为 云函数 资源
            "resource": "*",
            "effect": "allow" // allow：声明操作为 放通
        }
    ],
    "version": "1.0"
}

等价 Rego:

package authz.user

default allow := false

# 含义：放通外部用户对云函数的访问
allow if {
  # 两条条件之间为与关系，即同时满足才执行 allow（允许）操作
  # 通过 auth_type 为 external 匹配外部用户
  input.subject.auth_type == "external"
  # 通过 resource_type 为 functions 匹配云函数
  input.cloudbase.resource_type == "functions"
}

2.2 常见字段对照​

下表中列出了旧版网关策略中的概念在 Rego 表达式中的对应表达式：

网关鉴权Rego 表达式示例
策略关联的角色为管理员input.subject.auth_type == "administrator"
策略关联的角色为外部用户input.subject.auth_type == "external"
策略关联的角色为内部用户input.subject.auth_type == "internal"
策略关联的角色为匿名用户input.subject.auth_type == "anonymous"
策略关联的角色为注册用户input.subject.auth_type in {"external", "internal"}
策略关联的角色为所有用户not input.subject.auth_type == "unauthenticated"
策略关联的角色为 <自定义角色>"<角色名>" in input.subject.groups
策略中关联的资源 <resource>input.cloudbase.resource_type == "<resource>"
策略中指定的域名 <host>input.request.host == "<host>"
策略中指定的 HTTP 方法 <method>input.request.method == "<method>"
策略中指定的精确路径<path>（不含 * 通配）input.request.path == "<path>"
策略中指定的前缀路径<path>（含*通配，如/path/*）startswith(input.request.path, "<path>")
策略效果为允许 effect = allowallow if { ... }
策略效果为拒绝effect = denydeny contains "这里描述拒绝原因" if { ... }

关于策略中 action 的资源标识:域名:HTTP方法:请求路径四段式结构，详细说明如下：

格式说明：

  1. 资源标识（必填）：如 functions、storages、cloudrun 等
  2. 域名（可选）：实际访问的自定义域名，通过HTTP API 访问时域名统一为 tcloudbasegateway，省略时表示 *（所有域名）
  3. HTTP方法（可选）：大写的 HTTP 请求方法（如 GET、POST、PUT、DELETE），省略时表示 *（所有方法）
  4. 请求路径（必填）：HTTP 请求路径，使用 * 通配符匹配。* 表示所有路径，/path/* 表示 /path/ 下的所有路径

示例：

  • functions:* → 允许所有云函数访问（省略域名和方法）
  • functions:/hello → 仅允许访问路径 /hello
  • functions:/api/* → 允许访问 /api/ 下的所有路径（如 /api/users、/api/orders）
  • cloudrun:xxx.api.tcloudbasegateway.com:POST:/v1/cloudrun/* → 允许通过指定域名 POST 方法访问云托管 API 下的所有路径

2.3 常见对照示例​

以下示例均省略 package authz.user 头,实际使用时拼到一份策略文件中即可。

示例 1 — 放通全部用户访问 AI 大模型

allow if {
  input.cloudbase.resource_type == "ai"
}

示例 2 — 给外部用户方通单个 APIs

allow if {
  input.subject.auth_type == "external"
  input.cloudbase.resource_type == "apis"
  startswith(input.request.path, "/v1/apis/api_id")
}

示例 3 — 放通匿名用户访问云函数

allow if {
  input.subject.auth_type == "anonymous"
  input.cloudbase.resource_type == "functions"
}

示例 4 — 给某个路径放通单个资源方用:

allow if {
  input.cloudbase.resource_type == "functions"
  input.request.path == "/v1/functions/hello"
}

示例 5 — 给所有已登录用户放通一批云函数调用

allow if {
  not input.subject.auth_type == "unauthenticated"
  input.cloudbase.resource_type == "functions"
  startswith(input.request.path, "/v1/functions/api/")
}

示例 6 — 放通某个自定义角色对于云函数的访问

allow if {
  # 检查用户是否具有指定的自定义角色
  "my-custom-role" in input.subject.groups
  input.cloudbase.resource_type == "functions"
}

三、注意事项​

  • deny 优先于 allow，同时满足 allow 和 deny 条件时请求会被拒绝。
  • 切换是单向的，保存 OPA 策略后立即生效，无法回退至旧版网关鉴权，请确认后保存。