# 角色与权限矩阵

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

最后校对于 2026-10-10

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

## 权限点长什么样[​](#权限点长什么样 "权限点长什么样的直接链接")

一个角色就是一组「权限点」。权限点的名字看起来像路由，但它是后端接口上的一个标记， 不是 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 个。逐条的对照表——每个权限点由哪个内置角色持有、卡住哪些接口——在 [权限矩阵](https://n9e.github.io/zh/docs/reference/permissions.md)。

## 三个内置角色[​](#三个内置角色 "三个内置角色的直接链接")

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

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

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

## 建一个自定义角色[​](#建一个自定义角色 "建一个自定义角色的直接链接")

![角色管理](https://n9e.github.io/zh/img/docs/security/roles.zh.webp)![角色管理](https://n9e.github.io/zh/img/docs/security/roles.zh.dark.webp)

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`。变量设置是例外，见[站点与用户变量](https://n9e.github.io/zh/docs/security/variables.md)。

## 下一步[​](#下一步 "下一步的直接链接")

* 逐个权限点的完整对照表：[权限矩阵](https://n9e.github.io/zh/docs/reference/permissions.md)
* 第二层权限怎么配：[业务组授权](https://n9e.github.io/zh/docs/security/business-groups.md)
* 两层是怎么合在一起的：[认证、Token 与 RBAC 模型](https://n9e.github.io/zh/docs/concepts/auth-rbac.md)