鉴权kafka创建新用户和给topic赋权限等相关Acl命令失效问题定位

问题现象背景：

收到客户反馈使用kafka鉴权sdk并填入平台新建的用户组和topic相关参数，消费报鉴权失败。

 排查过程：

1、首先是怀疑客户使用的入参或用法有误，因此向客户要来了ak和sk（其中ak是用户组id，sk是通过用户组id和用户组secret通过sha256算法计算得到），在生产环境新建了用户组和topic，按照标准流程获取ak和sk，执行消费仍报一样的错误；其次是怀疑acl权限没有正确加入到权限列表中，故使用./kafka-acls.sh --authorizer kafka.security.auth.SimpleAclAuthorizer --authorizer-properties zookeeper.connect=ip:2181 –list命令查询了列表，发现用户和topic都加入了权限列表中。

2、期间在网上进行了检索，网上的答案跟这个问题都不太一致（还有说ntp问题导致时间不同步的，检查后ntp正常；说用arthus在线debug的，但考虑生产环境不太方便使用也pass了）。这时，考虑生产这么难定位，如果测试环境有同样问题会更好定位，因此在测试环境如同生产一样操作了一番，发现与生产竟报一样的错，这下问题复现，确认不是使用问题，应该是代码或配置问题。但测试复现顿时感觉方便定位不少，因此下面考虑从测试环境入手定位。

3、由于可以本地通过intellij工具本地消费debug代码，并将log4j2.xml日志级别调整为DEBUG级别

  因此在kafka client源码中打了断点后，可以在线debug并看到更多的具体日志，只是客户端在往服务端校验鉴权信息时仍然是简单的鉴权错误提示，没有更多的有效信息。又考虑在服务端寻找问题信息，想到可以调整服务端kafka的日志级别，因此将kafka  config目录下的log4j.properties相关日志级别都修改成了DEBUG，观察了消费报错后的kafka服务端日志，也没有找到有效信息。

4、期间怀疑是否由引入或修改代码或kafka环境升级或配置修改导致问题，检查了最近的git提交记录，发现kafka acl鉴权相关类很久没有提交或修改代码，因此排除了代码修改引入问题的可能。咨询了运维也排除了kafka环境问题的可能性。

5、经过以上步骤，突然感觉变得有点没有思路，尝试了使用admin的ak和sk去消费，是可以正常消费不会报错。回忆当时实现代码，整个鉴权过程都可以通过命令行的方式进行操作，因此使用命令行的方式，将创建acl用户和对kafka topic赋权的过程都执行了一遍。具体命令如下：

（1）创建用户名为 1037750712148164608，密码为1a0ecf2e77a447c74db9c69150adc49ac680fabbb663e756af9d20882c3a0484的kafka用户

./kafka-configs.sh --zookeeper ip:2181 --alter --add-config 'SCRAM-SHA-256=[iterations=8192,password=1a0ecf2e77a447c74db9c69150adc49ac680fabbb663e756af9d20882c3a0484],SCRAM-SHA-512=[password=1a0ecf2e77a447c74db9c69150adc49ac680fabbb663e756af9d20882c3a0484]' --entity-type users --entity-name 1037750712148164608

（2）给用户为1037750712148164608消费topic为**estTopic1103002的权限

./kafka-acls.sh --authorizer kafka.security.auth.SimpleAclAuthorizer --authorizer-properties zookeeper.connect=ip:2181  --add --allow-principal User:1037750712148164608 --operation Read --topic **estTopic1103002 

（3）并赋予所有kafka 组的权限

./kafka-acls.sh --authorizer-properties zookeeper.connect=ip:2181 --add --allow-principal User:1037750712148164608 --operation Read --topic=**estTopic1103002 --group=*

（4）查询权限列表

./kafka-acls.sh --authorizer kafka.security.auth.SimpleAclAuthorizer --authorizer-properties zookeeper.connect=ip:2181 –list

使用命令行操作后再用kafka sdk进行消费发现是可以正常消费，不报鉴权错误。由此将问题确认为kafka鉴权的java api上。

6、分析了kafka鉴权的整个过程，理解kafka的鉴权信息应该是存储在zookeeper集群上的（期间也怀疑过是zk集群除了问题，不过这在第5部过后也被排除），由此怀疑是不是通过java api写入的密码与实际的密码不一致导致出现上述问题的，因此想去查询一下具体存储的密码是多少。故在zk集群环境的使用kafkaCli登陆

里面有kafkaAcl节点，可是里面只存储了kafka topic相关的权限信息

  我们需要找的是用户信息，因此在/config/users目录下面找到相应的用户列表

  而此用户节点里面存储了用户的相应鉴权信息，当然密码是没有的，只有盐值等

  虽然没有找到密码，但发现一个问题，就是使用命令行创建的用户，/config/users目录下会新建一个名称为用户名的节点，但用java api创建，则没有此节点。

7、将问题缩小到创建kafka用户那一行鉴权命令，由此去review了之前写的代码。

  核心逻辑就是通过java命令执行kafka命令行一样的操作，期间需要加载微服务lib目录下的所有jar包，想到这发现与命令行唯一的区别就是加载lib包，因此怀疑是依赖包有变化导致出现的问题。将测试环境版本回退到一年前的版本，发现果然一切正常，没有出现鉴权失败的问题。

8、比较两个版本lib包中的区别

  发现scala由原先的12变为了11，联想到kafka底层是用scala实现，并且回忆到之前flink版本升级需要将scala改为11，由此恍然大悟。去查了下kafka的版本

  底层是scala12的，由此确认是底层scala版本不兼容导致的问题。