跳到主要内容

角色与权限矩阵

内置角色、自定义角色，以及各自授予哪些菜单和 API 操作。

角色管的是第一层权限：能进哪些页面、能调哪些接口。能操作哪些数据是第二层， 由业务组成员关系决定，两层是且的关系。这页只讲第一层。

权限点长什么样​

一个角色就是一组「权限点」。权限点的名字看起来像路由，但它是后端接口上的一个标记， 不是 URL：

/alert-rules        看告警规则
/alert-rules/add    新增
/alert-rules/put    修改
/alert-rules/del    删除

绝大多数资源都是这套 查看 / add / put / del 四件套。少数只有一个名字的权限点 （比如 /alert-his-events、/system/site-settings）只控制菜单显不显示， 后端不会因为缺它而拒绝请求。

人员组织 → 角色管理里，权限点按 7 个分组折叠：

分组中文权限点数覆盖
Infrastructure基础设施4机器的查看、修改、删除、绑定未归组机器
Explorer数据查询20指标、日志、快捷视图、内置指标、记录规则、索引模式、仪表盘
alerting告警22告警规则、屏蔽、订阅、自愈脚本与任务、活跃与历史事件
Notification通知18通知规则、通知媒介、消息模板、工作流
Integrations集成中心9数据源、模板中心、系统集成
Organization人员组织16用户、团队、业务组、角色
System Settings系统配置7站点、变量、单点登录、告警引擎、关于产品、大模型配置、技能管理

一共 96 个。逐条的对照表——每个权限点由哪个内置角色持有、卡住哪些接口——在 权限矩阵。

三个内置角色​

角色覆盖范围
Admin跳过权限检查，等于持有全部 96 个；同时也不受业务组边界约束
Standard53 个。日常使用够了，但不含通知类、数据源、系统配置和角色管理
Guest6 个，全是查询：指标、快捷视图、日志、链路，以及两个帮助页

一个用户可以同时挂多个角色，最终权限是并集。

Standard 拿不到的那一批值得单独记一下，因为它常常和「标准用户」这个名字给人的 印象不符：/notification-rules、/notification-channels、/notification-templates、 /event-pipelines、/datasources、/components、/embedded-products、/roles、 /system/*、/users/add|put|del。也就是说，一个 Standard 用户能写告警规则， 但配不了通知媒介，也看不到数据源列表。要放开就自定义角色。

建一个自定义角色​

角色管理角色管理
  1. 人员组织 → 角色管理，左侧「角色列表」标题旁的 +；
  2. 填名称和备注。名称就是它在用户表单里显示的字符串，建议用英文，不要带空格；
  3. 保存后在左侧选中它，右侧勾权限点。全部展开 / 全部折叠帮你快速扫一遍；
  4. 勾完点权限树下方的保存，弹窗确认。选中 Admin 时这个按钮不出现。

预期结果：接口层面立刻生效，不用重启进程；把这个角色挂到某个用户身上， 那个用户刷新页面后，侧栏里只剩勾中的菜单。

做减法比做加法安全：先从 Guest 的 6 个点起步，缺什么补什么。一次性照着 Standard 全勾再删，很容易漏掉一个写权限。

几个反直觉的地方​

  • Admin 角色改不了。 界面上它的权限点全是勾中且置灰的；接口层面也会直接拒绝 （admin role can not be modified）。想要「弱化版管理员」，新建一个角色。
  • Standard 有完整的 /busi-groups 增删改权限。 也就是默认配置下， 一个普通用户可以建业务组、也可以删掉他有权限的业务组。真要收口就自定义角色， 把这四个点摘掉。
  • /alert-mutes 少一个 put。 Standard 有 add 和 del，没有 put—— 屏蔽规则能建能删，但改不了。这是种子数据的历史遗留，不是设计。
  • 数据源只有 Admin 能改。 /datasources 这个点只控制「能不能看到数据源列表页」， 新增、修改、删除一律要求 Admin；非管理员调列表接口拿到的记录里， 地址、请求头、证书和账号密码都已经被抹掉。
  • 系统配置类的点同理。 /system/site-settings、/system/sso-settings 只管菜单可见， 真正的保存动作都要求 Admin。变量设置是例外，见站点与用户变量。

下一步​

本页目录