OneUptime 用户、团队与权限模型完全指南从角色与作用域到授权判定源码解析【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime导读OneUptime 的一切资源都运行在项目Project之内而谁能在这个项目里做什么由三个要素决定项目中的用户Users、用户所属的团队Teams以及授予这些团队的权限Permissions。本文以 权限官方文档 为主线结合仓库源码深入讲解这套 RBAC 模型的核心规则、角色与细粒度权限、作用域Scope、所有人与标签机制、API 密钥授权以及 OneUptime 判定一次请求是否被允许的完整决策链。读完你将能够独立设计一套最小权限 分域治理的团队权限方案并理解其底层实现原理。权限模型一览一条规则解释几乎所有行为OneUptime 权限体系的根本规则只有一条用户永远不直接持有权限。一个用户的访问权限等于他在该项目中所有团队成员身份所对应权限的并集Union。因此想改变某人能做什么只有两条路径修改他的团队成员身份或修改他所在团队的权限。这套模型可以抽象为下面的结构Proyecto项目 └── Equipo团队 ← 权限挂载在这里 ├── Permisos permitidos ← 允许权限每个都带作用域全部 / 自有 / 标签 ├── Permisos bloqueados ← 阻止权限永远优先于允许权限 └── Miembros del equipo ← 团队成员已接受邀请的用户概念含义用户User一个 OneUptime 账号。一次登录可加入任意数量的项目。项目Project租户边界。监控器、事件、团队和数据都只属于某一个项目。团队Team项目内一个有名字的权限载体。团队成员Team member被邀请到团队并已接受邀请的用户。权限Permission一个具体能力例如CreateProjectMonitor或一个聚合多个能力的角色例如MonitorAdmin。作用域Scope允许权限能影响的范围全部资源、仅自有资源、或仅带标签的资源。所有人Owner被标记为某个具体资源负责人的用户或团队。标签Label打在资源上的标记用于限制权限和资源组织。用户账号是全局的进入项目靠的是团队OneUptime 的用户账号对实例是全局的同一登录凭据可用于该用户被邀请进入的所有项目。判断一个用户是否在某个项目里唯一标准是它是否是该项目至少一个团队的成员——没有单独的添加用户到项目步骤邀请某人加入项目本质上就是邀请他加入团队。围绕用户有几个关键行为邀请会创建一个待定pending的团队成员记录用户只有在接受邀请之后才被算作项目成员也才获得任何权限。将用户从项目所有团队中移除即收回其对该项目的访问权。若项目强制启用 SSO而某用户尚未通过身份提供方认证则该用户被视为未授权的 SSO 用户在完成认证前看不到任何内容详见 SSO 文档。配置 SCIM 后身份提供方可以自动创建、更新和删除用户及其团队成员关系详见 SCIM 文档。这一设计在源码中有直接对应在 UserPermission.ts 中getDefaultUserTenantAccessPermission给每个用户注入两个自动权限——CurrentUser与UnAuthorizedSsoUser。注释明确指出这套默认权限同样被赋予尚未满足项目 SSO 要求的用户这类用户在通过 SSO 之前不会被当作正式成员。也就是说成员身份与SSO 通过在代码层面是被严格区分的。另外同一文件中的withProjectUserPermissionUserPermission.ts解释了另一个容易忽视的细节ProjectUser权限不存储在团队权限表中它是成为项目成员这件事本身的意义所在——共享工作区资源保存的表格视图、标签、团队、成员资料都通过它来读取。因此即使某用户的团队只授予了MonitorViewer这类领域角色他仍然会获得隐式的ProjectUser权限否则仪表盘连该角色本应让其访问的页面都无法渲染。该注入发生在缓存读取与刷新两条路径上保证旧缓存快照不会把成员锁在门外。界面入口Settings → Users会列出项目内所有成员及其邀请状态。团队权限到达人的唯一通道每个新项目默认创建三个团队团队持有的权限是否可编辑OwnersProjectOwner否。始终至少保留一名成员。AdminProjectAdmin否MembersProjectMember是——这是起点可自由修改Owners与Admin团队是被刻意锁定的权限不可编辑团队不可删除或重命名。这是防止项目意外把自己锁死的关键机制——Owners团队必须始终至少保留一名成员。权限层级上ProjectOwner是最高访问级别包含计费、删除项目以及管理员能做的一切。ProjectAdmin覆盖除计费与删除项目之外的一切。这一差异在源码中同样清晰可见在 APIKey AccessPermission.ts 中Master Key 的租户权限被构建为在默认权限基础上追加Permission.ProjectOwner——可见ProjectOwner是源码中最顶层的权限标记。除这三个内置团队外你可以随意创建任意数量的自定义团队——前端值班组支持组只读审计组——并分别授予所需权限。界面入口Settings → Teams。打开一个团队即可看到Members成员、Permissions权限与Block Permissions阻止权限三个页签。权限角色与细粒度权限两种授予方式权限是单一的具体能力团队Permissions页签提供两种授予方式。角色Roles按产品域批量授予角色把整个产品域打包成三个级别之一Admin— 该域的完全控制权包括其配置严重级别、状态、模板。Member— 日常工作创建、编辑、删除资源但不能重新配置该域。Viewer— 只读。例如MonitorAdmin、IncidentMember、StatusPageViewer等。文档强调大多数场景都应优先使用角色因为 OneUptime 新增功能时新的监控相关表会自动并入既有监控角色而无需你追加新的授权——角色不会随产品演进而过时。所有角色列表可以在 权限参考 中找到。该参考页面由 OneUptime 源码在请求时实时生成与仪表盘、API 和 Terraform Provider 使用的是同一份列表因此不可能与产品漂移也始终反映你正在运行的版本。细粒度权限Granular permissions精确授予单一能力每个独立能力也可以单独授予CreateProjectMonitor、ReadProjectIncident、DeleteProjectStatusPage等。当角色范围过宽、只需授予恰好一件事时使用细粒度权限。细粒度权限的键同时也是创建API 密钥API Keys时使用的键API与Terraform Provider所期望的键。权限参考文档中明确指出Permission Key 列就是调用 API、CLI 与 Terraform Provider 时要使用的值而表格标题列则是仪表盘中显示的名称。允许与阻止Allow and Block每个团队持有两张列表Permissions允许— 该团队可以做什么。Block Permissions阻止— 该团队永远不能做什么无视任何允许条目。阻止永远优先Block always wins一条不带标签的阻止条目直接彻底收回该团队的这一能力一条带标签的阻止条目只对携带这些标签的资源生效——典型场景是这个团队可以编辑监控器但标了 Production 的除外。还有两条容易踩坑的规则一个权限不能同时在两张列表里带限制标签OneUptime 会拒绝第二次操作并给出说明由于用户的访问权是所有团队成员身份的并集一个团队上的阻止不会抵消另一个团队上的允许——阻止只约束它所在的团队本身。如果发现某人权限超出预期请逐一检查他所属的每一个团队。作用域Scope允许权限能走多远每一条允许权限在授予时都要选择一个作用域作用域含义项目内全部资源All resources in the project默认值。权限适用于所有匹配的资源。本团队或成员所有Owned by this team or its members权限仅适用于本团队或当前操作者被列为所有者的资源。按标签限制Restrict by labels高级权限仅适用于携带至少一个所选标签的资源。Owned自有是构建各人照管各人服务模型最简洁的方式给团队授予MonitorAdmin并限定为 Owned然后把这个团队设为其负责监控器的所有者。需要留意Owned 作用域只会收窄可以拥有所有者的资源——监控器、事件、仪表盘、服务等而项目配置事件状态、标签、团队本身没有所有者因此 Owned 作用域的角色在这些配置上行为与普通角色无异。Labels标签是同一种思路更手动化的版本先给资源打标签再授予限定在这些标签上的权限。文档还特别提到某些角色天然是项目级的不提供作用域选择——因为Billing Admin但只针对属于我的计费没有任何意义。这类豁免角色会在仪表盘中直接不显示作用域选项。所有者Owners负责与通知而非权限所有者是被关联到某个具体资源的用户或团队。绝大多数代表你运维的东西的资源——监控器、事件、告警、计划维护、值班策略、仪表盘、服务、状态页、工作流、Runbook 与 SLO——都有Owners页签。所有者承担两个职责通知Notification资源发生状况时监控器宕机、创建事件、SLO 开始烧掉错误预算OneUptime 通知的就是所有者。访问Access当你要求时所有权正是Owned作用域解析的依据——用户本人是所有者在列或其所隶属的某个团队是所有者即匹配。这里有一条反直觉但极其重要的原则所有权本身不授予任何权限。作为某监控器的所有者并不允许你编辑它除非你所属的某个团队还持有监控器相关权限。所有权只会收窄访问范围永远不会放大它。这与Owned作用域的语义完全自洽所有者身份是过滤条件而不是授权凭证。标签Labels组织 权限限制的双重工具标签是项目级范围的标记贴在资源上有两个用途仪表盘中的过滤与分组以及上述的权限限制。标签限制的满足条件是资源携带权限上至少一个标签即可一个完全没有标签的资源不满足任何按标签限制的权限。界面入口Settings → Labels。API 密钥直接授予不走团队API 密钥与用户走的是完全不同的授权路径——权限直接授予在密钥自身密钥不属于任何团队也不受团队归属影响可以分配与给团队相同的细粒度权限和角色密钥支持阻止权限与标签限制与团队一致密钥不支持 Owned 作用域——因为所有权是针对用户解析的而密钥不是用户所以必须显式授予密钥所需的访问权。最佳实践为每个集成单独创建一个密钥只授予能跑通的最窄权限集这样撤销一个密钥不会影响其他集成。这套逻辑在源码中有精确实现。在 APIKey AccessPermission.ts 中getDefaultApiGlobalPermission为密钥注入Public、User、CurrentUser、AuthenticatedRequest四个全局标记权限getApiTenantAccessPermission通过ApiKeyPermissionService.findPermissionsByApiKeyId只取出该密钥在该项目的权限行含labelIds与isBlockPermission拼接到默认权限之上——这与文档权限直接挂在密钥上的描述一一对应文件中还解释了AuthenticatedRequest是一个标记而非能力它代表某个已认证主体发起了调用不出现在权限选择器中也不会被逐密钥授予或撤销。它存在是为了让密钥在访问 File 等资源时不会被误判为只是某个登录用户而被限制到自有行密钥没有 userId永远无法满足用户自有行条件。界面入口Settings → API Keys。更多调用方式参见 API 参考。授权判定OneUptime 如何决定一次请求是否被允许对于已登录用户判定按以下顺序执行找团队找出该用户在此项目中属于的所有团队只统计已接受的邀请。收集权限行汇总这些团队上的所有权限行——允许与阻止各自携带标签与作用域。先查阻止列表一条匹配的、不带标签的阻止条目立即拒绝该请求。再查允许列表请求至少需要一个目标表针对该操作所接受的权限。应用作用域Owned 作用域的授予把查询收窄到自有资源标签作用域的授予收窄到匹配标签。如果同一操作存在其他更宽的授予更宽的生效。应用标签阻止带标签的阻止条目在目标资源携带其中任一标签时拒绝请求。此外每个已登录用户还自动持有一小组权限覆盖读取自己的资料、自己的通知规则等场景——这些不是管理权限也不会解锁任何他人的数据。缓存机制解析后的权限按用户 项目维度缓存并在团队成员关系或团队权限变化时刷新。如果修改权限后用户没有立刻看到变化让该用户刷新页面即可。源码对这一机制提供了完整佐证。在 UserPermission.ts 中缓存键被格式化为${userId}:${projectId}带分隔符避免两个 ObjectID 拼接无边界导致碰撞GET此处与 SETAccessTokenService.refreshUserTenantAccessPermission都经由buildTenantPermissionCacheKey这一个助手方法保证两者不会漂移。同时缓存条目默认存活 30 天GlobalCache.setString的默认 TTL除非团队或成员关系变更先行重写它——这正是改完权限要等刷新的底层原因。实战配方Recipes文档给出了五组可以直接照搬的权限设计模式只读观察团队创建团队添加Viewer角色或按需只添加某些区域的*Viewer角色。值班工程师管理自己的服务给团队MonitorAdmin、IncidentMember、OnCallMember三个角色且作用域限定为Owned然后把团队设为其运维监控器的所有者。外部承包商远离生产环境以All作用域授予所需角色再对敏感能力添加阻止权限并限制到Production标签。只上报部署的 CI 流水线创建一个仅含所需细粒度权限、不含任何角色的 API 密钥。不该看到计费的人不要将其加入 Owners 团队——ProjectAdmin本身就不含计费权限。延伸阅读权限参考Permission Reference — 全部角色与细粒度权限由 OneUptime 源码实时生成。SSO 与 SCIM — 认证与用户自动供给。API 参考 — 在 API 中使用权限。相关源码用户权限解析与缓存、API 密钥权限构建、团队权限数据模型。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考