EMQX Dashboard

原创

已于 2025-04-02 11:16:28 修改 · 2k 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#emqx #mqtt

于 2025-03-26 17:28:31 首次发布

EMQX Dashboard

EMQX理论基础
https://blog.youkuaiyun.com/liudachu/article/details/146495030

1 Dashboard简介

EMQX 提供了一个内置的管理控制台，即 EMQX Dashboard。方便用户通过 Web 页面就能轻松管理和监控 EMQX 集群，并配置和使用所需的各项功能。

访问地址：http://ip:18083

首次登录访问账号：admin/public

重置密码：

./bin/emqx ctl admins passwd <Username> <Password>

2 访问控制

2.1 认证

2.1.1 创建认证器

认证：就是验证客户端的身份。

创建认证器大致步骤：

1、选择认证方式

2、配置数据源

3、配置数据源相关参数

认证方式说明

目前 EMQX 提供了三种认证方式，包含有：

Password-Based，使用客户端 ID 或用户名加密码的认证方式；
JWT，客户端可以在用户名或密码字段中携带 JWT token 来进行认证；
SCRAM，MQTT 5.0 中的增强认证，可以实现对客户端和服务器的双向认证。

数据源说明

Password-Based

当选择 Password-Based 的认证方式后，用户可以选择存储认证数据的数据库或提供认证数据功能的 HTTP 服务器，数据库包含两类：

EMQX 的内置数据库，即选择 Built-in Database；
外部数据库，支持选择并连接到一些主流数据库，包括：MySQL、PostgreSQL、MongoDB、Redis 等。

除数据库外，还可以直接使用能够提供认证数据的 HTTP 服务，即选择 HTTP Server。

在这里插入图片描述

JWT

如果选择了 JWT 的认证方式，将无需选择数据源。

SCRAM

MQTT 5.0 中的增强认证功能，如果选择了该认证方式的话，目前仅提供了使用 Built-in Database 数据源。

配置参数说明

内置数据库

例如使用内置数据库的话需要选择使用用户名还是客户端 ID，选择密码的加密方式等；如果是选择了 MQTT 5.0 的增强认证，使用内置数据库的话，只需要配置加密方式即可。

在这里插入图片描述

外部数据库

选择外部数据库的话，需要配置能访问到的数据库地址，数据库名称，用户名密码，以及认证相关配置，填写如何从数据库中获取数据的 SQL 语句或其它查询语句等。以 MySQL 为例（注意ip地址不能使用127.0.0.1和localhost）：

在这里插入图片描述

数据库环境准备：

# 创建数据库
docker run -d \
-p 3306:3306 \
-v mysql8_conf:/etc/mysql/conf.d \
-v mysql8_data:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=1234 \
--name mysql8 \
--restart=always \
--privileged=true \
mysql:8.0.30

# 导入资料中的mqtt_user.sql脚本
CREATE TABLE `mqtt_user`  (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `password_hash` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL DEFAULT NULL,
  `salt` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL DEFAULT NULL,
  `username` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 2 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci ROW_FORMAT = Dynamic;

HTTP Server

选择使用 HTTP 服务的话，需要配置请求该 HTTP 服务的请求方式，POST 或 GET 方法。请求地址 URL，注意 URL 内需要填写协议是 http 或 https，如果有端口号的话需要在 URL 中携带端口号。然后是 HTTP 请求的 Headers 配置，携带认证信息的内容需要和请求 HTTP 服务的数据格式相同，然后配置到 Body 字段中，例如将 username 和 password 填写到 JSON 数据中。

在这里插入图片描述

2.1.2 认证列表

创建认证器成功后，可以在认证列表中查看和管理。认证列表的每一栏都可以通过鼠标来拖动调整顺序，或通过操作栏调整列表顺序，顺序对于认证列表来说有一定的重要性，因为EMQX允许创建多个认证器，这些认证器将按照在认证链中的位置顺序运行，如果在当前认证器中未检索到匹配的认证信息，将会切换至链上的下一个认证器继续认证过程。

在这里插入图片描述

认证链的认证流程，以密码认证为例，通常这会产生以下 2 种情况：

当前认证器执行时检索到了匹配的认证信息，例如用户名一致：

1.1 密码完全匹配，则客户端认证通过，允许连接。

1.2 密码无法匹配，则客户端认证失败，拒绝连接。
当前认证器执行时没有检索到匹配的认证信息，例如数据源中没有查找到数据：

2.1 当前认证器之后还有认证器：忽略认证，交由下一认证器继续认证。

2.2 当前认证器已经是链中最后一个认证器：客户端认证失败，拒绝连接。

2.1.3 用户管理

对于使用内置数据库的用户来说，在认证列表页点击 用户管理，可以来到用户管理页面，在该页面，可以管理认证信息，例如添加或删除用户名和密码，也可以通过下载模版，在模版内填充好相关的认证信息，点击 导入 来批量创建认证相关的用户信息。

在这里插入图片描述

2.1.4 客户端连接

当在MQTT的服务端创建完认证器以后，那么此时客户端在进行连接的时候就需要出示认证信息，如果未出示认证信息，那么此时就会报错Error: Connection refused: Bad User Name or Password

在这里插入图片描述

2.2 授权

2.2.1 授权简介

通常情况下，认证只是验证了客户端的身份是否合法，而该客户端是否具备发布、订阅某些主题的权限，还需要由授权系统来判断。在 EMQX 中，授权是指对 MQTT 客户端的发布和订阅操作进行权限控制。

授权检查器链：

1、EMQX支持多种授权检查机制：基于ACL文件(默认配置)、基于内置数据库、基于MySQL进行授权、基于 MongoDB 进行授权、基于 PostgreSQL 进行授权、基于Redis进行授权、基于HTTP应用进行授权 …

2、EMQX 支持用户通过配置多个授权检查器构成授权链，以实现更灵活的授权检查。EMQX 将按照授权链中配置的检查器顺序依次执行授权检查。如果在当前授权检查器中未检索到权限数据，将会切换至链上的下一个启用的授权检查器继续权限检查。

2.2.2 ACL文件授权演示

1、ACL授权说明

EMQX 支持基于 ACL 文件中存储的规则进行授权检查。您可在文件中配置多条授权检查规则，在收到客户端的操作请求后，EMQX 会按照从上到下的顺序进行授权规则匹配；在成功匹配到某条规则后，EMQX 将按设定允许或拒绝当前请求，并停止后续规则的匹配。

在这里插入图片描述

2、文件格式介绍

基本语法和概念如下：

一组授权规则一个花括号包起来，花括号内的各个元素用逗号分隔
每条规则应以 . 结尾
注释行以 %% 开头，在解析过程中会被丢弃

代码示例：

%% 允许用户名是 dashboard 的客户端订阅 "$SYS/#" 这个主题
{
   
   allow, {
   
   user, "dashboard"}, subscribe, ["$SYS/#"]}.

%% 允许来自127.0.0.1 的用户发布和订阅 "$SYS/#" 以及 "#"
{
   
   allow, {
   
   ipaddr, "127.0.0.1"}, all, ["$SYS/#", "#"]}.

%% 拒绝其他所有用户订阅 `$SYS/#`，`#` 和 `+/#` 主题
{
   
   deny, all, subscribe, ["$SYS/#", {
   
   eq, "#"}, {
   
   eq, "+/#"}]}.

%% 如果前面的规则都没有匹配到，则允许所有操作
%% 注意：在生产环境中，最后一条规则应该设置为 `{
    
    deny, all}`，并且配置 `authorization.no_match = deny`
{
   
   allow, all}.

在每一组授权规则中：

1、第一个元素表示该条规则对应的权限；可选值：

allow （允许）
deny（拒绝）

2、第二个元素用来指定适用此条规则的客户端，比如：

{username, "dashboard"}：用户名为 dashboard 的客户端；也可写作{user, "dashboard"}
{username, {re, "^dash"}}：用户名匹配正则表达式 ^dash 的客户端
{clientid, "dashboard"}：客户端 ID 为 dashboard 的客户端，也可写作{client, "dashboard"}
{clientid, {re, "^dash"}}：客户端 ID 匹配正则表达式 ^dash 的客户端
{ipaddr, "127.0.0.1"}：源地址为 127.0.0.1 的客户端；支持 CIDR 地址格式。注意：如果 EMQX 部署在负载均衡器后侧，建议为 EMQX 的监听器开启

proxy_protocol 配置，否则 EMQX 可能会使用负载均衡器的源地址。
{ipaddrs, ["127.0.0.1", ..., ]}：来自多个源地址的客户端，不同 IP 地址之间以 , 区分
all：匹配所有客户端
{'and', [Spec1, Spec2, ...]} ：满足列表中所有规范的客户端。
{'or', [Spec1, Spec2, ...]} ：满足列表中任何规范的客户端。

3、第三个元素用来指定该条规则对应的操作：

publish：发布消息
subscribe：订阅主题
all：发布消息和订阅主题
从 v5.1.1 版本开始，EMQX 支持检查发布与订阅操作中的 QoS 与保留消息标志位，您可以在第三个元素中加上 qos或者retain来指定检查的 QoS 或保留消息

标志位，例如：
- {publish, [{qos, 1}, {retain, false}]}：拒绝发布 QoS 为 1 的保留消息
- {publish, {retain, true}}：拒绝发布保留消息
- {subscribe, {qos, 2}}：拒绝以 QoS2 订阅主题