Hi everyone. I discovered something minor while addressing the AclAuthorizer config inheritance issue that I need to document. The minimum 3 days for voting is up and we could successfully conclude the vote with 3 +1 binding votes and a +1 non-binding vote, but I'll leave the vote open another day in case anyone needs to comment. Here's the information.
The "zookeeper.ssl.context.supplier.class" configuration doesn't actually exist in ZooKeeper 3.5.6. The ZooKeeper admin guide documents it as being there, but it doesn't appear in the code. This means we can't support it in KIP-515, and I am removing it. I checked the latest ZooKeeper 3.6 SNAPSHOT, and it has been added. So this config could probably be added to Kafka via a new, small KIP if/when we upgrade to ZooKeeper 3.6 (which looks to be in release-candidate stage at the moment). I've created https://issues.apache.org/jira/browse/KAFKA-9469 ("Add zookeeper.ssl.context.supplier.class config if/when adopting ZooKeeper 3.6") for this issue. Again, I will leave the vote open another day in case there needs to be any comment or discussion about this. Ron On Wed, Jan 22, 2020 at 8:56 AM Ron Dagostino <rndg...@gmail.com> wrote: > > 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 > > > > > > >
