1. 为什么需要Kafka安全认证最近在给公司内网的Kafka集群做安全加固时发现很多同事对SASL/PLAIN认证的配置流程不太熟悉。其实对于内网测试环境或准生产环境来说启用基础的用户密码认证非常有必要。想象一下如果任何人都能随意连接你的Kafka集群发送或消费消息那数据安全就完全无法保障了。SASL/PLAIN是Kafka支持的最简单的认证机制它通过用户名密码进行身份验证。虽然密码是明文传输建议配合TLS使用但对于内网环境已经能有效防止未授权访问。我见过太多因为没开认证导致的安全事故比如测试环境的Kafka被其他团队误操作或者临时topic被随意创建占用资源。2. 服务端配置全流程2.1 准备JAAS配置文件首先在Kafka安装目录下创建kafka_server_jaas.conf这个文件定义了服务端的认证信息cd /usr/local/kafka/kafka_2.12-2.5.0 vi kafka_server_jaas.conf文件内容模板如下KafkaServer { org.apache.kafka.common.security.plain.PlainLoginModule required usernameadmin passwordadmin-test user_adminadmin-test user_producerprod-test user_consumercons-test; };这里有几个关键点需要注意KafkaServer是固定标识表示这是服务端配置username/password用于broker节点间通信user_开头的配置定义客户端用户比如user_producer表示生产者账号建议为不同角色创建独立账号如生产者、消费者、管理员2.2 修改server.properties接下来修改Kafka的主配置文件vi config/server.properties在文件末尾追加这些关键参数listenersSASL_PLAINTEXT://192.168.2.122:9092 advertised.listenersSASL_PLAINTEXT://192.168.2.122:9092 security.inter.broker.protocolSASL_PLAINTEXT sasl.enabled.mechanismsPLAIN sasl.mechanism.inter.broker.protocolPLAIN authorizer.class.namekafka.security.auth.SimpleAclAuthorizer allow.everyone.if.no.acl.foundtrue参数说明listeners指定使用SASL_PLAINTEXT协议监听9092端口advertised.listeners客户端连接时使用的地址两个sasl开头的参数指定使用PLAIN机制authorizer.class.name启用ACL授权记得把IP换成你的服务器实际内网IP2.3 修改启动脚本为了让Kafka加载JAAS配置需要修改启动脚本vi bin/kafka-server-start.sh找到export KAFKA_HEAP_OPTS部分添加JVM参数export KAFKA_HEAP_OPTS-Xmx1G -Xms1G -Djava.security.auth.login.config/usr/local/kafka/kafka_2.12-2.5.0/kafka_server_jaas.conf3. 客户端配置指南3.1 创建客户端JAAS文件客户端也需要独立的认证配置vi kafka_client_jaas.conf内容示例生产者配置KafkaClient { org.apache.kafka.common.security.plain.PlainLoginModule required usernameproducer passwordprod-test; };注意这里的username必须与服务端配置的user_producer对应。3.2 修改生产者/消费者脚本为了让控制台工具能使用认证需要修改两个脚本vi bin/kafka-console-producer.sh vi bin/kafka-console-consumer.sh在两个脚本中都添加JVM参数位置与server启动脚本类似-Djava.security.auth.login.config/usr/local/kafka/kafka_2.12-2.5.0/kafka_client_jaas.conf3.3 配置文件调整最后修改生产者和消费者的properties文件vi config/producer.properties vi config/consumer.properties都追加以下内容security.protocolSASL_PLAINTEXT sasl.mechanismPLAIN4. 完整验证流程4.1 启动服务端先启动Zookeeper如果使用内置Zookeeperbin/zookeeper-server-start.sh config/zookeeper.properties然后启动Kafka服务bin/kafka-server-start.sh config/server.properties检查日志没有报错后可以开始验证。4.2 生产者测试开一个终端运行生产者bin/kafka-console-producer.sh \ --broker-list 192.168.2.122:9092 \ --topic test \ --producer-property security.protocolSASL_PLAINTEXT \ --producer-property sasl.mechanismPLAIN4.3 消费者测试另开一个终端运行消费者bin/kafka-console-consumer.sh \ --bootstrap-server 192.168.2.122:9092 \ --topic test \ --from-beginning \ --consumer-property security.protocolSASL_PLAINTEXT \ --consumer-property sasl.mechanismPLAIN如果能在生产者输入消息消费者立即收到说明整个认证流程配置成功。5. 常见问题排查在实际部署时可能会遇到这些问题认证失败检查JAAS文件中用户名密码是否匹配特别注意user_前缀连接超时确认server.properties中的IP地址配置正确协议不匹配确保服务端和客户端都使用SASL_PLAINTEXT权限问题检查JAAS文件的读取权限确保Kafka进程有权限访问有个特别容易踩的坑如果同时配置了多个监听器比如PLAINTEXT和SASL_PLAINTEXT但只给其中一个配置了认证客户端可能会意外通过未认证的端口连接。建议测试时用netstat -tulnp确认实际连接的端口。6. 生产环境建议虽然SASL/PLAIN配置简单但在生产环境还需要注意配合SSL使用PLAIN机制密码是明文传输建议使用SASL_SSL定期更换密码修改JAAS配置后需要重启服务权限细化通过kafka-acls.sh设置详细的topic操作权限监控告警对认证失败事件设置监控我曾经遇到过因为密码泄露导致的消息污染问题后来我们升级到了SCRAM机制支持动态修改密码。不过对于刚接触Kafka安全的新手PLAIN机制仍然是很好的起点。