As of version 1.0.0, kafka-acls.sh no longer recognizes my ACLs stored in zookeeper. I am using SSL and the default principle builder class. My principle name contains a comma. Ex:
The default principle builder uses the getName() function in javax.security.auth.x500:
The documentation states "The only characters in attribute values that are escaped are those which section 2.4 of RFC 2253 states must be escaped". This makes sense as my kakfa-authorizor log shows the comma correctly escaped with a backslash:
INFO Principal = User:CN=myhost.mycompany.com,OU=MyOU,O=MyCompany\, Inc.,ST=MyST,C=US is Denied Operation = Describe from host = 22.214.171.124 on resource = Topic:mytopic (kafka.authorizer.logger)
Here's what I get when I try to create the ACL in kafka 1.0:
Examining Zookeeper, I can see the data. Though I notice that the json string for ACLs is not actually valid since the backslash is not escaped with a double backslash. This was true for 0.11.0.1 as well, but was never actually a problem.
Now Kafka does not recognize any ACLs that have an escaped comma in the principle name and all the clients are denied access. I tried searching for anything relevant that changed between 0.11.0.1 and 1.0.0 and I noticed
Could the new json library be failing because the acl is not actually a valid json string?
I can store a valid json string with an escaped backslash (ex: containing "O=MyCompany
, Inc."), and the comparison between the principle builder string, and what is read from zookeeper succeeds. However, successively apply ACLs seems to strip the backslashes and generally corrupts things:
It looks as though the backslash used for escaping RFC 2253 strings is not being handled correctly. That's as far as I've dug.