1. 遇到Invalid username or password错误时别慌最近在帮客户部署Kafka集群时又遇到了那个熟悉的老朋友Authentication failed: Invalid username or password。这个错误看似简单但背后可能藏着各种配置问题。我记得第一次遇到这个报错时花了整整一天时间才找到问题所在现在回想起来真是哭笑不得。这个错误通常出现在启用SASL认证的Kafka环境中当客户端或Broker间认证失败时就会抛出。表面上看是用户名密码不对但实际上可能涉及多个配置文件的协同工作。就像拼图游戏任何一块拼错了位置整个画面就不完整了。2. 基础检查确认你的JAAS配置2.1 理解JAAS文件结构JAAS(Java Authentication and Authorization Service)配置文件是SASL认证的核心。它通常包含两个主要部分KafkaServer和Client。KafkaServer部分定义Broker的认证信息Client部分则用于Broker与Zookeeper之间的通信。一个典型的JAAS配置长这样KafkaServer { org.apache.kafka.common.security.plain.PlainLoginModule required usernameadmin passwordadmin123 user_adminadmin123 user_alicealice123; }; Client { org.apache.kafka.common.security.plain.PlainLoginModule required usernamezkuser passwordzkpass; };2.2 常见配置陷阱我见过最常见的错误就是username/password和user_*映射不一致。比如上面例子中usernameadmin对应passwordadmin123那么user_admin也必须映射到相同的密码admin123。很多人在复制粘贴配置时会不小心改了一处而忘记改另一处。另一个坑是文件位置问题。JAAS文件需要放在Kafka进程能访问的位置并通过JVM参数指定-Djava.security.auth.login.config/path/to/your/jaas.conf3. Broker间通信配置检查3.1 inter.broker.listener.name的重要性在集群环境中Broker之间也需要相互认证。这就涉及到inter.broker.listener.name的配置。这个参数告诉Kafka哪个监听器用于Broker间通信。在server.properties中需要确保inter.broker.listener.nameINTERNAL listenersINTERNAL://:9092,EXTERNAL://:9093 listener.security.protocol.mapINTERNAL:SASL_PLAINTEXT,EXTERNAL:SASL_PLAINTEXT3.2 SASL机制一致性Broker间通信的SASL机制必须一致。比如如果配置了sasl.mechanism.inter.broker.protocolPLAIN那么所有Broker的JAAS文件中都必须支持PLAIN机制。我曾经遇到一个案例某个Broker的JAAS文件只配置了SCRAM导致整个集群通信失败。4. 客户端配置检查4.1 客户端JAAS配置客户端也需要正确的JAAS配置。对于Java客户端可以通过properties文件设置sasl.jaas.configorg.apache.kafka.common.security.plain.PlainLoginModule required \ usernamealice \ passwordalice123;或者在代码中直接设置props.put(sasl.jaas.config, org.apache.kafka.common.security.plain.PlainLoginModule required username\alice\ password\alice123\;);4.2 安全协议匹配客户端的安全协议必须与Broker监听器匹配。如果Broker配置的是SASL_SSL客户端也必须使用SASL_SSLsecurity.protocolSASL_SSL sasl.mechanismPLAIN5. 高级排查技巧5.1 启用DEBUG日志当基础检查都通过但问题依旧时可以启用Kafka的DEBUG日志log4j.logger.kafkaDEBUG这会输出详细的认证过程帮助你定位问题发生在哪个环节。5.2 使用kafka-configs.sh验证Kafka自带的kafka-configs.sh工具可以用来验证配置bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type users --describe这个命令可以列出当前配置的用户帮助确认用户是否创建成功。5.3 网络抓包分析作为最后的手段可以使用tcpdump或Wireshark抓包分析认证过程。当然这需要你对SASL协议有一定了解tcpdump -i any port 9092 -w kafka.pcap6. 典型场景案例分析6.1 案例一KRaft模式下的认证失败在KRaft模式下Controller和Broker的认证需要特别注意。我遇到过一个案例错误日志显示Authentication failed during authentication due to invalid credentials with SASL mechanism SCRAM-SHA-256问题出在controller.listener.names和inter.broker.listener.name的配置冲突上。解决方案是确保controller和broker使用相同的SASL机制。6.2 案例二Zookeeper和Kafka认证混淆另一个常见错误是把Zookeeper和Kafka的认证配置混为一谈。记住即使使用SASLZookeeper和Kafka的认证也是独立的。它们的JAAS配置需要分别设置并且使用不同的用户名密码。7. 配置一致性检查清单为了帮助大家系统性地排查问题我整理了一个检查清单JAAS文件中username/password与user_*映射是否一致Broker的listener.security.protocol.map是否正确定义inter.broker.listener.name是否指向正确的监听器sasl.mechanism.inter.broker.protocol是否与JAAS配置匹配客户端的安全协议(sasl.security.protocol)是否匹配Broker监听器所有Broker的配置是否完全一致防火墙是否放行了Broker间的通信端口时间同步是否正常Kerberos认证对时间敏感8. 预防措施和最佳实践经过多次踩坑后我总结了一些最佳实践首先使用配置管理工具(Ansible/Puppet)确保所有节点的配置一致。手动修改很容易出错。其次实现监控告警。除了监控Kafka进程状态外还要监控认证失败次数kafka.server:typesasl-metrics,nameFailedAuthenticationsPerSec最后文档化你的安全配置。记录下每个环境的用户名密码和SASL机制避免团队成员因为信息不对称而误改配置。