从旧版鉴权策略迁移到 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 = allow	allow if { ... }
策略效果为拒绝effect = deny	deny 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 {
  input.subject.auth_type == "anonymous"
  input.cloudbase.resource_type == "functions"
  input.request.host == "xxx.api.tcloudbasegateway.com"
  input.request.path == "/v1/functions/sendMsg"
}

三、注意事项

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