基于Ory Keto实现含对象所有权的RBAC权限方案咨询

你当前逐资源配置权限继承规则的写法会产生大量冗余配置，核心是没有利用Keto命名空间级通用规则、通配符资源、主体集继承的能力，以下是可直接落地的实现方案，三类权限可完全打通，无重复配置。

核心设计原则 #

所有权限传导逻辑统一在命名空间层定义，不针对单个资源配置继承关系。后续业务流转只需要维护「主体-资源」的关联关系，不需要重复编写权限规则，Admin全局权限、资源所有权、自定义角色/用户组权限走同一套校验链路，不需要业务层做特殊分支判断。

具体实现步骤 #

1. 定义命名空间通用规则 #

提前规划4类命名空间，所有权限继承规则一次性配置完成：

namespace Product
  // 定义基础操作权限
  permission view
  permission create
  permission update
  permission delete
  permission purchase // KYC用户专属附加权限

  // 定义资源关联关系
  relation owner: User | Role#member
  relation kyc_allowed: Role#member

  // 权限继承规则：所有CRUD权限默认授予owner
  permission view = owner
  permission create = owner
  permission update = owner
  permission delete = owner
  // 附加购买权限授予KYC认证角色成员
  permission purchase = kyc_allowed

namespace Role
  relation member: User | Role#member // 支持角色/用户组嵌套

namespace User

2. 一次性配置全局规则 #

全局Admin权限只需要配置一次，永久生效，不需要逐资源绑定：

// 所有Admin角色成员，默认持有所有产品资源的owner身份
products:*#owner@(roles:Admin#member)

3. 业务侧日常关系配置 #

后续所有业务操作只需要添加三类关联关系，无任何重复规则配置：

• 授予资源所有权：用户创建产品时，只需要写入一条关联关系，自动获得该产品全部CRUD权限

  // UserA持有ProductA所有权
  products:ProductA#owner@UserA
  

• 绑定Admin角色：给用户分配超管身份时，只需要将用户加入Admin角色，自动获得所有产品的CRUD权限，校验逻辑和普通资源所有者完全一致

  // UserB绑定Admin角色
  roles:Admin#member@UserB
  

• 配置附加业务权限：给用户绑定KYCVerified角色/加入对应用户组时，自动获得对应附加权限，支持角色、用户组嵌套

  // 配置KYCVerified角色和产品附加权限的关联（一次性配置）
  products:*#kyc_allowed@(roles:KYCVerified#member)
  // UserA绑定KYCVerified角色
  roles:KYCVerified#member@UserA
  

方案优势 #

• 无冗余配置：所有权限逻辑在命名空间层统一定义，新增资源、用户、角色时不需要重复编写继承规则
• 逻辑完全兼容：Admin全局权限、资源所有权、自定义角色权限走同一套校验链路，不需要在业务代码中写特殊判断
• 扩展性强：后续新增资源类型、权限点、角色时，只需要在对应命名空间添加少量规则，不影响存量配置

注意事项 #

• 通配符资源匹配能力要求Keto版本≥v0.8.0，部署前请确认版本符合要求
• 角色/用户组嵌套层级建议控制在3层以内，避免权限校验查询耗时过长
• 如果需要更细粒度的权限划分（例如产品编辑者仅能修改内容无法删除资源），只需要在对应命名空间新增relation和permission映射即可，和现有逻辑无冲突

内容的提问来源于stack exchange，提问作者KittyCat