Hi everyone. This concludes the vote for KIP 515. The vote passes with +1 binding votes from Gwen, Rajini, and Manikumar and a +1 non-binding vote from Mitch. I have marked the KIP as "Accepted" and opened a pull request at https://github.com/apache/kafka/pull/8003.
Ron Ron On Thu, Jan 23, 2020 at 9:35 AM Ron Dagostino <rndg...@gmail.com> wrote: > > 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 > > > > > > > > >
