From dev-return-110506-archive-asf-public=cust-asf.ponee.io@kafka.apache.org Wed Jan 15 18:54:06 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 4F78018065E for ; Wed, 15 Jan 2020 19:54:06 +0100 (CET) Received: (qmail 53653 invoked by uid 500); 15 Jan 2020 18:54:05 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 53641 invoked by uid 99); 15 Jan 2020 18:54:04 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Jan 2020 18:54:04 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id A272B1805F1 for ; Wed, 15 Jan 2020 18:54:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 5.401 X-Spam-Level: ***** X-Spam-Status: No, score=5.401 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_REPLY=1, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=4, URIBL_SBL_A=0.1] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id GcsssJttvsPI for ; Wed, 15 Jan 2020 18:54:01 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::d2e; helo=mail-io1-xd2e.google.com; envelope-from=rndgstn@gmail.com; receiver= Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id 774F87E12F for ; Wed, 15 Jan 2020 18:54:00 +0000 (UTC) Received: by mail-io1-xd2e.google.com with SMTP id n11so18937001iom.9 for ; Wed, 15 Jan 2020 10:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=lKfiy+46BwZa45CVR5vxKKVW62fVK3G76qg0mcrz7yA=; b=Bjxu4IdpBVk6j9rwIzmza19nme5vXa/ijOOSZ50B/vEE3x5+mu3bdDX/0sl6UIUnZd nAQM16kWpMQShFCIOdtIIrCoKZYxfF4eIGGAeFAGAKBdz1Y2oqor4u9XwSGSo5H2MJa4 Kvl0fawE/aB+1GUh+KZaogtBwqHI+e1ROM1wDA6A7UOyvda5HxRZU6592mKDJDmTIq/9 r+modBymEjJJ6hiIiMmG4cZrDyavE8sOyOgRskT8Y8K6HioTWx2XBYyEzdK2Urh1OUAt ETn0WmBoNM7nXfiquLwClDoAbprCOQ1p2UxEntoSe4VgvW56HS6ub7VT4ibr5XLqUZMI lTuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=lKfiy+46BwZa45CVR5vxKKVW62fVK3G76qg0mcrz7yA=; b=BOY9y1VM/Itx1yx1bDL1tQhzGcsLRCeuMouGdtl8iBm4TgCmxF2/u20sGI867vvb/q zvHecOdg/wDody9cvAleo8uzUV/U9f90jWdhw1hvTUUP8hNWCprKcIhat7ZxfFVldvQM YRfW11QdmsBeje6S2C8kZS7kI34R5LlJ/wtXNepytyWqNOQoRDz55S6btUJ9Z9PoQiFs YCmzSuOx8jdFthkUPc2Erv2BCWDcyx1xCLj6JTT/jsB/FJmkS+eM2DhNeZby217JlzEQ vU8+nlORgKdqghp2LLLZI7r+bOvGtsLYJcInn56HpFVy8GFuLYxuNM19Lx6N9yI8vb/h jI8A== X-Gm-Message-State: APjAAAXhZRxMRqQCpEvhmFZmPCE/Ulz4rINyiyTOJnyxvxfwWV6cIr5H X4IAxlKrTMTmdkK0Uug3u7rYjSwamW+9yey3oXR21y9vo1Q= X-Google-Smtp-Source: APXvYqzlveFTZD0cbK57cfc/e9XKcm5Aj+k9d7QAw2RkiDh3IMFR86I+mcPRhJWvDhV5M674BIh/d5debHjnX+zfolA= X-Received: by 2002:a5e:9246:: with SMTP id z6mr24143042iop.232.1579114438508; Wed, 15 Jan 2020 10:53:58 -0800 (PST) MIME-Version: 1.0 References: <6b1bbe02-ee90-47dd-a26b-f01ea4242b5b@www.fastmail.com> <4910a37f-9059-4b4b-96a3-e2cafc0afb09@www.fastmail.com> In-Reply-To: <4910a37f-9059-4b4b-96a3-e2cafc0afb09@www.fastmail.com> From: Ron Dagostino Date: Wed, 15 Jan 2020 13:53:46 -0500 Message-ID: Subject: Re: [DISCUSS] KIP-515: Enable ZK client to use the new TLS supported authentication To: dev@kafka.apache.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Colin and Rajini. I've updated the KIP to say that KIP-421 functionality is available to encrypt sensitive configs like the ZK key store and trust store passwords. (I've also made it clear that the configs are not dynamically reconfigurable since dynamic values are stored in ZK and the data is needed to get to ZK in the first place). Colin, let me know if you think anything else needs to be said/done about it -- I wasn't sure if your comment above implies that there are additional direct actions that we need to take aside from this. I agree that making the brokers' ZooKeeper clients dynamic with respect to key and trust stores (e.g. via zookeeper.ssl.context.supplier.class) may increase the risk that this KIP may not land in time for 2.5. Regarding the config names for ZK being different than the ZooKeeper configs (e.g. camel-case keyStore/trustStore instead of keystore/truststore, ciphersuites instead of cipher.suites, enabledProtocols instead of enabled.protocols), I agree it is an issue. I tried to mitigate it by putting warning text in the config docs for these. Regarding configuration inheritance, I think what you are saying is that for any configs where the broker has a clear semantic equivalent, the broker could fall back to the broker value if the ZK value is not given. The potential list is: zookeeper.ssl.keyStore.location =3D> ssl.keystore.location zookeeper.ssl.keyStore.password =3D> ssl.keystore.password zookeeper.ssl.keyStore.type =3D> ssl.keystore.type zookeeper.ssl.trustStore.location =3D> ssl.truststore.location zookeeper.ssl.trustStore.password =3D> ssl.truststore.password zookeeper.ssl.trustStore.type =3D> ssl.truststore.type zookeeper.ssl.ciphersuites =3D> ssl.cipher.suites Note that there are two configs that look the same based on their key names but whose allowable values differ: zookeeper.ssl.protocol(Default: TLSv1.2) =3D> ssl.protocol(Default: TLS) zookeeper.ssl.enabledProtocols(Default: value of protocol property) =3D ssl.enabled.protocols(Default: TLSv1.2,TLSv1.1,TLSv1) Not sure what the right answer is, but hopefully this detail will help get us there. Ron On Wed, Jan 15, 2020 at 12:26 PM Colin McCabe wrote: > > On Tue, Jan 14, 2020, at 11:49, Rajini Sivaram wrote: > > Hi Ron, > > > > Thanks for the detailed explanation, sounds good to me. > > > > A few more questions: > > > > 1) At the moment, all sensitive broker configs including > > keystore/truststore passwords can be stored encrypted in ZooKeeper prio= r to > > starting up brokers. We are now adding SSL keystore/truststore password= s > > for ZooKeeper client that cannot be stored in ZooKeeper since you need > > these to connect to ZK. We should perhaps document that these configs c= an > > be encrypted using KIP-421. > > That's a good point. Previously, we didn't have ZK on-the-wire security = support. However, now that we do, sending sensitive keystore and truststor= e passwords to ZK in cleartext should be deprecated in favor of using KIP-4= 21. > > > > > 2) We can dynamically update keystores and trust stores used by brokers > > without restarting the broker. Can we support this easily for ZK client= s > > created by the broker, for example by adding our own > > `zookeeper.ssl.context.supplier.class`? > > > > Hmm. That might be better to consider in a follow-up, since the deadline= for 2.5 KIPs is coming up? > > best, > Colin > > > 3) Looks like we are using config names that directly map to ZK configs= . > > Have we considered using equivalent Kafka config names with prefixes, > > perhaps with inheritance from the non-prefixed names? Not sure if this = is a > > good idea, but perhaps worth documenting in Rejected Alternatives at le= ast. > > > > > > On Tue, Jan 14, 2020 at 5:14 PM Colin McCabe wrote= : > > > > > Hi Ron, > > > > > > Thanks for the explanation. I guess thinking about it a little bit m= ore, > > > we should just add --zk-tls-config-file to all of these commands. > > > > > > We will be removing this option (plus ZK in general) from these comma= nds > > > in the next major release, but ZK is still supported in 2.5, so we sh= ould > > > just do the logical thing. (The exception is ZkSecurityMigrator, whi= ch > > > will stay). > > > > > > best, > > > Colin > > > > > > > > > On Tue, Jan 14, 2020, at 07:38, Ron Dagostino wrote: > > > > Hi Colin. > > > > > > > > <<< It seems like this [--zk-tls-config-file information] could jus= t > > > appear > > > > in a configuration file, which all of these tools already accept (I > > > think) > > > > > > > > ZkSecurityMigrator has no such property file facility; adding a > > > > "--zk-tls-config-file" parameter is exactly for this purpose. If w= e add > > > > that to ZkSecurityMigrator then it is trivial to add it to other co= mmands > > > > (the same code is simply reused; it ends up being just a few extra > > > lines). > > > > I do not see any parameter in the other two commands to adjust the = ZK > > > > connection; ConfigCommand accepts a "--command-config" flag, but > > > according > > > > to the code "This is used only with --bootstrap-server option for > > > > describing and altering broker configs." > > > > > > > > I do agree there would be no need to add "--zk-tls-config-file" to > > > > ReassignPartitionsCommand if its direct ZK connectivity is replaced= in > > > time > > > > for the next release. > > > > > > > > ConfigCommand supports the "--bootstrap-server" option and will hav= e its > > > > direct ZooKeeper access formally deprecated as per KIP-555, but the > > > special > > > > use case of bootstrapping a ZooKeeper ensemble with encrypted crede= ntials > > > > prior to starting Kafka will still exist, so it feels like while > > > > "--zk-tls-config-file" would never be used except for this use case= it > > > > could probably still be added for this particular situation. > > > > > > > > Ron > > > > > > > > P.S. I responded on 1/6 but I just discovered that e, ail (and 3 mo= re I > > > > sent) did not go through. I am trying to get emails through now to= move > > > > this discussion forward. > > > > > > > > On Mon, Jan 6, 2020 at 5:07 PM Colin McCabe wr= ote: > > > > > > > > > On Fri, Dec 27, 2019, at 10:48, Ron Dagostino wrote: > > > > > > Hi everyone. I would like to make the following changes to the= KIP. > > > > > > > > > > > > MOTIVATION: > > > > > > Include a statement that it will be difficult in the short term= to > > > > > > deprecate direct Zookeeper communication in kafka-configs.{sh, = bat} > > > > > (which > > > > > > invoke kafka.admin.ConfigCommand) because bootstrapping a Kafka > > > cluster > > > > > > with encrypted passwords in Zookeeper is an explicitly-supporte= d use > > > > > case; > > > > > > therefore it is in scope to be able to securely configure the C= LI > > > tools > > > > > > that still leverage non-deprecated direct Zookeeper communicati= on > > > for TLS > > > > > > (the other 2 tools are kafka-reassign-partitions.{sh, bat} and > > > > > > zookeeper-security-migration.sh). > > > > > > > > > > Hi Ron, > > > > > > > > > > Thanks for the KIP. > > > > > > > > > > About deprecations: > > > > > > > > > > * zookeeper-security-migration: clearly, deprecating ZK access in= this > > > one > > > > > would not make sense, since it would defeat the whole point of th= e > > > tool :) > > > > > > > > > > * kafka-reassign-partitions: ZK access should be deprecated here. > > > KIP-455 > > > > > implementation has dragged a bit, but this should get done soon. > > > Certainly > > > > > before the next release. > > > > > > > > > > * kafka-configs: I think ZK access should be deprecated here as w= ell. > > > I > > > > > agree there is a super-special bootstrapping case here, but that = should > > > > > have its own tool, not use kafka-configs. > > > > > > > > > > I will post a separate KIP for this, though. > > > > > > > > > > > > > > > > > GOALS: > > > > > > Support the secure configuration of TLS-encrypted communication > > > between > > > > > > Zookeeper and: > > > > > > a) Kafka brokers > > > > > > b) The three CLI tools mentioned above that still support dir= ect, > > > > > > non-deprecated communication to Zookeeper > > > > > > It is explicitly out-of-scope to deprecate any direct Zookeeper > > > > > > communication in CLI tools as part of this KIP; such work will = occur > > > in > > > > > > future KIPs instead. > > > > > > > > > > > > PUBLIC INTERFACES: > > > > > > 1) The following new broker configurations will be recognized. > > > > > > zookeeper.client.secure (default value =3D false, for backwar= ds > > > > > > compatibility) > > > > > > zookeeper.clientCnxnSocket > > > > > > zookeeper.ssl.keyStore.location > > > > > > zookeeper.ssl.keyStore.password > > > > > > zookeeper.ssl.trustStore.location > > > > > > zookeeper.ssl.trustStore.password > > > > > > It will be an error for any of the last 5 values to be left > > > unspecified > > > > > if > > > > > > zookeeper.client.secure is explicitly set to true. > > > > > > > > > > > > 2) In addition, the kafka.security.authorizer.AclAuthorizer cla= ss > > > > > supports > > > > > > the ability to connect to a different Zookeeper instance than t= he > > > one the > > > > > > brokers use. We therefore also add the following optional conf= igs, > > > which > > > > > > override the corresponding ones from above when present: > > > > > > authorizer.zookeeper.client.secure > > > > > > authorizer.zookeeper.clientCnxnSocket > > > > > > authorizer.zookeeper.ssl.keyStore.location > > > > > > authorizer.zookeeper.ssl.keyStore.password > > > > > > authorizer.zookeeper.ssl.trustStore.location > > > > > > authorizer.zookeeper.ssl.trustStore.password > > > > > > > > > > > > 3) The three CLI tools mentioned above will support a new > > > > > --zk-tls-config-file > > > > > > " option. The > > > following > > > > > > properties will be recognized in that file, and unrecognized > > > properties > > > > > > will be ignored to allow the possibility of pointing > > > zk-tls-config-file > > > > > at > > > > > > the broker's config file. > > > > > > zookeeper.client.secure (default value =3D false) > > > > > > zookeeper.clientCnxnSocket > > > > > > zookeeper.ssl.keyStore.location > > > > > > zookeeper.ssl.keyStore.password > > > > > > zookeeper.ssl.trustStore.location > > > > > > zookeeper.ssl.trustStore.password > > > > > > It will be an error for any of the last 5 values to be left > > > unspecified > > > > > if > > > > > > zookeeper.client.secure is explicitly set to true. > > > > > > > > > > Do we really need a --zk-tls-config-file flag? It seems like thi= s > > > could > > > > > just appear in a configuration file, which all of these tools alr= eady > > > > > accept (I think). > > > > > > > > > > best, > > > > > Colin > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > On Mon, Dec 23, 2019 at 3:03 PM Ron Dagostino > > > wrote: > > > > > > > > > > > > > Hi everyone. Let's get this discussion going again now that = Kafka > > > 2.4 > > > > > > > with Zookeeper 3.5.6 is out. > > > > > > > > > > > > > > First, regarding the KIP number, the other KIP that was using= this > > > > > number > > > > > > > moved to KIP 534, so KIP 515 remains the correct number for t= his > > > > > > > discussion. I've updated the Kafka Improvement Proposal page= to > > > list > > > > > this > > > > > > > KIP in the 515 slot, so we're all set there. > > > > > > > > > > > > > > Regarding the actual issues under discussion, I think there a= re > > > some > > > > > > > things we should clarify. > > > > > > > > > > > > > > 1) It is possible to use TLS connectivity to Zookeeper from A= pache > > > > > Kafka > > > > > > > 2.4 -- the problem is that configuration information has to b= e > > > passed > > > > > via > > > > > > > system properties as "-D" command line options on the java > > > invocation > > > > > of > > > > > > > the broker, and those are not secure (anyone with access to t= he box > > > > > can see > > > > > > > the command line used to invoke the broker); the configuratio= n > > > includes > > > > > > > sensitive information (e.g. a keystore password), so we need = a > > > secure > > > > > > > mechanism for passing the configuration values. I believe th= e real > > > > > > > motivation for this KIP is to harden the configuration mechan= ism > > > for > > > > > > > Zookeeper TLS connectivity. > > > > > > > > > > > > > > 2) I believe the list of CLI tools that continue to use direc= t > > > > > Zookeeper > > > > > > > connectivity in a non-deprecated fashion is: > > > > > > > a) > > > zookeeper-security-migration.sh/kafka.admin.ZkSecurityMigrator > > > > > > > b) > > > > > > > > > > > > > > > kafka-reassign-partitions.{sh,bat}/kafka.admin.ReassignPartitionsComm= and > > > > > > > c) kafka-configs.{sh, bat}/kafka.admin.ConfigCommand > > > > > > > > > > > > > > 3) I believe Kafka.admin.ConfigCommand presents a conundrum > > > because it > > > > > > > explicitly states in a comment that a supported use case is > > > > > bootstrapping a > > > > > > > Kafka cluster with encrypted passwords in Zookeeper (see > > > > > > > > > > > > > > > https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/= admin/ConfigCommand.scala#L65 > > > > > ). > > > > > > > This means it will be especially difficult to deprecate this > > > particular > > > > > > > direct Zookeeper connectivity without a different storage > > > mechanism for > > > > > > > dynamic configuration values being available (i.e. the self-m= anaged > > > > > quorum > > > > > > > referred to in KIP-500). > > > > > > > > > > > > > > I think it would be easier and simpler to harden the Zookeepe= r TLS > > > > > > > configuration in both Kafka and in CLI tools compared to tryi= ng to > > > > > > > deprecate the direct Zookeeper connectivity in the above 3 CL= I > > > tools -- > > > > > > > especially when ConfigCommand has no obvious short-term path = to > > > > > deprecation. > > > > > > > > > > > > > > Regarding how to harden the TLS configuration, adding the > > > appropriate > > > > > > > configs to Kafka is an obvious choice for the brokers. Not t= hat > > > these > > > > > > > values cannot be dynamically reconfigurable because the value= s > > > would be > > > > > > > required to connect to Zookeeper via TLS in the first place. > > > > > > > > > > > > > > Regarding how to harden the TLS configuration for the 3 remai= ning > > > CLI > > > > > > > tools, it would be relatively straightforward to add support = for a > > > > > > > "--zk-tls-config-file > > > > > > properties file path>" option to each one. > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > On Thu, Sep 12, 2019 at 8:13 AM Pere Urb=C3=B3n Bayes < > > > pere.urbon@gmail.com > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > >> True, the number is duplicated. > > > > > > >> > > > > > > >> do you know how can we get the problem fix? I was not awar= e, I > > > > > missed, > > > > > > >> sorry the need to add the KIP to the table. > > > > > > >> > > > > > > >> -- Pere > > > > > > >> > > > > > > >> Missatge de Jorge Esteban Quilcate Otoya < > > > quilcate.jorge@gmail.com> > > > > > del > > > > > > >> dia > > > > > > >> dt., 3 de set. 2019 a les 13:43: > > > > > > >> > > > > > > >> > Hi Pere, > > > > > > >> > > > > > > > >> > Have you add your KIP to the list here > > > > > > >> > > > > > > > >> > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+P= roposals > > > > > > >> ? > > > > > > >> > > > > > > > >> > I found the KIP number assigned to another. > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > On Mon, Sep 2, 2019 at 2:23 PM Pere Urb=C3=B3n Bayes < > > > > > pere.urbon@gmail.com> > > > > > > >> > wrote: > > > > > > >> > > > > > > > >> >> Thanks for your time Harsha, > > > > > > >> >> anyone else with comments? looking forward to hearing = from > > > you. > > > > > > >> >> > > > > > > >> >> Stupid question: when do you move from discussion to vote= ? > > > > > > >> >> > > > > > > >> >> Missatge de Harsha Chintalapani del dia > > > dv., 30 > > > > > > >> d=E2=80=99ag. > > > > > > >> >> 2019 a les 21:59: > > > > > > >> >> > > > > > > >> >> > Thanks Pere. KIP looks good to me. > > > > > > >> >> > -Harsha > > > > > > >> >> > > > > > > > >> >> > > > > > > > >> >> > On Fri, Aug 30, 2019 at 10:05 AM, Pere Urb=C3=B3n Bayes= < > > > > > > >> >> pere.urbon@gmail.com> > > > > > > >> >> > wrote: > > > > > > >> >> > > > > > > > >> >> >> Not really, > > > > > > >> >> >> my idea is to keep the JAAS parameter, so people don= 't see > > > > > major > > > > > > >> >> >> changes. But if you pass a properties file, then this = takes > > > > > > >> precedence > > > > > > >> >> over > > > > > > >> >> >> the other, with the idea that you can do sasl as well = with > > > the > > > > > > >> >> properties > > > > > > >> >> >> files. > > > > > > >> >> >> > > > > > > >> >> >> Makes sense? > > > > > > >> >> >> > > > > > > >> >> >> -- Pere > > > > > > >> >> >> > > > > > > >> >> >> Missatge de Harsha Chintalapani del = dia > > > dv., > > > > > 30 > > > > > > >> >> d=E2=80=99ag. > > > > > > >> >> >> 2019 a les 19:00: > > > > > > >> >> >> > > > > > > >> >> >>> Hi Pere, > > > > > > >> >> >>> Thanks for the KIP. Enabling SSL for zookee= per > > > for > > > > > Kafka > > > > > > >> >> makes > > > > > > >> >> >>> sense. > > > > > > >> >> >>> "The changes are planned to be introduced in a compat= ible > > > way, > > > > > by > > > > > > >> >> >>> keeping the current JAAS variable precedence." > > > > > > >> >> >>> Can you elaborate a bit here. If the user configures = a JAAS > > > > > file > > > > > > >> with > > > > > > >> >> >>> Client section it will take precedence over zookeeper= SSL > > > > > configs? > > > > > > >> >> >>> > > > > > > >> >> >>> Thanks, > > > > > > >> >> >>> Harsha > > > > > > >> >> >>> > > > > > > >> >> >>> > > > > > > >> >> >>> > > > > > > >> >> >>> On Fri, Aug 30, 2019 at 7:50 AM, Pere Urb=C3=B3n Baye= s < > > > > > > >> >> pere.urbon@gmail.com> > > > > > > >> >> >>> wrote: > > > > > > >> >> >>> > > > > > > >> >> >>>> Hi, > > > > > > >> >> >>>> quick question, I saw in another mail that 2.4 relea= se is > > > > > planned > > > > > > >> for > > > > > > >> >> >>>> September. I think it would be really awesome to hav= e > > > this for > > > > > > >> this > > > > > > >> >> >>>> release, do you think we can make it? > > > > > > >> >> >>>> > > > > > > >> >> >>>> -- Pere > > > > > > >> >> >>>> > > > > > > >> >> >>>> Missatge de Pere Urb=C3=B3n Bayes del > > > dia > > > > > dj., > > > > > > >> 29 > > > > > > >> >> >>>> d=E2=80=99ag. 2019 a les 20:10: > > > > > > >> >> >>>> > > > > > > >> >> >>>> Hi, > > > > > > >> >> >>>> this is my first KIP for a change in Apache Kafka, s= o I'm > > > > > really > > > > > > >> need > > > > > > >> >> >>>> to the process. Looking forward to hearing from you = and > > > learn > > > > > the > > > > > > >> >> best > > > > > > >> >> >>>> ropes here. > > > > > > >> >> >>>> > > > > > > >> >> >>>> I would like to propose this KIP-515 to enable the > > > > > > >> ZookeeperClients > > > > > > >> >> to > > > > > > >> >> >>>> take full advantage of the TLS communication in the = new > > > > > Zookeeper > > > > > > >> >> 3.5.5. > > > > > > >> >> >>>> Specially interesting it the Zookeeper Security Migr= ation, > > > > > that > > > > > > >> >> without > > > > > > >> >> >>>> this change will not work with TLS, disabling users = to use > > > > > ACLs > > > > > > >> when > > > > > > >> >> the > > > > > > >> >> >>>> Zookeeper cluster use TLS. > > > > > > >> >> >>>> > > > > > > >> >> >>>> link: > > > > > > >> >> >>>> > > > > > > >> >> >>>> > > > > > > >> >> > > > > > > >> > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-515%3A+Enable+Z= K+client+to+use+the+new+TLS+supported+authentication > > > > > > >> >> >>>> > > > > > > >> >> >>>> Looking forward to hearing from you on this, > > > > > > >> >> >>>> > > > > > > >> >> >>>> /cheers > > > > > > >> >> >>>> > > > > > > >> >> >>>> -- > > > > > > >> >> >>>> Pere Urbon-Bayes > > > > > > >> >> >>>> Software Architect > > > > > > >> >> >>>> http://www.purbon.com > > > > > > >> >> >>>> https://twitter.com/purbon > > > > > > >> >> >>>> https://www.linkedin.com/in/purbon/ > > > > > > >> >> >>>> > > > > > > >> >> >>>> -- > > > > > > >> >> >>>> Pere Urbon-Bayes > > > > > > >> >> >>>> Software Architect > > > > > > >> >> >>>> http://www.purbon.com > > > > > > >> >> >>>> https://twitter.com/purbon > > > > > > >> >> >>>> https://www.linkedin.com/in/purbon/ > > > > > > >> >> >>>> > > > > > > >> >> >>> > > > > > > >> >> >>> > > > > > > >> >> >> > > > > > > >> >> >> -- > > > > > > >> >> >> Pere Urbon-Bayes > > > > > > >> >> >> Software Architect > > > > > > >> >> >> http://www.purbon.com > > > > > > >> >> >> https://twitter.com/purbon > > > > > > >> >> >> https://www.linkedin.com/in/purbon/ > > > > > > >> >> >> > > > > > > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > > > >> >> -- > > > > > > >> >> Pere Urbon-Bayes > > > > > > >> >> Software Architect > > > > > > >> >> http://www.purbon.com > > > > > > >> >> https://twitter.com/purbon > > > > > > >> >> https://www.linkedin.com/in/purbon/ > > > > > > >> >> > > > > > > >> > > > > > > > >> > > > > > > >> -- > > > > > > >> Pere Urbon-Bayes > > > > > > >> Software Architect > > > > > > >> http://www.purbon.com > > > > > > >> https://twitter.com/purbon > > > > > > >> https://www.linkedin.com/in/purbon/ > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >