Kafka安全服务搭建（SASL-SCRAM）

学编程的荔枝壳

已于 2024-12-18 16:14:32 修改

阅读量1k

点赞数 8

分类专栏： kafka 文章标签： kafka 安全分布式

于 2024-08-26 18:12:03 首次发布

本文链接：https://blog.csdn.net/qq_44062110/article/details/141570325

版权

kafka 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

前言

最近在做公司kafka安全相关的项目，项目做完之后，感觉有必要对部署阶段的内容进行整理一下，一方面加深影响，另一方面希望通过这种方式能够为遇到相同问题的小伙伴提供解决思路，这篇文章算是之前写的一篇文章的补充和说明，如果感兴趣也可以参考一下：kafka安全机制（SASL_SCRAM）

一、环境搭建

这里提供两种搭建方式：

压缩包安装
Docker安装

1.1 压缩包安装

1.1.1 环境准备

jdk1.8
apache-zookeeper-3.5.9-bin
kafka_2.12-2.7.1

注意：实际应用的版本可自行决定！！！

安装顺序：jdk-->zookeeper-->kafka

小知识：kafka版本命名约定

kafka: 这部分指的是 Apache Kafka，一个开源的分布式事件流平台。Kafka 提供了一种可靠的、可扩展的发布-订阅消息系统，可以处理大规模的实时数据流。

2.12: 这表示 Scala 的版本。在 Kafka 的情况下，2.12意味着它是使用 Scala 2.12 编译的。Scala 是一种运行在 Java 虚拟机上的多范式编程语言，被用于 Kafka 的实现。

2.7.1: 这是 Kafka 的版本号。在这个例子中，版本号是 2.7.1。版本号通常表示软件的发布版本，新版本通常包含新功能、改进和修复之前版本的 bug。

安装文件解压之后，需要将kafka的libs目录下的如下jar赋值到zookeeper的lib目录下：

cp ${KAFKA_HOME}/libs/kafka-clients-2.7.1.jar ${ZOOKEEPER_HOME}/lib
cp ${KAFKA_HOME}/libs/lz4-java-1.7.1.jar ${ZOOKEEPER_HOME}/lib
cp ${KAFKA_HOME}/libs/snappy-java-1.1.7.7.jar ${ZOOKEEPER_HOME}/lib
cp ${KAFKA_HOME}/libs/slf4j-api-1.7.30.jar ${ZOOKEEPER_HOME}/lib
cp ${KAFKA_HOME}/libs/slf4j-log4j12-1.7.30.jar ${ZOOKEEPER_HOME}/lib

每个kafka对应的zookeeper版本不一样，建议先下载想要的kafka版本，解压之后，查看libs下依赖的zookeeper版本，然后去官网下载对应的版本进行安装！！！

1.1.2 JDK的安装与配置

Kafka从2.0.0版本开始就不再支持JDK7及以下版本

到官网下载jdk安装包，并上传至Linux的/opt目录下
解压安装包
配置jdk环境变量,修改/etc/profile文件并向其中添加如下配置

export JAVA_HOME=/opt/jdk解压后的文件名
export JRE_HOME=$JAVA_HOME/jre
export PATH=$PATH:$JAVA_HOME/bin
export CLASSPATH=./://$JAVA_HOME/lib:$JRE_HOME/lib

生效配置文件，source/etc/profile命令使配置生效

source /etc/profile

通过java-version命令验证JDK 是否已经安装配置成功

java -version

1.1.3 Zookeeper的安装与配置

ZooKeeper是安装Kafka集群的必要组件，Kafka通过ZooKeeper来实施对元数据信息的管理，包括集群、broker、主题、分区等内容。

ZooKeeper是一个开源的分布式协调服务，是Google Chubby的一个开源实现。
分布式应用程序可以基于ZooKeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、配置维护等功能。
在ZooKeeper中共有3个角色：leader、follower和observer，同一时刻 ZooKeeper集群中只会有一个leader，其他的都是follower和observer。
observer不参与投票，默认情况下 ZooKeeper 中只有 leader 和 follower 两个角色。更多相关知识可以查阅ZooKeeper官方网站来获得。

1.1.3.1 单机模式安装

到官网下载zookeeper安装包，并上传至Linux的/opt目录下
解压压缩包
添加配置，向/etc/profile配置文件中添加如下内容

export ZOOKEEPER_HOME=/opt/zookeeper解压后的文件名
export PATH=$PATH:$ZOOKEEPER_HOME/bin

执行source/etc/profile命令使配置生效

source /etc/profile

修改 ZooKeeper 的配置文件。首先进入$ZOOKEEPER_HOME/conf 目录，并将zoo_sample.cfg文件修改为zoo.cfg
修改zoo.cfg配置文件，zoo.cfg文件的内容参考如下

# ZooKeeper服务器心跳时间，单位为ms
tickTime=2000
# 投票选举新leader的初始化时间
initLimit=10
# leader与follower心跳检测最大客忍时间，响应超过syncLimit*tickTime,leader认为
# fo11ower“死掉”，从服务器列表中别除fol1ower
syncLimit=5
# 数据目录
dataDir=/tmp/zookeeper/data
# 日志目录
dataLogDir=/tmp/zookeeper/log
# ZooKeeper对外服务端口
clientPort=2181

默认情况下，Linux系统中没有/tmp/zookeeper/data和/tmp/zookeeper/log这两个目录，所以接下来还要创建这两个目录

mkdir -p /tmp/zookeeper/data

mkdir -p /tmp/zookeeper/log

在${dataDir}目录（也就是/tmp/zookeeper/data）下创建一个myid文件，并写入一个数值，比如0。myid文件里存放的是服务器的编号
通过zkServer.sh start启动Zookeeper服务

zkServer.sh start

通过zkServer.sh status查看启动状态

zkServer.sh status

1.1.3.2 集群模式安装

以上是关于ZooKeeper单机模式的安装与配置，一般在生产环境中使用的都是集群模式，集群模式的配置也比较简单，相比单机模式而言只需要修改一些配置即可。下面以3台机器为例来配置一个ZooKeeper集群。首先在这3台机器的/etc/hosts文件中添加3台集群的IP地址与机器域名的映射，示例如下（3个IP地址分别对应3台机器）

然后在这3台机器的zoo.cfg文件中添加以下配置：

为了便于讲解上面的配置，这里抽象出一个公式，即 server.A=B：C：D。其中：

- A是一个数字，代表服务器的编号，就是前面所说的myid文件里面的值。集群中每台服务器的编号都必须唯一，所以要保证每台服务器中的myid文件中的值不同。
- B代表服务器的IP地址。
- C表示服务器与集群中的 leader 服务器交换信息的端口。
- D表示选举时服务器相互通信的端口。

1.1.4 Zookeeper安全认证配置

zookeeper和kafka在默认情况下，是没有开启安全认证的，那么任意客户端可以在不需要任何身份认证的情况下访问zookeeper和kafka下的各节点，甚至可以进行节点的增加，修改以及删除的动作。注意，前面的动作是基于客户端能访问服务端所在的网络，如果进行了物理隔绝或者做了防火墙限制，那前述内容就不一定成立。但是，在某些对安全加固要求比较严格的客户或者生产环境中，那就必须开启安全认证才行。除了最基本的身份认证以外，还有针对每个节点的权限访问，但本文不涉及该话题。

进入正题，先从zookeeper开始配置，zookeeper官网提供了认证配置的参考，点击下方官网地址，即可查看详情。配置分两种情况：

客户端和服务端的双向认证（3.4.0开始引入）
服务端与服务端的双向认证（2.4.10开始引入）

如果是非集群模式下，仅配置客户端和服务端的双向认证即可。集群模式下，则需要客户端和服务端的认证以及zookeeper服务器之间的双向认证。

Zookeeper 使用的是Java自带的认证和授权服务(简称：JAAS)，详细内容请看官网，该链接是 Java 8 的 JAAS 的介绍。这里为zookeeper和kafka分别在对应配置文件下创建jass配置文件为（文件名可以随意）：

zookeeper：${ZOOKEEPER_HOME}/conf/zoo_jaas.conf
kafka：${KAFKA_HOME}/config/kafka-server-jaas.conf

注意：本节中的客户端指的kafka，服务端指的是zookeeper

1.4.4.1 客户端和服务端的双向认证

1. 配置zookeeper服务端

在zoo_jaas.conf添加如下配置

Server {
  org.apache.zookeeper.server.auth.DigestLoginModule required
  username="zookeeper"
  password="zookeepersecret”
  user_kafka="kafkasecret";
};

修改zoo.cfg配置

# 强制进行SASL认证
sessionRequireClientSASLAuth=true
authProvider.1=org.apache.zookeeper.server.auth.DigestLoginModule

增加jvm参数，在${ZOOKEEPER_HOME}/bin/zkEnv.sh脚本中增加：

export SERVER_JVMFLAGS="-Djava.security.auth.login.config=${ZOOKEEPER_HOME}/conf/zoo_jaas.conf"

配置客户端

在kafka-server-jaas.conf中添加如下配置：

Client{
  org.apache.zookeeper.server.auth.DigestLoginModule required
  username="kafka"
  password="kafkasecret";
};

修改客户端的启动脚本${KAFKA_HOME}/bin/kafka-server-start.sh，增加jvm参数:

exec $base_dir/kafka-run-class.sh $EXTRA_ARGS -Djava.security.auth.login.config=${KAFKA_HOME}/config/kafka-server-jaas.conf kafka.Kafka "$@"

1.1.4.2 服务端与服务端的双向认证

该认证一般很少用到，有前面两个认证基本能保证kafka的安全性了，如果想进一步了解这部分内容，可以查看官网：Apache Kafka

修改zoo.cfg，增加如下配置：

quorum.auth.enableSasl=true # 打开sasl开关, 默认是关的
quorum.auth.learnerRequireSasl=true # ZK做为leaner的时候, 会发送认证信息
quorum.auth.serverRequireSasl=true # 设置为true的时候,learner连接的时候需要发送认证信息,否则拒绝
quorum.auth.learner.loginContext=QuorumLearner # JAAS 配置里面的 Context 名字
quorum.auth.server.loginContext=QuorumServer # JAAS 配置里面的 Context 名字
quorum.cnxn.threads.size=20 # 建议设置成ZK节点的数量乘2

修改zoo_jaas.conf，增加如下配置：

QuorumServer {
  org.apache.zookeeper.server.auth.DigestLoginModule required
  user_test="test";
};

QuorumLearner {
  org.apache.zookeeper.server.auth.DigestLoginModule required
  username="test"
  password="test";
};

QuorumServer 和 QuorumLearner 都是配置的ZK节点之间的认证配置

1.1.5 Kafka的安装与配置

1.1.5.1 单机模式安装

到官网下载kafka安装包，并上传至Linux的/opt目录下
解压压缩包
修改broker的配置文件$KAFKA_HOME/conf/server.properties

# broker的编号，如果集群中有多个broker,则每个broker的编号需要设置的不同
broker.id=0
# broker对外提供的服务入口地址
listeners=PLAINTEXT://localhost:9092
# 存放消息日志文件的地址
log.dirs=/tmp/kafka-logs
# Kafka所需的ZooKeeper集群地址，为了方便演示，我们假设Kafka和ZooKeeper都安装在本机
zookeeper.connect=localhost:2181/kafka

1.1.5.2 集群模式安装

如果是单机模式，那么修改完上述配置参数之后就可以启动服务。如果是集群模式，那么只需要对单机模式的配置文件做相应的修改即可：确保集群中每个broker的broker.id配置参数的值不一样，以及listeners配置参数也需要修改为与broker对应的IP地址或域名，之后就可以各自启动服务。注意，在启动 Kafka 服务之前同样需要确保 zookeeper.connect参数所配置的ZooKeeper服务已经正确启动。

1.1.5.3 Kafka安全认证配置

通过kafka-configs.sh脚本生成一个用户admin作为超级管理员

bin/kafka-configs.sh --zookeeper localhost:2181/kafka --alter --add-config 'SCRAM-SHA-256=[password=admin]' --entity-type users --entity-name admin

注意：在配置kafka的server.properties对于zookeeper的连接我们采用的是zookeeper的CHROOT，所以上述命令中也需要指定对应路径，不然启动的kafka时会获取不到生成的SCRAM认证信息！！！

小知识：

ZooKeeper 中的 CHROOT 是指将 ZooKeeper 的命名空间限定在一个特定的路径下。这就是说，ZooKeeper 的所有数据和操作都将在指定的路径下进行，而不是整个 ZooKeeper 服务器上。CHROOT 功能允许在一个 ZooKeeper 集群上运行多个独立的 ZooKeeper 实例，每个实例都有自己的命名空间。

在 ZooKeeper 的配置文件 zoo.cfg 中，CHROOT 通过配置项 chroot 来设置。例如：

chroot=/myapp

在这个例子中，ZooKeeper 就会将其根路径设置为 /myapp，而不是默认的根路径。这样，对于 ZooKeeper 中的所有路径，都将以 /myapp 为根进行解释。这就好比把 ZooKeeper 变成了一个容器，其内部的所有路径都相对于 /myapp 这个容器。

CHROOT 的使用场景包括：

隔离命名空间：允许多个应用在同一个 ZooKeeper 集群上使用不同的命名空间，防止彼此之间的命名冲突。
模拟多个独立环境：允许在同一个 ZooKeeper 集群上模拟多个独立的环境，每个环境有自己的数据和配置。

要注意的是，如果你在使用 CHROOT，ZooKeeper 客户端在连接到 ZooKeeper 服务器时，也需要指定相应的 CHROOT 路径。例如，如果 CHROOT 设置为 /myapp，那么客户端在连接时需要指定 "/myapp" 作为根路径。

总的来说，CHROOT 提供了一种简单而有效的方式，使得在同一个 ZooKeeper 集群上可以支持多个隔离的命名空间。

生成之后可以通过如下命令进行查看：

bin/kafka-configs.sh --zookeeper localhost:2181/kafka --describe --entity-type users --entity-name admin

也可以添加其他SCRAM认证信息，例如SCRAM-SHA-512：

bin/kafka-configs.sh --zookeeper localhost:2181/kafka --alter --add-config 'SCRAM-SHA-512=[password=admin512]' --entity-type users --entity-name admin

也可使用如下命令删除已经添加的认证信息：

bin/kafka-configs.sh --zookeeper localhost:2181/kafka --alter --delete-config 'SCRAM-SHA-256' --entity-type users --entity-name admin

修改kafka-server-jaas.conf，增加kafka服务的SCRAM认证用户信息

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

修改server.properties，新增如下配置：

# 启用ACL
allow.everyone.if.no.acl.found=false
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
# 设置本例中admin为超级用户；在Zookeeper的“/kafka/config/users”下存在用户
super.users=User:admin
# 同时启用SCRAM和PLAIN机制
sasl.enabled.mechanisms=SCRAM-SHA-256
# 为broker间通讯开启SCRAM机制，采用SCRAM-SHA-256算法
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256
# broker间通讯使用PLAINTEXT，本例中不演示SSL配置
security.inter.broker.protocol=SASL_PLAINTEXT
# 配置listeners使用SASL_PLAINTEXT
listeners=SASL_PLAINTEXT://xx.xx.xx.xx:9092
# 配置advertised.listeners
advertised.listeners=SASL_PLAINTEXT://xx.xx.xx.xx:9092

如果是集群，上述配置每个节点都应该配置一份！！！

1.1.5.4 服务启动

启动Kafka服务，在$KAFKA_HOME目录下执行下面的命令即可

bin/kafka-server-start.sh config/server.properties

如果要在后台运行Kafka服务，那么可以在启动命令中加入-daemon参数或＆字符，示例如下:

bin/kafka-server-start.sh -daemon config/server.properties

或者

bin/kafka-server-start.sh config/server.properties &

通过jps命令查看Kafka服务进程是否已经启动

1.2 Docker安装

1.2.1 镜像拉取

zookeeper

docker pull wurstmeister/zookeeper

kafka

docker pull wurstmeister/kafka

1.2.2 安全配置准备

1.2.2.1 kafka_server_jaas.conf

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

Client {
    org.apache.zookeeper.server.auth.DigestLoginModule required
    username="zooclient"
    password="kafka166";
};

说明：

KafkaServer中的username/password是给kafka brokers之间作为client初始请求连接访问使用的，会被作为server的broker验证。
user_admin是kafka服务连接访问请求验证信息，所以这条是必须的，这里可以按这个格式（user_用户名=密码）配置多个。
Client是把kafka作为client端，访问zookeeper(作为server端)的时候用的。对应的必须在zookeeper里面做相应的配置。

1.2.2.2 zk_server_jaas.conf

Server {
    org.apache.zookeeper.server.auth.DigestLoginModule required
    username="zooadmin"
    password="zooadminpwd"
    user_zooclient="kafka166";
};

说明：

user_zooclient这个用户就是前面kafka_server_jaas.conf里面的Client信息；这样就对上了：这两个用户名和密码必须一致，作为kafka client和zookeeper server之间认证使用。

1.2.3 配置修改

准备好上述文件之后，便可按如下步骤进行部署了：

1.2.3.1 开启zookeeper的conf/zoo.cfg安全认证

# 启用 SASL 认证
authProvider=org.apache.zookeeper.server.auth.DigestLoginModule
requireClientAuthScheme=sasl

注意：

如果是集群部署，authProvider后面还应该加.集群编号；
authProvider的值应该与上面jaas文件中Client以及Server配置的保持一致。

1.2.3.2 添加zk_server_jaas.conf到JVM的环境变量中

在bin/zkEnv.sh中添加如下环境变量：

SERVER_JVMFLAGS=" -Djava.security.auth.login.config=/opt/zookeeper-3.4.13/conf/zk_server_jaas.conf"

具体的值根据自身情况修改

注意：

如果不需要配置zookeeper的SASL认证功能，那么上面关于zookeeper的修改都可以忽略，也就是说kafka访问zookeeper的时候不需要SASL认证；此时kafka_server_jaas.conf里面的Client部分可以省略，这样你在启动kafka的时候会看到如下类型信息：

[2024-08-26 07:17:36,142] WARN SASL configuration failed: javax.security.auth.login.LoginException: No JAAS configuration section named 'Client' was found in specified JAAS configuration file: 'opt/kafka/config/kafka_server_jaas.conf'. Will continue connection to Zookeeper server without SASL authentication, if Zookeeper server allows it. (org.apache.zookeeper.ClientCnxn)

1.2.3.3 添加kafka_server_jaas.conf到JVM的环境变量中

在bin/kafka-server-start.sh中添加如下环境变量：

export KAFKA_OPTS=" -Djava.security.auth.login.config=opt/kafka/config/kafka_server_jaas.conf"

具体的值根据自身情况修改

1.2.3.4 修改kafka的config/server.properties

# 启用ACL
allow.everyone.if.no.acl.found=false
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
# 设置本例中admin为超级用户；在Zookeeper的“/kafka/config/users”下存在用户
super.users=User:admin
# 同时启用SCRAM和PLAIN机制
sasl.enabled.mechanisms=SCRAM-SHA-256
# 为broker间通讯开启SCRAM机制，采用SCRAM-SHA-256算法
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256
# broker间通讯使用PLAINTEXT，本例中不演示SSL配置
security.inter.broker.protocol=SASL_PLAINTEXT
# 启用delegation token
delegation.token.master.key=delegation666

说明：

super.users可以配置多个，多个以;隔开，前提是这些用户信息在kafka_server_jaas.conf中已经配置；
delegation.token.master.key是为kafka用户生成委托令牌的，详细信息可以参考官网：Apache Kafka

1.2.4 服务启动

先启动zookeeper，后启动kafka

1.2.4.1 启动zookeeper

docker run -d --name zookeeper -p 2181:2181 \
-v ~/mounts/zookeeper/bin/:/opt/zookeeper-3.4.13/bin/ \
-v ~/mounts/zookeeper/conf/:/opt/zookeeper-3.4.13/conf/ \
-v ~/mounts/zookeeper/data/:/opt/zookeeper-3.4.13/data/ \
wurstmeister/zookeeper

启动后查看zookeeper日志是否正常

docker logs -f zookeeper

1.2.4.2 启动kafka

docker run -d --name kafka -p 9092:9092 \
--env KAFKA_ZOOKEEPER_CONNECT=xx.xx.xx.xx:2181/kafka \
--env KAFKA_ADVERTISED_LISTENERS=SASL_PLAINTEXT://xx.xx.xx.xx:9092 \
--env KAFKA_LISTENERS=SASL_PLAINTEXT://0.0.0.0:9092 \
--env KAFKA_BROKER_ID=0  \
--env KAFKA_LOG_DIRS=/kafka/kafka-logs  \
-v ~/mounts/kafka/bin/:/opt/kafka/bin/ \
-v ~/mounts/kafka/config/:/opt/kafka/config/ \
-v ~/mounts/kafka/logs/:/opt/kafka/logs/ \
-v ~/mounts/kafka-logs/:/kafka/kafka-logs/ \
wurstmeister/kafka

查看日志

docker logs -f kafka

这时如果没通过bin/kafka-configs.sh脚本创建上面提到的kafka之前的admin账号信息的话，就会报如下错误：

[2024-08-26 07:17:36,414] INFO [SocketServer listenerType=ZK_BROKER, nodeId=0] Failed authentication with /172.17.0.1 (Authentication failed during authentication due to invalid credentials with SASL mechanism SCRAM-SHA-256) (org.apache.kafka.common.network.Selector)

需要进入到kafka的容器里面进通过脚本生成对应的admin信息：

docker exec -it kafka /bin/bash

通过kafka-configs.sh脚本生成一个用户admin作为超级管理员

bin/kafka-configs.sh --zookeeper localhost:2181/kafka --alter --add-config 'SCRAM-SHA-256=[password=admin]' --entity-type users --entity-name admin

注意：在配置kafka的server.properties对于zookeeper的连接我们采用的是zookeeper的CHROOT，所以上述命令中也需要指定对应路径，不然启动的kafka时会获取不到生成的SCRAM认证信息！！！

小知识：

ZooKeeper 中的 CHROOT 是指将 ZooKeeper 的命名空间限定在一个特定的路径下。这就是说，ZooKeeper 的所有数据和操作都将在指定的路径下进行，而不是整个 ZooKeeper 服务器上。CHROOT 功能允许在一个 ZooKeeper 集群上运行多个独立的 ZooKeeper 实例，每个实例都有自己的命名空间。

在 ZooKeeper 的配置文件 zoo.cfg 中，CHROOT 通过配置项 chroot 来设置。例如：

chroot=/myapp

在这个例子中，ZooKeeper 就会将其根路径设置为 /myapp，而不是默认的根路径。这样，对于 ZooKeeper 中的所有路径，都将以 /myapp 为根进行解释。这就好比把 ZooKeeper 变成了一个容器，其内部的所有路径都相对于 /myapp 这个容器。

CHROOT 的使用场景包括：

隔离命名空间：允许多个应用在同一个 ZooKeeper 集群上使用不同的命名空间，防止彼此之间的命名冲突。
模拟多个独立环境：允许在同一个 ZooKeeper 集群上模拟多个独立的环境，每个环境有自己的数据和配置。

要注意的是，如果你在使用 CHROOT，ZooKeeper 客户端在连接到 ZooKeeper 服务器时，也需要指定相应的 CHROOT 路径。例如，如果 CHROOT 设置为 /myapp，那么客户端在连接时需要指定 "/myapp" 作为根路径。

总的来说，CHROOT 提供了一种简单而有效的方式，使得在同一个 ZooKeeper 集群上可以支持多个隔离的命名空间。

生成之后可以通过如下命令进行查看：

bin/kafka-configs.sh --zookeeper localhost:2181/kafka --describe --entity-type users --entity-name admin

也可以添加其他SCRAM认证信息，例如SCRAM-SHA-512：

bin/kafka-configs.sh --zookeeper localhost:2181/kafka --alter --add-config 'SCRAM-SHA-512=[password=admin512]' --entity-type users --entity-name admin