权限治理：成员权限、行级权限与安全上下文

如果语义层只解决“指标统一”，但不解决“谁能看什么”，它就很难进入生产。

1. 为什么 Cube 的权限能力很重要

企业分析场景经常会遇到：

• 不同角色看到不同指标；
• 不同国家经理只能看各自国家数据；
• 外部客户只能看自己的租户数据；
• 某些敏感字段不能暴露给普通用户；
• 某些 API 只能给服务账号调用。

Cube 的做法，是把这些规则放在语义层，而不是全部散落到下游应用里。

2. Row-level Security：按行过滤数据

官方文档中明确指出：

• row-level security 类似数据库中的行级权限；
• 可以通过 access policies 管理；
• 可以基于 groups 和 user attributes 做过滤。

官方风格示例

access_policy:
  - group: manager
    row_level:
      filters:
        - member: country
          operator: equals
          values: ["{ userAttributes.country }"]

它的含义是：

• 经理组用户只能看到 country = 当前用户国家 的数据。

3. Member-level Security：控制暴露哪些成员

除了过滤行，还要控制成员暴露范围。

比如：

• 财务指标不对销售团队开放；
• 成本、毛利、退款率只能给少数角色；
• 一些技术字段不应该被最终用户看见。

这时候就需要 member-level security 与 view 层治理配合使用。

4. Security Context：权限的输入变量

很多权限规则最终都会依赖请求上下文，例如：

• 用户 ID
• 用户所属组织
• 国家 / 大区 / 部门
• 是否服务账号
• 是否内部管理员

Cube 的安全上下文会参与：

• access policy
• API scopes
• query rewrite
• 多租户 driver / repository 选择

这也是为什么生产环境中的认证不是“可有可无”的附属项，而是整个语义层治理的前提。

5. API Scopes：不是所有接口都给所有人

REST API 文档里还描述了 API scopes：

• meta
• data
• graphql
• sql
• jobs

并且可以通过：

• CUBEJS_DEFAULT_API_SCOPES
• contextToApiScopes

控制不同用户能访问哪些接口。

这很适合这样的场景：

• 普通用户只能查数据，不能看完整 metadata；
• 服务账号可以访问 /v1/meta；
• 某些系统能跑 pre-aggregations jobs，而普通客户端不行。

6. View 在权限治理中的价值

很多人只把 view 当“字段组合器”，其实它在治理里也很关键。

因为 view 能帮助你：

• 暴露更少、更稳的成员；
• 屏蔽底层复杂 join 图；
• 把不同角色 / 场景所需数据产品分开。

例如：

• executive_dashboard_view
• regional_sales_view
• customer_success_view

这样最终消费端不需要直接接触所有底层 cubes。

7. 多租户与权限治理的关系

在很多 SaaS 场景里，权限治理与多租户是连在一起的：

• 数据源连接按租户变化；
• 预聚合 schema 按租户变化；
• row-level filters 也可能按租户变化；
• repository / data model 甚至也可能按租户动态切换。

所以在中文教程里，最好把“权限”和“多租户”分开讲，但提示两者在生产里经常耦合。

8. 中文教程里最推荐强调的三点

1）权限要前置到语义层

不要把所有行级过滤逻辑都扔给前端或 Agent。

2）view 是治理入口，不只是语义包装

终端消费者不应该直接接触整张原始语义图。

3）安全上下文是生产设计的核心输入

没有稳定的安全上下文，就很难写出真正可运营的语义权限规则。

一句话总结

Cube 的权限能力让语义层不仅能定义“怎么算”，还能定义“谁能看什么”；在企业环境里，这往往比单纯能跑查询更重要。