From dev-return-110518-archive-asf-public=cust-asf.ponee.io@kafka.apache.org Wed Jan 15 20:54:31 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 6049E18065E for ; Wed, 15 Jan 2020 21:54:31 +0100 (CET) Received: (qmail 35208 invoked by uid 500); 15 Jan 2020 20:54:29 -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 35182 invoked by uid 99); 15 Jan 2020 20:54:29 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.159) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Jan 2020 20:54:29 +0000 Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 7EEC31005 for ; Wed, 15 Jan 2020 20:54:29 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailauth.nyi.internal (Postfix) with ESMTP id D9F9D221D8 for ; Wed, 15 Jan 2020 15:54:28 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute2.internal (MEProxy); Wed, 15 Jan 2020 15:54:28 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrtdefgddugeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdevohhlihhnucfotgevrggsvgdfuceotghmtggtrggs vgesrghprggthhgvrdhorhhgqeenucffohhmrghinheptghlihgvnhhtrdhsvggtuhhrvg dpiihoohhkvggvphgvrhdqshgvtghurhhithihqdhmihhgrhgrthhiohhnrdhshhdpghhi thhhuhgsrdgtohhmpdgrphgrtghhvgdrohhrghdpphhurhgsohhnrdgtohhmpdhtfihith htvghrrdgtohhmpdhlihhnkhgvughinhdrtghomhenucfrrghrrghmpehmrghilhhfrhho mheptghmtggtrggsvgefudegodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqd egiedukeegudeftddqudehheekkeehudegqdgtmhgttggrsggvpeeprghprggthhgvrdho rhhgsehfrghsthhmrghilhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A7013C200A4; Wed, 15 Jan 2020 15:54:28 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-754-g09d1619-fmstable-20200113v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6b1bbe02-ee90-47dd-a26b-f01ea4242b5b@www.fastmail.com> <4910a37f-9059-4b4b-96a3-e2cafc0afb09@www.fastmail.com> Date: Wed, 15 Jan 2020 12:52:59 -0800 From: "Colin McCabe" To: dev@kafka.apache.org Subject: =?UTF-8?Q?Re:_[DISCUSS]_KIP-515:_Enable_ZK_client_to_use_the_new_TLS_sup?= =?UTF-8?Q?ported_authentication?= Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 15, 2020, at 10:53, Ron Dagostino wrote: > Thanks Colin and Rajini. >=20 > 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. >=20 > 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. >=20 > 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: >=20 > 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 >=20 > Note that there are two configs that look the same based on their key > names but whose allowable values differ: >=20 > zookeeper.ssl.protocol(Default: TLSv1.2) =3D> ssl.protocol(Default: TL= S) > zookeeper.ssl.enabledProtocols(Default: value of protocol property) =3D= > ssl.enabled.protocols(Default: TLSv1.2,TLSv1.1,TLSv1) >=20 > Not sure what the right answer is, but hopefully this detail will help= > get us there. >=20 > Ron I think, on balance, I agree with Rajini that it would be nice to make t= he configs look more like Kafka configs. We don't have camel-case in co= nfiguration keys, so we should avoid it here. best, Colin >=20 > On Wed, Jan 15, 2020 at 12:26 PM Colin McCabe wro= te: > > > > 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= prior to > > > starting up brokers. We are now adding SSL keystore/truststore pas= swords > > > for ZooKeeper client that cannot be stored in ZooKeeper since you = need > > > these to connect to ZK. We should perhaps document that these conf= igs can > > > be encrypted using KIP-421. > > > > That's a good point. Previously, we didn't have ZK on-the-wire secu= rity support. However, now that we do, sending sensitive keystore and t= ruststore passwords to ZK in cleartext should be deprecated in favor of = using KIP-421. > > > > > > > > 2) We can dynamically update keystores and trust stores used by br= okers > > > without restarting the broker. Can we support this easily for ZK c= lients > > > 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 dea= dline for 2.5 KIPs is coming up? > > > > best, > > Colin > > > > > 3) Looks like we are using config names that directly map to ZK co= nfigs. > > > Have we considered using equivalent Kafka config names with prefix= es, > > > perhaps with inheritance from the non-prefixed names? Not sure if = this is a > > > good idea, but perhaps worth documenting in Rejected Alternatives = at least. > > > > > > > > > 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 more, > > > > 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 = commands > > > > in the next major release, but ZK is still supported in 2.5, so = we should > > > > just do the logical thing. (The exception is ZkSecurityMigrator= , which > > > > 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] coul= d just > > > > appear > > > > > in a configuration file, which all of these tools already acce= pt (I > > > > think) > > > > > > > > > > ZkSecurityMigrator has no such property file facility; adding = a > > > > > "--zk-tls-config-file" parameter is exactly for this purpose. = If we add > > > > > that to ZkSecurityMigrator then it is trivial to add it to oth= er commands > > > > > (the same code is simply reused; it ends up being just a few e= xtra > > > > lines). > > > > > I do not see any parameter in the other two commands to adjust= the ZK > > > > > connection; ConfigCommand accepts a "--command-config" flag, b= ut > > > > 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 rep= laced in > > > > time > > > > > for the next release. > > > > > > > > > > ConfigCommand supports the "--bootstrap-server" option and wil= l have its > > > > > direct ZooKeeper access formally deprecated as per KIP-555, bu= t the > > > > special > > > > > use case of bootstrapping a ZooKeeper ensemble with encrypted = credentials > > > > > prior to starting Kafka will still exist, so it feels like whi= le > > > > > "--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 more I > > > > > sent) did not go through. I am trying to get emails through n= ow to move > > > > > this discussion forward. > > > > > > > > > > On Mon, Jan 6, 2020 at 5:07 PM Colin McCabe wrote: > > > > > > > > > > > On Fri, Dec 27, 2019, at 10:48, Ron Dagostino wrote: > > > > > > > Hi everyone. I would like to make the following changes t= o 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-sup= ported use > > > > > > case; > > > > > > > therefore it is in scope to be able to securely configure = the CLI > > > > tools > > > > > > > that still leverage non-deprecated direct Zookeeper commun= ication > > > > 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 acce= ss in this > > > > one > > > > > > would not make sense, since it would defeat the whole point = of the > > > > tool :) > > > > > > > > > > > > * kafka-reassign-partitions: ZK access should be deprecated = here. > > > > KIP-455 > > > > > > implementation has dragged a bit, but this should get done s= oon. > > > > Certainly > > > > > > before the next release. > > > > > > > > > > > > * kafka-configs: I think ZK access should be deprecated here= as well. > > > > 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 communic= ation > > > > between > > > > > > > Zookeeper and: > > > > > > > a) Kafka brokers > > > > > > > b) The three CLI tools mentioned above that still suppor= t direct, > > > > > > > non-deprecated communication to Zookeeper > > > > > > > It is explicitly out-of-scope to deprecate any direct Zook= eeper > > > > > > > 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 recogni= zed. > > > > > > > zookeeper.client.secure (default value =3D false, for ba= ckwards > > > > > > > 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 lef= t > > > > unspecified > > > > > > if > > > > > > > zookeeper.client.secure is explicitly set to true. > > > > > > > > > > > > > > 2) In addition, the kafka.security.authorizer.AclAuthorize= r class > > > > > > supports > > > > > > > the ability to connect to a different Zookeeper instance t= han the > > > > one the > > > > > > > brokers use. We therefore also add the following optional= configs, > > > > 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 unrecogniz= ed > > > > 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 lef= t > > > > unspecified > > > > > > if > > > > > > > zookeeper.client.secure is explicitly set to true. > > > > > > > > > > > > Do we really need a --zk-tls-config-file flag? It seems lik= e this > > > > could > > > > > > just appear in a configuration file, which all of these tool= s already > > > > > > 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 this > > > > > > > > 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 th= ere are > > > > some > > > > > > > > things we should clarify. > > > > > > > > > > > > > > > > 1) It is possible to use TLS connectivity to Zookeeper f= rom Apache > > > > > > Kafka > > > > > > > > 2.4 -- the problem is that configuration information has= to be > > > > passed > > > > > > via > > > > > > > > system properties as "-D" command line options on the ja= va > > > > invocation > > > > > > of > > > > > > > > the broker, and those are not secure (anyone with access= to the box > > > > > > can see > > > > > > > > the command line used to invoke the broker); the configu= ration > > > > includes > > > > > > > > sensitive information (e.g. a keystore password), so we = need a > > > > secure > > > > > > > > mechanism for passing the configuration values. I belie= ve the real > > > > > > > > motivation for this KIP is to harden the configuration m= echanism > > > > for > > > > > > > > Zookeeper TLS connectivity. > > > > > > > > > > > > > > > > 2) I believe the list of CLI tools that continue to use = direct > > > > > > Zookeeper > > > > > > > > connectivity in a non-deprecated fashion is: > > > > > > > > a) > > > > zookeeper-security-migration.sh/kafka.admin.ZkSecurityMigrator > > > > > > > > b) > > > > > > > > > > > > > > > > > > kafka-reassign-partitions.{sh,bat}/kafka.admin.ReassignPartition= sCommand > > > > > > > > c) kafka-configs.{sh, bat}/kafka.admin.ConfigCommand > > > > > > > > > > > > > > > > 3) I believe Kafka.admin.ConfigCommand presents a conund= rum > > > > 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/k= afka/admin/ConfigCommand.scala#L65 > > > > > > ). > > > > > > > > This means it will be especially difficult to deprecate = this > > > > particular > > > > > > > > direct Zookeeper connectivity without a different storag= e > > > > mechanism for > > > > > > > > dynamic configuration values being available (i.e. the s= elf-managed > > > > > > quorum > > > > > > > > referred to in KIP-500). > > > > > > > > > > > > > > > > I think it would be easier and simpler to harden the Zoo= keeper TLS > > > > > > > > configuration in both Kafka and in CLI tools compared to= trying to > > > > > > > > deprecate the direct Zookeeper connectivity in the above= 3 CLI > > > > tools -- > > > > > > > > especially when ConfigCommand has no obvious short-term = path to > > > > > > deprecation. > > > > > > > > > > > > > > > > Regarding how to harden the TLS configuration, adding th= e > > > > appropriate > > > > > > > > configs to Kafka is an obvious choice for the brokers. = Not that > > > > these > > > > > > > > values cannot be dynamically reconfigurable because the = values > > > > would be > > > > > > > > required to connect to Zookeeper via TLS in the first pl= ace. > > > > > > > > > > > > > > > > Regarding how to harden the TLS configuration for the 3 = remaining > > > > CLI > > > > > > > > tools, it would be relatively straightforward to add sup= port 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= aware, 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+Improvem= ent+Proposals > > > > > > > >> ? > > > > > > > >> > > > > > > > > >> > 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 hea= ring from > > > > you. > > > > > > > >> >> > > > > > > > >> >> Stupid question: when do you move from discussion to= vote? > > > > > > > >> >> > > > > > > > >> >> Missatge de Harsha Chintalapani de= l 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 peopl= e 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 z= ookeeper > > > > for > > > > > > Kafka > > > > > > > >> >> makes > > > > > > > >> >> >>> sense. > > > > > > > >> >> >>> "The changes are planned to be introduced in a c= ompatible > > > > way, > > > > > > by > > > > > > > >> >> >>> keeping the current JAAS variable precedence." > > > > > > > >> >> >>> Can you elaborate a bit here. If the user config= ures a JAAS > > > > > > file > > > > > > > >> with > > > > > > > >> >> >>> Client section it will take precedence over zook= eeper SSL > > > > > > configs? > > > > > > > >> >> >>> > > > > > > > >> >> >>> Thanks, > > > > > > > >> >> >>> Harsha > > > > > > > >> >> >>> > > > > > > > >> >> >>> > > > > > > > >> >> >>> > > > > > > > >> >> >>> On Fri, Aug 30, 2019 at 7:50 AM, Pere Urb=C3=B3n= Bayes < > > > > > > > >> >> pere.urbon@gmail.com> > > > > > > > >> >> >>> wrote: > > > > > > > >> >> >>> > > > > > > > >> >> >>>> Hi, > > > > > > > >> >> >>>> quick question, I saw in another mail that 2.4 = release is > > > > > > planned > > > > > > > >> for > > > > > > > >> >> >>>> September. I think it would be really awesome t= o have > > > > 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 Kaf= ka, so 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= Migration, > > > > > > that > > > > > > > >> >> without > > > > > > > >> >> >>>> this change will not work with TLS, disabling u= sers to use > > > > > > ACLs > > > > > > > >> when > > > > > > > >> >> the > > > > > > > >> >> >>>> Zookeeper cluster use TLS. > > > > > > > >> >> >>>> > > > > > > > >> >> >>>> link: > > > > > > > >> >> >>>> > > > > > > > >> >> >>>> > > > > > > > >> >> > > > > > > > >> > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-515%3A+Ena= ble+ZK+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/ > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >