RBAC

NereidAI 把身份与授权分开。套件身份平面证明用户是谁；各产品决定该用户 能做什么。本页描述套件共享层面的角色访问控制模型。

身份与授权

• 套件提供身份：稳定的主体、邮箱、显示名，以及一小组粗粒度套件角色 （user、operator、admin）。
• 各产品拥有授权：其角色、权限模型与数据范围完全是产品本地的。产品不发明 新的套件角色名；它们把粗粒度套件角色映射到自身细粒度权限。

身份平面还以形如 /nereid{product}/{tenant}/{role} 的 realm 组存储每用户、每产品 的租户与角色分配。产品按自己的 nereid{product} 前缀过滤这些组——因此同一个账号 可以在不同产品中持有不同的租户与角色。

默认拒绝的产品访问

访问默认拒绝，并在套件入口处设卡：

• 对某产品没有分配组的用户无法进入该产品。拥有账号只意味着能登录门户并接收 分配。
• Realm 管理员是例外：他隐含地管理每个产品，因此新部署的引导管理员永不会被 锁在门外。
• 移除某产品的最后一个分配会在下次登录时吊销访问权，因为产品在每次登录时都会 依据分组对账其成员关系。
• 产品在自身回调上实施同样的边界：只消费属于自己的分组，若没有则拒绝建立会话。

并非每个账号都是产品授权

operator 套件角色授予对门户账号控制台的访问，但不自动成为产品授权—— 运维人员仍需持有产品分组才能进入产品。

租户感知的访问

多租户是产品概念，不是集群边界。各产品把分配组中的租户段映射到自己的租户模型， 从而把访问限定在用户被分配的租户（在部分产品中还包括组织）内。身份平面刻意不发明 自己的租户语义。

例如，Horizon 通过其角色把用户绑定到 Open Horizon 的组织：跨组织的 platform 角色，以及绑定到某个组织的 partner 角色（多个 partner 分配会变成 可切换的组织）。其他产品使用各自的租户形态——模式相同，词汇是产品本地的。

权限点与数据范围

产品的 RBAC 通常回答两个彼此独立的问题，两者都收口才使模型成立：

问题	由什么决定	示例
调用者能做什么？	角色上的权限点	创建设备、下发命令、编辑规则
能触达哪些数据行？	数据范围（租户 / 客户 / 分组）	仅其被分配分组内的设备

Link 是一个很好的例证：权限决定调用者能做什么，数据范围决定其能触达哪些行， 并在存储层对读写两侧收口。这样，一个能读取设备的角色也无法触达其范围之外的设备； 该原则同样适用于实时推送——受限成员的通配订阅会在服务端物化为其被允许看见的设备集， 推送的帧因此不跨租户、不越权。

审计

授权决定以及其允许的操作都会被记录。Link 的审计日志是追加式、可防篡改的 哈希链——每条记录与前一条串联，并以每日封存锚定，可在线验链、防篡改。分发控制台 保有自己的追加式审计轨迹，覆盖控制台与 API 活动，并把每个操作归属到某个用户或某个 API 密钥。

账号治理

门户的账号控制台以服务账号客户端对着身份平面管理身份：创建、启用 / 停用、重置密码、 分配套件角色。由客户 IdP 联邦而来的账号在控制台中只读展示——其生命周期（密码、 MFA、锁定、注销）由客户的身份系统拥有。

没有通用角色清单

套件只共享上述粗粒度角色。具体角色清单——租户管理员、工程师、只读用户、 platform/partner 运维人员等——都是按产品定义，并随该产品文档化。

运维文档

产品特有的角色定义、权限表与审计保留设置在各产品仓库中： github.com/NereidAI。

相关

• SSO 与 OIDC —— 身份如何到达产品。
• 安全总览 —— 完整基线。