告别裸奔，聊聊主流消息队列的认证和鉴权！

大家好，我是君哥。

我们在使用消息队列时，经常关注的是消息队列收发消息的功能。但好多时候需要对客户端有一定的限制，比如只有持有令牌的客户端才能访问集权，不允许 Producer 发送消息到某一个 Topic，或者某一个 Topic 只能给固定 Consumer 消费。

为了能对客户端有一定限制，需要对消息队列进行认证和鉴权，今天我们就来聊一聊主流消息队列是怎么做认证和鉴权的。

1 认证

认证是指通过一定手段，对访问用户身份进行校验，只有校验通过的用户，才允许访问。

默认情况下，主流消息队列是不开启认证的，这也意味着只要网络能通，客户端就可以访问 Broker 集群，可以说集群处于“裸奔”的状态，有很大的风险。

消息队列的认证，是指对客户端进行身份确认，只有认证通过的客户端才可以访问 Broker 集群资源。

常见的认证的方式有很多，主流消息队列一般会定义一个认证框架来制定认证规则，然后通过实现这个框架来定义具体认证方式。

1.1 SSL/TLS

SSL(Secure Sockets Layer)是为网络通信提供安全及数据完整性的一种安全协议，消息队列基于 SSL 的认证是指 Broker 和客户端的认证，可以是单向认证，也可以是双向认证。

消息队列为了提升吞吐量，降低延迟，一般都是基于 TCP/IP 协议构建的，SSL 协议位于应用层和传输层之间。

使用 SSL 进行通信前，客户端和 Broker 都需要引入各自的证书，并且引入对应编程语言的 SSL 库。通信时，客户端携带对应的证书和公钥信息，与 Broker 建立连接，Broker 则对客户端进行认证，认证成功后，客户端才能进行下一步操作。

Kafka 在早期的 0.9 版本引入了 SSL。

SSL3.0 版本后改名成 TLS，TLS 是 SSL 的升级版本。Pulsar 和 RabbitMQ 这 2 个消息队列支持 TLS。

1.2 SASL

SASL 全称是 Simple Authentication and Security Laye，是一种标准化的 C/S 身份认证协议，客户端和服务器基于这个协议交换身份信息，验证成功后才可以建立连接。

SASL 其实是一中认证框架，基于这个框架我们可以实现多种认证机制，比如用户名密码、Kerberos、NTLM、OAuth等。

Kafka 0.9.0.0 版本开始支持 SASL，并且基于 SASL 实现了多种认证插件。如下图：

GSSAPI 是用来支持 Kerberos 协议的，如果公司已经做过 Kerberos 认证，那使用 GSSAPI 会非常方便。
PLAIN 是一种使用用户名密码的认证机制，可以跟 SSL 搭配使用，更加适合小公司的 Kafka 集群使用。PLAIN 有一个很大的缺点就是增加或删除用户，需要重启 Broker 集群才能生效，因为认证用户保存在静态文件中，Broker 集群不能动态加载。
SCRAM 将认证用户保存在 ZooKeeper，解决了 PLAIN 增加或删除用户需要重启集群的问题。
OAUTHBEARER 是 Kafka 在 2.0 版本引入的，主要是为了实现 OAuth2 认证机制。
Delegation Token 是 SASL 机制的补充，它是基于 Token 的一种认证机制，它的特点是非常轻量级，用户获取到一次 Token 之后，后面的请求过程中可以继续使用这个 Token(除了 Token 更新)，无须再次获取。

1.3 AK/SK

RocketMQ 基于 AK/SK 实现认证方式，通过对称加密来验证客户端身份，保证认证密码不会以明文在网络上传输，提升认证安全。

客户端发送请求时，使用加密算法对请求参数进行加密，然后生成数字签名，在请求中发送用户名和签名信息。Broker 收到请求后，首先查询用户名是否在本地库(不存在则认证失败)，如果存在，则用相同的算法对请求进行加密和签名，然后比较签名结果跟客户端请求中的签名信息是否一致。

1.4 自定义框架

RabbitMQ 和 Pulsar 都提供了自定义、可插拔的身份认证框架，然后基于框架的接口来实现各种认证插件，在配置文件中指定要使用的认证插件。

Pulsar 内置的认证插件包括 JWT、OAuth2.0、Athenz、Kerberos 等。

RabbitMQ 实现的认证插件包括 AMQPLAIN 和 PLAIN。

总结：认证框架的选择很多，Kafka 选择的 SASL 机制更加完善，功能更加强大，实现起来也更加复杂。而自定义的机制则实现更加简单，同时也能满足消息队列的认证需求。

下面对主流消息队列使用的认证方式总结如下：

消息队列	认证方式
Kafka	SASL：GSSAPI、PLAIN、SCRAM、OAUTHBEARER、Delegation Token
RocketMQ	AK/SK
RabbitMQ	AMQPLAIN、PLAIN
Pulsar	JWT、OAuth2.0、Athenz、Kerberos

2 鉴权

客户端通过认证后，就跟 Broker 建立了连接，但是并不是每个客户端都可以操作所有的集群资源，比如银行里面的不同业务数据不能给所有客户端访问。这就需要对客户端做资源访问限制。

授权是指对客户端赋予一定的权限，比如允许客户端从某一个 Topic 拉取消息。

消息队列对于资源的操作分为两种，一种是运维相关操作，比如创建 Topic、创建用户等，权限一般分配给运维人员。另一种是数据相关操作，包括生产消费消息，权限一般分配给业务系统客户端。

要实现资源控制，一般分成两种方式，下面详细介绍一下。

2.1 链路分开

如果分开两条链路来操作集群资源，一条链路由运维人员来通过 HTTP 来操作集群资源，另一条链路由业务系统客户端通过 TCP 来收发消息，这样实现权限控制就非常容易，成本很低。

主流消息队列 Pulsar 和 RabbitMQ 就是这种方式实现的。

这种方式也有一个问题，就是集群中需要开启两个 Server 来服务两个链路。

2.2 一条链路

跟两条链路相对应的是，运维操作和业务客户端操作都通过一条链路来实现。

一条链路的方式集群不用启动两个 Server，但是需要根据用户来分配权限，需要在代码层面实现集群的资源控制，实现难度较大。主流消息队列中的 Kafka 和 RocketMQ 就是用的这种方式。

2.3 访问控制

无论是两条链路还是一条链路，都无法细粒度地控制集群资源。比如运维操作要限制某个用户只能添加 Topic 而不能删除 Topic，业务系统客户端只被允许从某一个 Topic 发送和消费消息。

想要细粒度的控制集群资源，就需要引入鉴权模型，常见的鉴权模型如下：

ACL：Access Control List，也就是访问控制列表，特点是直接把用户和权限关联起来。
RBAC：Role Based Access Control，基于角色的权限控制，特点是引入了角色的概念，先将资源权限分配给角色，再把角色分配给用户。
ABAC：Attribute Based Access Control，基于属性的权限控制，是一种动态授权策略，他把用户要访问的资源跟资源的属性、环境因素结合起来，比如对一个资源的访问限制到时间级别。
PBAC：Policy Based Access Control，基于策略的权限控制，可以基于任务或事件等其他不同的场景灵活配置访问权限。

2.4 ACL

主流的消息队列都是基于 ACL 来实现鉴权的。要实现 ACL(Access Control List) ，首先需要定义好集群中有哪些资源或哪些操作需要做鉴权。

主流消息队列中，Kafka 的资源或操作定义非常细致，资源包括：Topic、消费者组、Broker 集群等，操作则包括：读、写、创建、删除、修改、订阅等。Kafka 对资源的操作定义成不同接口(比如创建 Topic)，通过接口来做鉴权控制。见官网 KIP-11 下面链接。

https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+Interface

Kafka 实现了可插拔的授权机制，该机制把所有 ACL 项保存在 ZooKeeper，Zookeeper 创建 /kafka-acl 节点进行保存。Kafka 提供了 kafka-acls 脚本，可以动态修改 ACL 配置项，并且可以立即生效。在 server.properties 中加入下面配置，就可以开启 ACL 鉴权：

authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer

其中 SimpleAclAuthorizer 是 Kafka 自带的鉴权实现类，这里也可以配置自定义的鉴权实现类。

RabbitMQ 的架构相对简单，定义的资源主要包括：Exchange、Queue 等，操作则包括读、写、配置。因为 RabbitMQ 的集群配置是通过 HTTP API 操作，所以并没有提供接口维度的权限控制。

Pulsar 的鉴权包括生产、消费、Lookup、Function、Source(从数据源读取数据)、Sink(数据存入下游)、Packages(保存用户代码包)。鉴权信息保存在 Zookeeper 的 /admin/policies/[namespace] 目录下。Pulsar 也支持可插拔的授权框架，默认实现类是 PulsarAuthorizationProvider。

RocketMQ 中的 ACL 提供了 Topic 资源级别的用户访问控制。用户在使用 RocketMQ 权限控制时，可以在 Client 客户端通过 RPCHook 注入 AccessKey 和 SecretKey 签名，同时将对应的权限控制属性（包括 Topic 访问权限、IP 白名单和 AccessKey 和 SecretKey 签名等）设置在 distribution/conf/plain_acl.yml 的配置文件中。

RocketMQ 对 Topic 资源访问权限控制定义了四种，下面表格来自官网，