我的 Kafka 旅程 - SASL + ACL 认证授权 · 配置 · 创建账号 · 用户授权 · 应用接入

系列目录

本文基于 Kafka 3.5 的 KRaft 模式来阐述
为开发环境准备的单机版 Broker + Controller

关于KRaft模式，目前它还不是特别稳定成熟，还不能完全替代ZK的角色，正如官网如下所说：

下个版本(3.7)是ZK模式的最终版本，2024年计划推出4.0版本，届时仅支持 KRaft 模式。
参考官方说明：KIP-833: Mark KRaft as Production Ready

默认的 Kafka 不受认证约束，可不用账号就可以连接到服务，也就是默认的 PLAIN 方式，不需要认证；配置了 SASL 认证之后，连接Kafka只能用凭证连接登录。

SASL 支持的认证方式有多种：GSSAPI,PLAIN,SCRAM-SHA-256,SCRAM-SHA-512,OAUTHBEARER；
其中 GSSAPI / OAUTHBEARER 都需要额外的独立服务，显得麻烦。
那本文讲述的是比较简单的 SASL_PLAINTEXT 方式，认证机制统一为：SCRAM-SHA-512，ACL/SCRAM机制可追加新用户并授权到TOPIC。

那么基于 SASL+PLAINTEXT+ACL+SCRAM 的认证模式，本文涵盖的内容为：

  1. 配置服务端的认证模式
  2. 命令行创建新账号
  3. 授权账号到Topic的生产/消费权限
  4. 命令行凭证接入样例
  5. 客户端凭证接入样例

作者：[Sol·wang] - 博客园，原文出处：https://www.cnblogs.com/Sol-wang/

一、创建新用户

所以在不受认证约束的默认情况下，默认支持SCRAM；启动后，使用 kafka-configs.sh，可以在 Kafka 中创建新用户：

如何首次启动 Kafka 参考：KRaft 模式启动

# 创建用户
bin/kafka-configs.sh --bootstrap-server {host}:9092 --alter \
  --entity-type users --entity-name {u-name} --add-config 'SCRAM-SHA-512=[password={user-password}]'

# 查看所有用户
bin/kafka-configs.sh --bootstrap-server {host}:9092 --describe --entity-type users
# 查看指定用户
bin/kafka-configs.sh --bootstrap-server {host}:9092 --describe --entity-type users --entity-name {u-name}

假设以上创建了 admin 的账号，后续继续使用此账号。

为什么要先创建一个账号

默认在没有账号的情况下，后续的认证授权生效后，用谁来连接到 Kafka 创建用户呢？？
当然是先有一个管理员账号的存在，如上创建的账号，就假设以上创建的账号为管理员 admin。

用户的分类

 - 超级管理员：对Kafka 的管理
 - 写入Topic：用于生产端的接入
 - 读取Topic：用于消费端的接入

二、Broker认证授权配置

接下来，让创建的用户起作用，就要配置认证授权机制，Kafka-KRaft 的默认认证机制为 PLAINTEXT，不需要凭证的；
本文目标机制为 SASL_PLAINTEXT，这就需要凭证(账号等)了。

2.1 简单方式

在默认的基础上 Brokerconfig/kraft/server.properties配置如下：

######## 认证配置
listeners=SASL_PLAINTEXT://:9092,CONTROLLER://:9093      # 定义三种通讯的认证模式，注释掉advertised.listeners
inter.broker.listener.name=SASL_PLAINTEXT                # 内部节点通讯认证名称，注释掉security.inter.broker.protocol

######## 认证机制 配置
sasl.enabled.mechanisms=SCRAM-SHA-512                    # SASL 启用的认证机制
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512       # Broker节点之间的认证机制用已启用的机制

######## ACL 账号限制 配置
super.users=User:admin                                   # 定义超级管理员
allow.everyone.if.no.acl.found=true                      # true：支持账号黑名单；false：支持账号白名单
# ACL 对于 KRaft 模式的授权方式(类名)
authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer

这样的配置，使得三种通讯的认证机制统一为SASL_PLAINTEXT；那么就可以直接跳到[2.3 章节]继续配置了。

但如果你想深究这块更细的配置，请继续下章节内容，以细化这里的简单配置。

2.2 具体方式

假如：对外认证机制用 SASL_PLAINTEXT，内部认证机制用 PLAINTEXT。

关于 Kafka 中的这三种通讯，这里计划这样做：

通讯 作用 认证机制 自定义别名
客户端(生产/消费)  与 Broker 之间的通讯 对外的 计划用 SASL_PLAINTEXT CLIENT
Broker节点 与 Broker节点 之间的数据通讯 内部的 计划用 PLAINTEXT BROKER
集群(KRaft)管理 Broker 节点 产生的控制器通讯 内部的 计划用 PLAINTEXT CONTROLLER

上述三种通讯分别起了自定义别名，接下来会在配置项之间相互引用定义的名称。

在配置 Borker 前，如果想理解各项配置含义，需要弄清以下几点。

首先，listener.security.protocol.map中SASL支持的通讯协议有哪几种：{别名}:{协议}

  • SSL
  • SASL_SSL
  • PLAINTEXT
  • SASL_PLAINTEXT（本文选择）

其次，既然需要三种通讯，就在listeners中配置需要的通讯端口：{别名}://:{端口号}

  • 客户端：9092
  • 控制器：9093
  • Broker：9091

最后，SASL 的认证机制有哪几种：

  • GSSAPI
  • PLAIN
  • SCRAM-SHA-256
  • SCRAM-SHA-512（本文选择）
  • OAUTHBEARER

理清以上几点后，Broker 需要做以下几点，步骤包含层次及别名引用关系：

  1. 在listener.security.protocol.map中追加定义，用新起的通讯别名+协议，新别名供后续配置引用
  2. 在listeners中分别配置要监听的三种通讯的端口，名称引用<1>中的通讯别名 CLIENT, BROKER, CONTROLLER
  3. 在inter.broker.listener.name上配置 Broker 之间的通讯，引用<1>中的通讯别名 BROKER
  4. 在controller.listener.names上配置 集群管理节点的通讯，引用<1>中的通讯别名 CONTROLLER
  5. 在sasl.enabled.mechanisms配置SASL启用的认证机制PLAINTEXTSCRAM-SHA-512
  6. 在sasl.mechanism.inter.broker.protocol配置内部Broker间的认证机制PLAINTEXT
  7. 配置 ACL 的授权，后续计划用 ACL 方式授权到指定的TOPIC

Broker 的配置效果，在config/kraft/server.properties配置如下：

######## 认证方式(内/外) 配置
# 追加的三个自定义名称 CONTROLLER / BROKER / CLIENT 及各自的认证模式（原有的配置略写...）
# CONTROLLER 是默认存在的，其实仅追加了两个
listener.security.protocol.map=CONTROLLER:PLAINTEXT,BROKER:PLAINTEXT,CLIENT:SASL_PLAINTEXT,...
listeners=CLIENT://:9092,CONTROLLER://:9093,BROKER://:9091        # 引用上一行的名称，定义三种通讯的认证模式及端口
advertised.listeners=CLIENT://{host}:9092,BROKER://{host}:9091    # 引用上一行的名称，定义本机对外通讯认证/IP/端口
inter.broker.listener.name=BROKER                                 # 引用上一行的名称，定义内部 Broker 间的通讯认证
#security.inter.broker.protocol=BROKER                            # 内部通讯安全协议（不配置就用上一行代替）

######## 认证机制 配置
sasl.enabled.mechanisms=SCRAM-SHA-512,PLAINTEXT          # SASL 启用的认证机制
sasl.mechanism.inter.broker.protocol=PLAINTEXT           # Broker节点之间的认证机制用已启用的机制

######## ACL 账号限制 配置
super.users=User:admin                                   # 定义超级管理员
allow.everyone.if.no.acl.found=true                      # true：支持账号黑名单；false：支持账号白名单
# ACL 对于 KRaft 模式的授权方式(类名)
authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer

配置总结：以上用到的三种通讯，各有各的通讯端口和认证机制：

  • 对外用 SASL_PLAINTEXT / 9092
  • 内部集群管理用 PLAINTEXT / 9093
  • 内部数据同步用 PLAINTEXT / 9091

2.3 配置 Broker 的凭证文件

配置了 SASL_PLAINTEXT 方式，就需要凭证文件；假设之前已经创建了用户 admin/*****，并且已配置为超级管理员。

为 Broker 配置 JAAS 文件，假设创建名称为 broker-jaas 的文件，内容如下：

KafkaServer {
    org.apache.kafka.common.security.scram.ScramLoginModule required username="admin" password="***";
};

再将 Broker 的 JAAS 文件配置到环境变量

编辑bin/kafka-server-start.sh追加行：

export KAFKA_OPTS=" -Djava.security.auth.login.config={Path}/broker-jaas"

JAAS

Java Authentication and Authorization Service
这里我们把 JAAS 称为凭证文件，任何连接到 Broker 都要附上对应的JAAS文件，以示身份。

重启 Kafka 服务，使其配置生效。此时，只能用定义了的超级管理员来连接操作 Kafka。连接需要的用户凭证于下节内容。

非首次运行，Kafka可能不会识别listener...map中新配置的别名，这跟log.dirs的文件有关，或还原或动态修改配置命令：
bin/kafka-configs.sh --bootstrap-server {host}:9092 \
  --entity-type brokers --entity-name {broker-id} \
  --alter --add-config listener.security.protocol.map=...

三、命令行中的凭证

假设之前已经创建了用户 admin/*****，并且已配置为超级管理员。

3.1 配置 Client 的凭证文件

为命令行模式创建此用户的凭证文件，这里命名为 admin-user-jaas 保存起来。
例如 admin 用户凭证内容如下：

security.protocol=SASL_PLAINTEXT
sasl.mechanism=SCRAM-SHA-512
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="admin" password="*****";

命令行模式，用凭证连接 Kafka 服务：

之后的每一步操作，都要带上用户凭证文件，假设用超级用户 admin 继续创建新用户的场景：

bin/kafka-configs.sh --bootstrap-server {host}:9092 \
  --alter --add-config 'SCRAM-SHA-512=[password={user-password}]' \
  --entity-type users --entity-name {new-user-name} --command-config admin-user-jaas

与之前不同的是多了--command-config admin-user-jaas 也就是admin用户的凭证信息。这时若不带凭证信息会提示 disconnected。

四、ACL授权用户到TOPIC

用户创建好了，接下来要为用户授权到指定的 Topic 了，并指定权限。

4.1 按端授权

通常生产端的授权也就是写入权限，那么消费端的授权也就是读取权限。

# 授权用户到指定 topic 的生产端(写入)权限
# --allow-principal：指定用户
# --topic {topic-name}：指定某个主题
# --producer：指定为(生产端的)写入权限
bin/kafka-acls.sh --bootstrap-server {host}:9092 --add --producer \
  --allow-principal User:{user-name} --topic {topic-name} --command-config {admin-jaas}
#
# 授权用户到指定 topic 的消费端(读取)权限
# --allow-principal：指定用户
# --topic {topic-name}：指定某个主题
# --consumer：指定为(消费端的)读取权限
# --group {topic-group-name}：必须的消费组归属
bin/kafka-acls.sh --bootstrap-server {host}:9092 --add --consumer \
  --allow-principal User:{user-name} --topic {topic-name} --group {topic-group-name} --command-config {jaas-name}

以生产端为例，自动拥有[查看/写入/创建]权限：

Kafka-ACL-按端用户授权

4.2 按动作授权

先来看看 ACL 支持的权限有哪些：
DescribeDescribeConfigsAlterIdempotentWriteReadDeleteCreateClusterActionAllWriteAlterConfigsCreateTokensDescribeTokens

按[读取/写入]授权案例：

# 授权用户到指定 topic 的指定(create/read/write/describe)权限
# --allow-principal：指定多个用户
# --topic {topic-name}：指定某个主题
bin/kafka-acls.sh --bootstrap-server {host}:9092 \
  --add \
  --allow-principal User:{user1-name} \
  --allow-principal User:{user2-name} \
  --operation read \
  --operation write \
  --topic {topic-name} --command-config {admin-jaas}

Kafka-ACL-用户授权

随着业务不断的增长，创建更多的账号并授权到各个TOPIC使用。

4.3 其它授权管理

以上都是以添加权限为主，除此之外，还有更多的操作方式，以下仅列出了 必要的/常用的 供参考：

# 加入黑名单 (add deny-principal)
bin/kafka-acls.sh --bootstrap-server {host}:9092 --add --deny-principal User:{u-name} --topic {t-name} --command-config {admin-jaas}
# 加入白名单（add allow-principal）也就是上述的授权方式
bin/kafka-acls.sh --bootstrap-server {host}:9092 --add --allow-principal User:{u-name} --topic {t-name} --command-config {admin-jaas}
# 查看已授权（all）不限[用户/主题]
bin/kafka-acls.sh --bootstrap-server {host}:9092 --list --operation all --command-config admin-jaas
# 查看权限（list）从主题查看权限
bin/kafka-acls.sh --bootstrap-server {host}:9092 --list --topic {t-name} --command-config admin-jaas
# 移除权限（remove allow-principal）
bin/kafka-acls.sh --bootstrap-server {host}:9092 --remove --allow-principal User:{u-name} --topic {t-name} --command-config {admin-jaas}

五、命令行用凭证接入

所有的用户凭证文件JAAS都相同，只不过账号密码不同，同样的为客户端用户创建一个凭证文件。

跟 admin-user-jaas 文件一样，创建各自账号的JAAS凭证文件后，这里是生产端/消费端的命令行接入案例：

# 生产端 用户凭证 连接到 Kafka
# --producer.config {用户凭证文件}
bin/kafka-console-producer.sh --bootstrap-server {host}:9092 --topic {topic-name} --producer.config upro-jaas
#
# 消费端 用户凭证 连接到 Kafka
# --consumer.config {用户凭证文件}
bin/kafka-console-consumer.sh --bootstrap-server {host}:9092 --topic {topic-name} --consumer.config ucsm-jaas --from-beginning

六、客户端应用凭证接入

6.1 .NET接入

也就是把各账号凭证文件JAAS中的内容，移到客户端的配置类中，如下样例：

var conf = new ConsumerConfig {
    GroupId = "test-cons-group",
    BootstrapServers = "192.168.56.101:9092",
    SaslUsername = "user-name",
    SaslPassword = "*********",
    SaslMechanism = SaslMechanism.ScramSha512,
    SecurityProtocol = SecurityProtocol.SaslPlaintext,
    SaslOauthbearerConfig = "org.apache.kafka.common.security.scram.ScramLoginModule"
};

6.2 可视化应用 Kafdrop 接入

基于 Docker 的 SASL 接入方式：

docker run -dit --name={容器名称} -p 9000:9000 \
  -e KAFKA_BROKERCONNECT={kafka-node-host}:9092 \
  -e KAFKA_PROPERTIES=$(cat kafka-admin-jaas | base64) \
  obsidiandynamics/kafdrop

ACL 权限列表，浏览曾经授权的用户权限：

Kafka-Kafdrop-ACL-Overview

6.3 可视化应用 Kafka-UI 接入

 基于 Docker 的 SASL 接入方式：

docker run -dit --name={容器名称} -p 8080:8080 -e DYNAMIC_CONFIG_ENABLED=true  provectuslabs/kafka-ui

Kafka-UI 创建集群

Kafka-UI 配置集群及认证

ACL 权限列表，浏览曾经授权的用户权限：

Kafka-UI-ACL-Overview

posted @ 2023-09-04 09:04  Sol·wang  阅读(3804)  评论(12)  编辑  收藏  举报