如何通过可视化方式快捷管理kafka的acl配置

Posted 2021-09-26 NetWhite

前言

我在kafka快速配置启用ACL示例中，以SASL_SCRAM配置方式为示例说明了如何快速在一个kafka集群中启用认证授权机制，提高集群使用的安全性。

但是可能有这一样种场景，比如有多个部门，不同的项目组或项目之间都在共用这个集群，不同的项目组或项目之间会使用不同的用户名/密码或者对不同的topic/消费组分别进行授权，这样，如果我们每次都通过命令的方式，用户信息或者topic数量比较多的时候，无论是查看或者修改都极不方便，所以需要一个可视化的控制台可以便捷的进行操作。

kafka-console-ui

简介

kafka-console-ui支持基于SASL_SCRAM机制可视化管理ACL。

github地址：https://github.com/xxd763795151/kafka-console-ui.git

快速使用

打包

git clone https://github.com/xxd763795151/kafka-console-ui.git
cd kafka-console-ui
sh package.sh

部署

# 解压缩
tar -zxvf kafka-console-ui.tar.gz
# 进入解压缩后的目录
cd kafka-console-ui

启动、停止

# 启动
sh bin/start.sh
# 停止
sh bin/shutdown.sh

修改配置

# 编辑配置
vim config/application.yml

主要配置如下：

kafka:
  config:
    # kafka broker地址，多个以逗号分隔
    bootstrap-server: 'localhost:9092'
    # 服务端是否启用acl，如果不启用，下面的几项都忽略即可
    enable-acl: true
    # 只支持2种安全协议SASL_PLAINTEXT和PLAINTEXT，启用acl则设置为SASL_PLAINTEXT，不启用acl不需关心这个配置
    security-protocol: SASL_PLAINTEXT
    sasl-mechanism: SCRAM-SHA-256
    # 超级管理员用户名，在broker上已经配置为超级管理员
    admin-username: admin
    # 超级管理员密码
    admin-password: admin
    # 启动自动创建配置的超级管理员用户
    admin-create: true
    # broker连接的zk地址
    zookeeper-addr: localhost:2181
    sasl-jaas-config: org.apache.kafka.common.security.scram.ScramLoginModule required username="${kafka.config.admin-username}" password="${kafka.config.admin-password}";

因为是启用ACL，所以enable-acl一定要为true，另外要把broker地址、zk地址、超级管理的账户密码修改为自己的。

注意配置项里有是否自动创建管理员用户，如果kafka集群配置启用了ACL，但是超级管理员还没创建集群节点已经启动了，此时集群仍然是不可用状态，各集群节点间通信认证是失败的，可以直接启动这个控制台，让它把这个超级管理员自动创建了，就不用自己手工去创建这个用户了。

功能说明

• 用户权限列表

展示当前所有用户权限信息，并可查询：

• 管理生产权限

快速增加或者删除某个用户对某个topic的消息发送权限

• 管理消费权限

快速增加或者删除某个用户使用消费组订阅某个topic的权限

• 删除当前用户及其相关所有权限

将当前用户配置删除同时清空该用户授予的所有权限信息

• 细粒度权限控制

可以选择某个资源（topic或消费组）增加什么权限（白名单、黑名单什么的都能配置）

•  查看并管理某个资源的权限明细

•  新增、更新用户

• 查看用户信息

注意这个密码一致性，可能存在不一致或没有密码的情况，这个是效验结果。因为kafka scram的用户密码是单向加密的时候，无法解密，所以这里是把密码缓存起来了，如果有的用户不是通过这个平台创建的，这里缓存的密码是不一致的或者就没有缓存，所以每次查看用户明细的时候，这里会用缓存的密码与实际kafka的用户密码做一个校验，以此来判断查出来的密码是否是正确的。

• 管理员用户不允许操作

 管理员用户信息，不允许操作，主要是避免误操作，影响到集群的稳定性。

·

 末语

当然了，这个东西是我写的，还有其它的一些功能，目前只有ACL这一块实现的相对完备，缺点就是只支持SASL_SCRAM。

目前kafka的安全协议有4种：PLAINTEXT、SSL、SASL_PLAINTEXT、SASL_SSL，私以为，如果kafka集群是在内网中，且只有自己的项目在用，PLAINTEXT，即明文传输完全够用，也不需要认证机制，都是自己人嘛，何必那么麻烦再配置ACL呢。如果是在云上，暴露在公网里了，消息安全性也很高可能需要SSL信道加密了。

但是存在这些一些场景，可能集群是很多项目在用，但是并不需要加密。重点是只需要做好权限控制，哪个项目需要使用哪个topic需要进行申请，那安全协议SASL_PLAINTEXT就足够了，认证机制选用SASL的实现，不需要使用SSL做信道加密且不考虑SASL的其它几种认证机制实现，只是选择了SCRAM，不妨考虑一下我的这个方案。