一、概述
官方文档:
https://kafka.apache.org/documentation/#security
在官方文档中,kafka有五种加密认证方式,分别如下:
- SSL:用于测试环境
- SASL/GSSAPI (Kerberos) :使用kerberos认证,密码是加密的,也是当前企业中使用最多的,最小支持版本0.9
- SASL/PLAIN :使用简单用户名和密码形式,生产环境中一般不使用,主要用于测试,最小支持版本0.10
- SASL/SCRAM:主要解决PLAIN动态更新问题以及安全机制,最小支持版本0.10.2
- SASL/OAUTHBEARER:基于OAuth2认证框架,最小支持版本2.0
几种认证方式的详细比较
- SASL/GSSAPI 主要是给 Kerberos 使用的。GSSAPI 适用于本身已经做了 Kerberos 认证的场景,这样的话,SASL/GSSAPI 可以实现无缝集成。
- SASL/PLAIN 是一个简单的用户名 / 密码认证机制,通常与 SSL 加密搭配使用。对于一些小公司而言,搭建公司级的 Kerberos 可能并没有什么必要,他们的用户系统也不复杂,特别是访问 Kafka 集群的用户可能不是很多。对于 SASL/PLAIN 而言,这就是一个非常合适的应用场景。总体来说,SASL/PLAIN 的配置和运维成本相对较小,适合于小型公司中的 Kafka 集群。SASL/PLAIN 有这样一个弊端:它不能动态地增减认证用户,必须重启 Kafka 集群才能令变更生效。因为所有认证用户信息全部保存在静态文件中,所以只能重启 Broker,才能重新加载变更后的静态文件。
- SASL/SCRAM 通过将认证用户信息保存在 ZooKeeper 的方式,避免了动态修改需要重启 Broker 的弊端。在实际使用过程中,可以使用 Kafka 提供的命令动态地创建和删除用户,无需重启整个集群。因此,如果打算使用 SASL/PLAIN,不妨改用 SASL/SCRAM 试试。不过要注意的是,后者是 0.10.2 版本引入的。
- SASL/OAUTHBEARER 是 2.0 版本引入的新认证机制,主要是为了实现与 OAuth 2 框架的集成。 Kafka 不提倡单纯使用 OAUTHBEARER,因为它生成的不安全的 JSON Web Token,必须配以 SSL 加密才能用在生产环境中。
- Delegation Token 是在 1.1 版本引入的,它是一种轻量级的认证机制,主要目的是补充现有的 SASL 或 SSL 认证。 如果要使用 Delegation Token,需要先配置好 SASL 认证,然后再利用 Kafka 提供的 API 去获取对应的 Delegation Token。这样,Broker 和客户端在做认证的时候,可以直接使用这个 token,不用每次都去 KDC 获取对应的 ticket(Kerberos 认证)或传输 Keystore 文件(SSL 认证)。
二、SASL/PLAIN
SASL/PLAIN是基于用户名密码的认证方式,是比较常用的一种认证,通常与TLS一起用于加密以实现安全认证。
增加kafka配置
vim /opt/kafka_2.13-2.6.0/config/server.properties
# 增加以下配置,每台节点都要配置
listeners=SASL_PLAINTEXT://host.name:port
security.inter.broker.protocol=SASL_PLAINTEXT
sasl.mechanism.inter.broker.protocol=PLAIN
sasl.enabled.mechanisms=PLAIN
# 分发配置,需要注意用户名和路径
scp /opt/kafka_2.13-2.6.0/config/server.properties root@kafka2-73085:/opt/kafka_2.13-2.6.0/config/
scp /opt/kafka_2.13-2.6.0/config/server.properties root@kafka3-73085:/opt/kafka_2.13-2.6.0/config/
增加kafka的权限配置信息
# 编辑配置文件
vim /opt/kafka_2.13-2.6.0/config/kafka_server_jaas.conf
# 增加以下配置
# 增加了两个用户 admin用户和tly用户,配置文件中间不能有注释
KafkaServer {
org.apache.kafka.common.security.plain.PlainLoginModule required
username="admin"
password="123456"
user_admin="123456"
user_tly="123456";
};
# 分发配置文件
scp kafka_server_jaas.conf root@kafka2-73085:/opt/kafka_2.13-2.6.0/config/
scp kafka_server_jaas.conf root@kafka3-73085:/opt/kafka_2.13-2.6.0/config/
上面配置是新增了两个用户,admin和tly,这两个用户都是普通用户,KafkaServer中的username、password配置的用户和密码,是用来broker和broker连接认证。在本例中,admin是代理broker间通信的用户。user_userName配置为连接到broker的所有用户定义密码,broker使用这些验证所有客户端连接,包括来自其他broker的连接。
将JAAS位置作为JVM参数传递给broker
# 编辑 kafka-run-class.sh
vim /opt/kafka_2.13-2.6.0/bin/kafka-run-class.sh
# 更改第219行
export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka_2.13-2.6.0/config/kafka_server_jaas.conf"
# 分发脚本
scp kafka-run-class.sh root@kafka2-73085:/opt/kafka_2.13-2.6.0/bin/kafka-run-class.sh
scp kafka-run-class.sh root@kafka2-73085:/opt/kafka_2.13-2.6.0/bin/kafka-run-class.sh
启动kafka集群
kafka-server-start.sh -daemon /opt/kafka_2.13-2.6.0/config/server.properties
这个时候集群启动完毕已经带有权限
客户端连接
查看topic列表
kafka-topics.sh --bootstrap-server kafka1-73085:9092 --list
迟迟不出结果,卡住了,实际上是没有权限
查看日志如下:
配置权限信息
# 编辑权限文件
vim /root/auth.conf
# 输入如下内容
security.protocol=SASL_PLAINTEXT
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="tly" password="123456";
username和password必须是kafka_server_jaas.conf中配置的。
使用带账号密码配置文件连接
kafka-topics.sh --bootstrap-server kafka1-73085:9092 --list --command-config /root/auth.conf
已经可以正常返回了,说明有权限认证通过了:
创建topic
kafka-topics.sh --bootstrap-server kafka1-73085:9092 --create --topic topic_1 --partitions 3 --replication-factor 3 --command-config /root/auth.conf
生产消息
kafka-console-producer.sh --bootstrap-server \
kafka1-73085:9092 --topic topic_1 --producer.config /root/auth.conf
消费消息
kafka-console-consumer.sh --bootstrap-server kafka1-73085:9092 \
--topic topic_1 --consumer.config /root/auth.conf
权限配置
# 修改server.properties 增加如下配置
# 指定通过ACL来控制权限
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
# 指定超级管理员
super.users=User:admin
使用权限配置并且超级用户是admin,这个用户和我们上面配置的列表中的admin用户相互映射,每个机器都需要配置然后重启所有节点
# 配置用户认证文件信息
vim /root/admin.conf
# 输入如下内容
security.protocol=SASL_PLAINTEXT
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="admin" password="123456";
# 重启所有节点,每个节点都要执行
# 停止节点
kafka-server-stop.sh
# 启动节点
kafka-server-start.sh -daemon /opt/kafka_2.13-2.6.0/config/server.properties
此时每个节点都有了权限认证
# 配置用户认证文件
vim /root/admin.conf
# 输入以下内容
security.protocol=SASL_PLAINTEXT
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="admin" password="123456";
创建topic
这个时候使用auth.conf已经不能创建topic了,使用admin.conf可以创建,因为admin账号和配置的超级管理员一致;而auth.conf配置的是tly账号;
kafka-topics.sh --bootstrap-server kafka1-73085:9092 --create --topic topic_2 --partitions 3 --replication-factor 3 --command-conf /root/auth.conf
不使用认证创建会一直卡主不动,其实也是没权限的,时间久了就会报timeout异常
kafka-topics.sh --bootstrap-server kafka1-73085:9092 --create --topic topic_3 --partitions 3 --replication-factor 3
kafka-acls控制权限
命令为:kafka-acls.sh
参数如下:
- –add 增加权限 --remove 删除权限
- –allow-host 允许操作的主机 --deny-host 拒绝的主机
- –allow-principal 允许操作的用户 --deny-principal 拒绝用户
- –bootstrap-server 集群地址
- –command-config 认证文件信息
- –group 可以消费topic的消费者组
- –list 查询所有权限
- –operation 增加操作权限
- describe
- describeConfigs
- alter
- read
- delete
- create
- all
- write
- alterconfig
- –topic 指定topic
查询topic所有权限
kafka-acls.sh --bootstrap-server kafka1-73085:9092 --list --command-config /root/admin.conf
删除所有权限
kafka-acls.sh --bootstrap-server kafka1-73085:9092 --topic topic_1 --remove --command-config /root/admin.conf
给用户增加权限
给之前的用户tly授权
kafka-acls.sh --bootstrap-server kafka1-73085:9092 --add --allow-principal User:tly --topic topic_1 --operation all --command-config /root/admin.conf
使用tly用户查看当前topic
kafka-topics.sh --bootstrap-server kafka1-73085:9092 --list --command-config /root/auth.conf
回收权限
kafka-acls.sh --bootstrap-server kafka1-73085:9092 --remove --allow-principal user:tly --topic topic_1 --operation all --command-config /root/admin.conf
增加权限并且增加IP限制
kafka-acls.sh --bootstrap-server kafka1-73085:9092 --add --deny-principal User:tly --topic topic_1 --operation all --deny-host 127.0.0.1 --command-config admin.conf
生产者和消费者的权限设置
# 删除所有权限信息
kafka-acls.sh --bootstrap-server kafka1-73085:9092 --topic topic_1 --remove --command-config /root/admin.conf
# 添加生产者权限
kafka-acls.sh --bootstrap-server kafka1-73085:9092 --add --allow-principal User:tly --operation Write --topic topic_1 --command-config /root/admin.conf
# 添加消费权限
kafka-acls.sh --bootstrap-server kafka1-73085:9092 --add --allow-principal User:tly --operation Read --topic topic_1 --command-config /root/admin.conf
# 消费消息
kafka-console-consumer.sh --bootstrap-server kafka1-73085:9092 --topic topic_1 --from-beginning --consumer.config /root/auth.conf
# 发现消费不到,原因是消费者组没有权限
# 增加消费者组权限
kafka-acls.sh --bootstrap-server kafka1-73085:9092 --add --allow-principal User:tly --operation Read --topic topic_1 --group group_1 --command-config /root/admin.conf
# 再次执行消费消息命令并增加分组信息即可以消费到数据
kafka-console-consumer.sh --bootstrap-server kafka1-73085:9092 --topic topic_1 --from-beginning --consumer.config /root/auth.conf --group group_1