Hi everyone. While finishing the PR for this KIP I realized that the inheritance of TLS ZooKeeper configs that happens in the *authorizer* does not reflect he spirit of our discussion. In particular, based on our inheritance discussion in the DISCUSS thread, the inheritance of authorizer configs needn't be as constrained as it is currently documented to be. I am going to update the KIP as described below and will assume there are no objections if nobody comments as such on this VOTE thread.
The KIP currently states that there is a limited inheritance for authorizer ZooKeeper TLS configs as follows: "Every config can be prefixed with "authorizer." for the case when kafka.security.authorizer.AclAuthorizer connects via TLS to a ZooKeeper quorum separate from the one that Kafka is using – this specific use case will be identified in the configuration by explicitly setting authorizer.zookeeper.ssl.client.enable=true." In other words, the authorizer inherits the broker's ZK TLS configs *unless* it explicitly indicates via authorizer.zookeeper.ssl.client.enable=true that it is going to use its own configs, in which case inheritance does not occur -- i.e. there is no overriding or merging going on where the broker's ZooKeeper TLS configs act as a base upon which any "authorizer." prefixed configs act as an overlay/override; instead, if you point to another ZooKeeper quorum and want to change anything related to TLS then you must restate everything. We had a discussion related to potentially inheriting a broker's *non-ZooKeeper* TLS configs. Inheritance was desirable, and I came around to that way of thinking, but it turned out to be impossible to do given that the broker's non-ZooKeeper TLS configs are potentially stored in ZooKeeper. Still, inheritance was desirable as a concept, so we should do it for the authorizer since the broker's *ZooKeeper* TLS configs are available in the config file. The KIP will now state that the broker's ZooKeeper TLS configs will act as a base config upon which any "authorizer." ZooKeeper TLS configs act as an overlay -- the configs are merged. This is consistent with how the other "authorizer." configs for ZooKeeper work (connection/session timeouts and max inflight requests, for example). This means that the order of evaluation for any particular authorizer ZooKeeper TLS configuration will be: (1) system property (2) broker non-prefixed ZooKeeper TLS config (3) "authorizer." prefixed ZooKeeper TLS config Note that (1) + (2) simply yields the ZooKeeper TLS configs that the broker is using -- with (2) overlaying (1) -- so any "authorizer." prefixed ZooKeeper TLS configs are a true additional level of overlay (again, consistent with the behavior of the ZooKeeper configs for connection/session timeouts and max inflight requests). Ron On Mon, Jan 20, 2020 at 11:14 AM Manikumar <manikumar.re...@gmail.com> wrote: > > +1 (binding). > > Thanks for the KIP. > > On Mon, Jan 20, 2020 at 9:21 PM Rajini Sivaram <rajinisiva...@gmail.com> > wrote: > > > +1 (binding) > > > > Thanks for the KIP, Ron! > > > > Regards, > > > > Rajini > > > > > > On Mon, Jan 20, 2020 at 3:36 PM Gwen Shapira <g...@confluent.io> wrote: > > > > > +1 (binding), this has been an on-going concern. Thank you for > > > addressing this, Ron. > > > > > > On Mon, Jan 20, 2020 at 5:22 AM Ron Dagostino <rndg...@gmail.com> wrote: > > > > > > > > Hi everyone. I would like to start a vote on KIP-515: Enable ZK > > > > client to use the new TLS supported authentication. > > > > > > > > The KIP is here: > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-515%3A+Enable+ZK+client+to+use+the+new+TLS+supported+authentication > > > > > > > > The discussion thread is here: > > > > > > > > > https://lists.apache.org/thread.html/519d07e607cf6598a8126139c964d31fa46f2c028b88b1d44086b8a9%40%3Cdev.kafka.apache.org%3E > > > > > > > > Thanks, > > > > > > > > Ron > > > > >
