点击上方“zhisheng”，选择“设为星标”

回复”送书“可参与书籍抽奖

今年有很多小伙伴在公众号或者微信留言问能不能整一篇有关Kafka权限管理的文章，迫于工作关系，这个需求一直拖后。后来知道我的好友兼Kafka高玩 —— 【一岁小宝 】他一直在弄这一块的东西，所以我就厚着face皮去催他整一篇，也就是你们接下来看到的内容。本文原文地址：https://www.jianshu.com/p/09129c9f4c80。

有关Kafka权限管理的资料可谓是少之又少，当你遇到这块内容的时候，如果靠自己摸索的话会耗费很长的时间。如果现在还没有接触到这一块，也建议收藏本文，以备不时之需。

本片篇幅很大，在编辑本文的时候，右下角字数统计18000字（算上了英文字符，tx的字数统计有点怪异），建议先马后看。

一、概述

1、Kafka的权限分类

1）、身份认证（Authentication）：对client 与服务器的连接进行身份认证，brokers和zookeeper之间的连接进行Authentication（producer 和 consumer）、其他 brokers、tools与 brokers 之间连接的认证。

2）、权限控制（Authorization）：实现对于消息级别的权限控制，clients的读写操作进行Authorization：（生产/消费/group)数据权限。

2、实现方式

自0.9.0.0版本开始Kafka社区添加了许多功能用于提高Kafka群集的安全性，Kafka提供SSL或者SASL两种安全策略。SSL方式主要是通过CA令牌实现，此文主要介绍SASL方式。

1）SASL验证:

2）SSL加密: 使用SSL加密在代理和客户端之间，代理之间或代理和工具之间传输的数据。

二、使用SASL进行身份验证

1、SASL/PLAIN验证

1.1 版本

1.2 Zookeeper配置

1）修改zoo.cfg增加两行配置：

2）配置JAAS文件：

说明：定义了需要链接到Zookeeper服务器的用户名和密码

3）加入需要的包：

如果没有引入对应的kafka包，启动kafka时会报找不到org.apache.kafka.common.security.plain.PlainLoginModule包的错误。

Zookeeper引入加载包需改Zookeeper脚本zkEnv.sh，在最后加入：

将for_sasl目录下的所有jar文件追加到CLASSPATH变量，再设置一个JVM参数给SERVER_JVMFLAGS变量，这两个变量都会在Zookeeper启动时传给JVM。

4）启动Zookeeper

1.3 Kafka服务端配置

1）kafka增加认证信息：

创建JAAS文件：

user_XXX 为自定义的用户，所有可以使用的用户必须在此定义，不能再之后新增。

• producer用于开放生产权限。

• consumer用于开放消费权限。

JAAS文件定义了链接Kafka Broker时所需要的用户名密码及broker各个节点之间相互通信的用户名密码：

• username/ password：broker之间通信使用的用户名密码。

• user_admin/user_producer/user_consumer：客户端（管理员、生产者、消费者）链接broker时所使用到的用户名密码。

2）配置server.properties

3）修改启动脚本

1.4 Kafka客户端端配置

1）创建JAAS文件：消费者：kafka_client_consumer_jaas.conf

生产者：kafka_client_producer_jaas.conf

2）修改客户端配置信息：分别在producer.properties和consumer.properties添加认证机制

consumer.properties中额外加入分组配置

3）修改客户端脚本指定JAAS文件加载：

1.5 授权

此时已经完成了基本的配置，但是如果测试可以发现无论是生产还是消费，都不被允许。最后一步，我们需要为设置的账号授权。

1）创建主题：

2）增加生产权限：

3）配置消费权限：

4）配置消费分组权限：

5）生产数据：

6）消费数据：

我们可以查看配置的权限信息：

Current ACLs for resource Topic:test: User:producer has Allow permission for operations: Write from hosts: * User:consumer has Allow permission for operations: Read from hosts: * Current ACLs for resource Group:test-group: User:consumer has Allow permission for operations: Read from hosts: *

1.6 JAVA客户端

在消费者/生产者初始化属性中引入JAAS文件：

2、SASL/SCRAM验证

上一节，我们通过配置SASL/PLAIN验证，实现了对Kafka的权限控制。但SASL/PLAIN验证有一个问题：只能在JAAS文件KafkaServer中配置用户，一但Kafka启动，无法动态新增用户。

SASL/SCRAM验证可以动态新增用户并分配权限。

2.1 版本

同上文

2.2 启动Zookeeper和Kafka

此方法是把凭证(credential)存储在Zookeeper，可以使用kafka-configs.sh在Zookeeper中创建凭据。对于每个SCRAM机制，必须添加具有机制名称的配置来创建凭证，在启动Kafka broker之前创建代理间通信的凭据。

所以第一步，在没有设置任何权限的配置下启动Kafka和Zookeeper。

2.3 创建SCRAM证书

1）创建broker建通信用户：admin(在使用sasl之前必须先创建,否则启动报错)

2）创建生产用户：producer

3）创建消费用户：consumer

SCRAM-SHA-256/SCRAM-SHA-512是对密码加密的算法，二者有其一即可。

2.4 查看SCRAM证书

2.5 删除SCRAM证书

2.6 服务端配置

在用户证书创建完毕之后开始Kafka服务端的配置：

1）创建JAAS文件：

2）将JAAS配置文件位置作为JVM参数传递给每个Kafka Broker

3）配置server.properties：

可以根据自己的需求选择SASL_SSL或SASL_PLAINTEXT, PLAINTEXT为不加密明文传输，性能好与SSL

4）重启Kafka和Zookeeper

2.7 客户端配置

1）为我们创建的三个用户分别创建三个JAAS文件:

2）修改启动脚本引入JAAS文件：

以生产者为例：

3）ACL权限配置：此时如果我们生产数据则会发生如下错误：

上文2.3节中我们创建了三个用户，但是还未对其赋予操作权限，接下来我们为其增加权限。

生产者：

消费者：

为生产者增加分组权限：

分配权限之后就可以进行生产，消费操作了。（其他颗粒度的权限设置请参考官方文档）

4）查看权限

2.8 小结

SASL/SCRAM验证方法可以在Kafka服务启动之后，动态的新增用户分并配权限，在业务变动频繁，开发人员多的情况下比SASL/PLAIN方法更加灵活。

3. SASL/OAUTHBEARER

SASL/OAUTHBEARER验证是Kafka2.0版中新增的验证方式：

KIP-255 adds a framework for authenticating to Kafka brokers using OAuth2 bearer tokens. The SASL/ OAuthBurer implementation is customizable using callbacks for token retrieval and validation.

KIP-255增加了一个使用OAuth2承载令牌对KafkaBroker进行认证的框架。SASL/OAuthBurer实现可使用回调进行令牌检索和验证。

3.1 Oauth2.0验证

OAuth（开放授权）是一个开放标准，允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容，OAuth2.0是OAuth协议的延续版本。

Oauth2.0的工作流程如下图：

（A）用户打开客户端以后，客户端要求用户给予授权。

（B）用户同意给予客户端授权。

（C）客户端使用上一步获得的授权，向认证服务器申请令牌。

（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。

（E）客户端使用令牌，向资源服务器申请获取资源。

（F）资源服务器确认令牌无误，同意向客户端开放资源。

3.2 JWT规范

Oauth2.0返回验证令牌使用了JWT格式：JSON Web Token（缩写 JWT）是目前最流行的跨域认证解决方案，JWT 的原理是，服务器认证以后，生成一个 JSON 对象，发回给用户。

JWT由三个部分组成，分别是：

• Header（头部）

• Claims（载荷）

• Signature（签名）

1）载荷

sub：该JWT所面向的用户 iss：该JWT的签发者 iat(issued at)：在什么时候签发的token exp(expires)：token什么时候过期 nbf(not before)：token在此时间之前不能被接收处理 jti：JWT ID为web token提供唯一标识

2）头部

typ：指明数据格式 alg：指明加密算法

3）签名 以上两个部分base64编码之后链接成一个字符串，用HS256算法进行加密。在加密的时候，我们还需要提供一个密钥（secret）:

算出签名以后，把 Header、Payload、Signature 三个部分用"点"（.）分割拼成一个字符串，就是最后的结果。

3.3 版本

Kafka2.0以上版本才支持此种验证

3.4 默认验证方式（非安全验证）

1）服务端配置：

（A）创建用于broker端通信的JAAS文件：

参数说明：

举例：

admin用户作为sub的主题用户用于kafka的broker之间通讯。

（B）在启动jvm参数中加入该文件：

（C）配置server.properties

2）客户端配置:

（A）配置producer.properties/consumer.properties

（B）创建客户端通信的JAAS文件（或配置文件中增加配置项）：

JAAS文件样本：

参数说明：

优先级：配置文件 > JAAS文件

（C）验证过程：

在3.4中我们列出了Kafka提供的一套非安全的验证用于非正式环境，通过创建和验证JWT实现验证。只要配置对应JAAS文件即可，本节我们来看一下验证原理。

通过阅读官方文档了解到Kafka提供了一个接口，通过实现接口，创建OAuthBearer token和验证OAuthBearer token。

此类一共有两个方法，查看此接口的继承关系:

通过名字不难猜到这两个就是Kafka提供的默认的非安全的验证类

先看OAuthBearerUnsecuredLoginCallbackHandler的configure方法：在saslMechanism是OAUTHBEARER并且jaasConfigEntries存在的情况下为moduleOptions赋值。moduleOptions保存的是JAAS里面的各种配置项。

handleCallback方法：取出配置的选项值，并组成claimsJson和headerJson，封装成OAuthBearerUnsecuredJws对象，把值赋给OAuthBearerTokenCallback。

接下来看OAuthBearerUnsecuredValidatorCallbackHandler：

在handleCallback里对callback里面的值进行校验，如果校验通过则返回OAuthBearerUnsecuredJws，验证成功，否则抛出异常。

3.5 安全验证

Kafka官方文档中说明：

Production use cases will require writing an implementation of org.apache.kafka.common.security.auth.AuthenticateCallbackHandler that can handle an instance of org.apache.kafka.common.security.oauthbearer.OAuthBearerTokenCallback and declaring it via either the sasl.login.callback.handler.class configuration option for a non-broker client or via the listener.name.sasl_ssl.oauthbearer.sasl.login.callback.handler.class configuration option for brokers (when SASL/OAUTHBEARER is the inter-broker protocol). Production use cases will also require writing an implementation of org.apache.kafka.common.security.auth.AuthenticateCallbackHandler that can handle an instance of org.apache.kafka.common.security.oauthbearer.OAuthBearerValidatorCallback and declaring it via the listener.name.sasl_ssl.oauthbearer.sasl.server.callback.handler.class broker configuration option.

分别需要编写两个实现类处理OAuthBearerTokenCallback并分别在：

3.6 配置

上一节我们讨论了Kafka默认提供的两个实现类，分别实现了AuthenticateCallbackHandler接口，并验证了基于JWT格式的token。受此启发我们可以编写自己的实现类。

1）服务端配置

（A）创建JAAS文件：

（B）在启动jvm参数中加入该文件：

（C）配置server.properties：

2）实现接口：此处只给出思路，具体验证过程根据业务需求定制，我们定义两个类：

区别在于这两个方法：

• login方法主要是客户端用自己的信息（可是是用户名/密码或者token）创建http或者https请求去Oauth服务器申请token,并封装OauthBearerTokenJwt返回。

• introspectBearer方法利用自己的accessToken去Oauth服务器做验证（查询数据库，验证失效时间等等），验证成功后同样返回OauthBearerTokenJwt。

本人用springboot搭建一个简易的后端用来模拟Oauth服务。

小结

本节介绍了自Kafka2.0版本新增的SASL/OAUTHBEARER验证以及相关Oauth和JWT技术。分别介绍了Kafka默认的非安全验证方法和正式环境的验证实现方法。

SASL/OAUTHBEARER可以加密传输验证信息，自定义实现类处理创建/验证token。在此过程中可以对接数据库，便于持久化用户权限信息。

尚未解决的问题：权限细粒度不知如何控制，对生产数据，消费数据，分组信息的控制暂时没有找到方法。

让我“好看”