Hopefully this applies to the previous thread I created yesterday.
This ACL problem really seems to be a chicken-and-egg problem. I’ve attempted nearly all I can think of and find from documentation in terms of disabling “allow.everyone.if.no.acl.found” and also creating topics and adding additional ACLs. From the very start of the Kafka broker, it fails to change something on the Kafka cluster because of an ACL problem. If I set inter-broker communication to mTLS, at least the broker now identifies itself (and yes the broker cert has a DN and SAN that both properly identify it using FQDN). However, the issues still persist. I cannot create ACLs because there are no ACLs explicitly giving the broker the ability to modify the ACLs kept on Zookeeper. So I can’t create ACLs because no ACLs currently exist. A real conundrum. I can’t get a job because I don’t have experience, but in order to get that experience, I need a job. So is this a design flaw? Are you FORCED to enable “allow.everyone.if.no.acl.found” or something? I have not found anywhere that allows me to create an initial set of ACLs to enable a broker to use the CLI tools, nor do I see anything in the documentation that would help me in this situation. Very few threads covering a topic like this leads me to believe that everyone has pretty insecure Kafka servers that only have perimeter security. So, I’m at the point where I either enable “allow.everyone.if.no.acl.found” and just secure the ANONYMOUS authentications to do basically nothing, enable Zookeeper Authentication so no further fudging with the internals can be done unless from an authenticated user, and create ACLs after everything has started up. Still leaves the potential vulnerability of having the “allow.everyone.if.no.acl.found”, but I don’t know considering the documentation doesn’t really cover it other than at a glance.
