From dev-return-110550-archive-asf-public=cust-asf.ponee.io@kafka.apache.org Thu Jan 16 11:06:59 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 2A4A818060E for ; Thu, 16 Jan 2020 12:06:59 +0100 (CET) Received: (qmail 82967 invoked by uid 500); 16 Jan 2020 11:06:57 -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 82955 invoked by uid 99); 16 Jan 2020 11:06:57 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Jan 2020 11:06:57 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 00AB8C0870 for ; Thu, 16 Jan 2020 11:06:56 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 5.1 X-Spam-Level: ***** X-Spam-Status: No, score=5.1 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, HTML_MESSAGE=0.2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-ec2-va.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id BK2xNZVJOSIL for ; Thu, 16 Jan 2020 11:06:51 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.166.51; helo=mail-io1-f51.google.com; envelope-from=rajinisivaram@gmail.com; receiver= Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id 4D67EBC5C3 for ; Thu, 16 Jan 2020 11:06:51 +0000 (UTC) Received: by mail-io1-f51.google.com with SMTP id z193so21285490iof.1 for ; Thu, 16 Jan 2020 03:06:51 -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; bh=FGbdePxFdFW7D2lOxZK9pkEHlGFiZN3ZlbYTW5CC58M=; b=AjGuwZYA2Wa84YyV7Aa59fx/K6uSz9c/DDywPNBJY+KsQLs94MVyprJMXubHU3PjxF g8Bj0D1868j43aMEsNxsfb2xtKK6EwMxNCYS3NFg8UnZGDA5ZY+vsMs+AJDXxrpfyCe+ e2YU8u7LrHcjbk+ec+NYlpe7g8N8OnqUmW+LgIP3Sl6p9EGFIUVd0WcViV7rZDa2dn5i kU9K3kKJo63woDGziU3mZFiHHBJzQvXKsQ5hRdU3dHnLIqlVBuLzpo7oBu3haVWkCAaA cYChRxTgK/C0Mh5ytbdsAG0OSbzaAQqC7bnj7+V2qV1JE4lwwilYmYNeGQLMHBuTSWWw BKcw== 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; bh=FGbdePxFdFW7D2lOxZK9pkEHlGFiZN3ZlbYTW5CC58M=; b=L77TYPBOYMJ7q7b+LhLb2AajgbDY+3dedXUDWDbxmDHswQQDWWKmcxl17QxgNmwZx/ lRt0bhE99E7WnKgdhyDWB153KzX+kzS4S8VIuTZ0/xs83lVyJCYbhsI3KZfElmVGuM7b vMwdT0lAGFlIUvlsQdn8DQ/R0ptgt2/qMV1pyvDLijRh+oaKAtD85xFpnhuXSNgvjD19 wh7BCJJHl1Vykkrh4+ulslWfnCIBw7l/e3vXvXBRfirr7NTX1n+gwZM1RPGn6/CaO1PN 3Jt2Jf7I4QY+M/nqxvGl4aBv0UplT/lF6TcJPx9SJDeC6gCtTEkvu93xKRF7B06MRGn2 f5/A== X-Gm-Message-State: APjAAAXGGfEfH3X0/bVC5jiDjJJSYSAzZtrES8LppKQKmGMfymuR7sg5 tsMn1/+F8IKp2VENwKZT1flD5b8colaThdew2jYj6p9B X-Google-Smtp-Source: APXvYqz7EoTvKDfWym/X+qFl57mYjSKTeo6LNiXUsrkVCej3KNdGQjUeg1oBSuKfTStBGYfJcXZvBwzSxpM/KVCS5D8= X-Received: by 2002:a6b:731a:: with SMTP id e26mr25354336ioh.254.1579172810475; Thu, 16 Jan 2020 03:06:50 -0800 (PST) MIME-Version: 1.0 References: <6b1bbe02-ee90-47dd-a26b-f01ea4242b5b@www.fastmail.com> <4910a37f-9059-4b4b-96a3-e2cafc0afb09@www.fastmail.com> <5f3801d4-0f88-47c5-a2ca-6b4f26dd2f75@www.fastmail.com> In-Reply-To: From: Rajini Sivaram Date: Thu, 16 Jan 2020 11:06:39 +0000 Message-ID: Subject: Re: [DISCUSS] KIP-515: Enable ZK client to use the new TLS supported authentication To: dev Content-Type: multipart/alternative; boundary="000000000000684ee0059c3fd2a2" --000000000000684ee0059c3fd2a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Forgot to mention: Overriding system property with a differently named Kafka configuration option is something we already do for JAAS configs - we default to System property `java.security.auth.login.config` if `sasl.jaas.config` is not configured. On Thu, Jan 16, 2020 at 10:58 AM Rajini Sivaram wrote: > Hi Ron/Colin, > > Thanks for the responses. I think we need to consider these cases: > > 1) The recommended approach: This is the one we document. Configs > consistent with Kafka make sense here. It seems a lot more confusing to > configure `ssl.cipher.suites`, `ssl.enabled.protocols`, ` > zookeeper.ssl.ciphersuites` and `zookeeper.ssl.enabledProtocols` with > multiple naming inconsistencies in server.properties. For users who have > never used ZK system properties, this is clearly simpler. Another config > to consider is `ssl.endpoint.identification.algorithm` which does the > same thing as `zookeeper.ssl.hostnameVerification` - if we are staying > consistent, we should use the Kafka format for this too. I would also > consider using something like `zookeeper.client.ssl.enabled` instead of ` > zookeeper.client.secure` since it is difficult to tell what `secure` > means when you have options to configure Kerberos, ACLs and/or SSL. > > 2) Inheritance using prefixed configs as we do for other prefixed configs > in Kafka: I think it may be useful for configs like `ssl.protocol` and ` > ssl.cipher.suites`. > > 3) Default values: Do we want to use Kafka defaults? The inconsistency we > have is `ssl.protocol/ssl.enabled.protocols` since we still have insecure > protocols enabled for Kafka. We have KIP-553 ( > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=3D142641= 956) > open to disable these. It is currently blocked since it also talks about > enabling TLSv1.3 by default and we haven't done sufficient testing for > that. Since it will be good to disable the older insecure protocols anywa= y, > perhaps we could do that without enabling TLSv1.3 by default in 2.5? > > 4) Backward compatibility for deployments which are using system > properties. We shouldn't override system properties with Kafka defaults o= r > inherited values. But we do want to override if user configures propertie= s > explicitly. In the current approach, this was simpler since we just had t= o > set the configured values. But if we decide to inherit Kafka configs, the= n > we will need to check system properties and update accordingly. But that > should be doable? > > On Wed, Jan 15, 2020 at 9:51 PM Colin McCabe wrote: > >> On Wed, Jan 15, 2020, at 13:41, Ron Dagostino wrote: >> > Hi Colin. Two things come to mind with respect to ZooKeeper camelCase >> > style vs Kafka-style config names for ZooKeeper. First, I think it >> > would be desirable for the client configs and broker configs to be >> > interoperable. For example, it feels like it would be convenient to >> > be able to pass the broker's config file to the ZK Security Migrator >> > tool. I think whatever we use (ZooKeeper camelCase style or Kafka >> > style), I think we should use the same for both. >> > >> > The second thing to think about is the fact that ZooKeeper >> > configuration inherently uses Java system properties as a first pass. >> > So while we might switch to Kafka-style configs in the config file >> > (e.g. zookeeper.ssl.trust.store.location), the >> > org.apache.zookeeper.client.ZKClientConfig class (which is how TLS >> > configs are set) is going to look for the camelCase >> > zookeeper.ssl.trustStore.location system property and use any value >> > there. I think this could be very confusing for people. Granted, we >> > are doing this so that people don't have to use system properties, but >> > there is no way to turn off the use of system properties, so I think >> > there would be pretty substantial potential for confusion. >> >> I don't think we document or recommend that anyone use system properties >> to configure Zookeeper usage within Kafka. And I think the reason is >> exactly the issue you pointed out -- it wouldn't be consistent with our >> other configurations. >> >> best, >> Colin >> >> > >> > One idea is to migrate the system properties -- i.e. look to see if >> > zookeeper.ssl.trustStore.location is set and if it is clear out the >> > value there and move it under the zookeeper.ssl.trust.store.location >> > system property. (I said it was an idea -- not necessarily a good one >> > :-) >> > >> > Ron >> > >> > On Wed, Jan 15, 2020 at 3:54 PM Colin McCabe >> wrote: >> > > >> > > On Wed, Jan 15, 2020, at 10:53, Ron Dagostino wrote: >> > > > Thanks Colin and Rajini. >> > > > >> > > > I've updated the KIP to say that KIP-421 functionality is availabl= e >> 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 a= nd >> > > > the data is needed to get to ZK in the first place). Colin, let m= e >> > > > 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 additiona= l >> > > > 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 ZooKeep= er >> > > > 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 conf= ig >> > > > 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 valu= e >> 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 >> > > >> > > I think, on balance, I agree with Rajini that it would be nice to >> make the configs look more like Kafka configs. We don't have camel-case= in >> configuration keys, so we should avoid it here. >> > > >> > > best, >> > > Colin >> > > >> > > > >> > > > 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 prior to >> > > > > > starting up brokers. We are now adding SSL keystore/truststore >> passwords >> > > > > > for ZooKeeper client that cannot be stored in ZooKeeper since >> you need >> > > > > > these to connect to ZK. We should perhaps document that these >> configs can >> > > > > > 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 a= nd >> truststore passwords to ZK in cleartext should be deprecated in favor of >> using KIP-421. >> > > > > >> > > > > > >> > > > > > 2) We can dynamically update keystores and trust stores used b= y >> brokers >> > > > > > without restarting the broker. Can we support this easily for >> ZK clients >> > > > > > 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 Z= K >> 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 least. >> > > > > > >> > > > > > >> > > > > > On Tue, Jan 14, 2020 at 5:14 PM Colin McCabe < >> cmccabe@apache.org> 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] >> could just >> > > > > > > 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 we add >> > > > > > > > that to ZkSecurityMigrator then it is trivial to add it to >> other commands >> > > > > > > > (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 have its >> > > > > > > > direct ZooKeeper access formally deprecated as per KIP-555= , >> but the >> > > > > > > special >> > > > > > > > use case of bootstrapping a ZooKeeper ensemble with >> encrypted credentials >> > > > > > > > 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 situatio= n. >> > > > > > > > >> > > > > > > > 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 now to move >> > > > > > > > this discussion forward. >> > > > > > > > >> > > > > > > > On Mon, Jan 6, 2020 at 5:07 PM Colin McCabe < >> cmccabe@apache.org> wrote: >> > > > > > > > >> > > > > > > > > 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 bootstrappin= g >> a Kafka >> > > > > > > cluster >> > > > > > > > > > with encrypted passwords in Zookeeper is an >> explicitly-supported use >> > > > > > > > > case; >> > > > > > > > > > therefore it is in scope to be able to securely >> configure the CLI >> > > > > > > tools >> > > > > > > > > > that still leverage non-deprecated direct Zookeeper >> communication >> > > > > > > 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 the >> > > > > > > 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 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 >> communication >> > > > > > > between >> > > > > > > > > > Zookeeper and: >> > > > > > > > > > a) Kafka brokers >> > > > > > > > > > b) The three CLI tools mentioned above that still >> support direct, >> > > > > > > > > > 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, fo= r >> backwards >> > > > > > > > > > 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 class >> > > > > > > > > supports >> > > > > > > > > > the ability to connect to a different Zookeeper >> instance than the >> > > > > > > one the >> > > > > > > > > > brokers use. We therefore also add the following >> optional configs, >> > > > > > > which >> > > > > > > > > > override the corresponding ones from above when presen= t: >> > > > > > > > > > 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 this >> > > > > > > could >> > > > > > > > > just appear in a configuration file, which all of these >> tools already >> > > > > > > > > accept (I think). >> > > > > > > > > >> > > > > > > > > best, >> > > > > > > > > Colin >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > Ron >> > > > > > > > > > >> > > > > > > > > > On Mon, Dec 23, 2019 at 3:03 PM Ron Dagostino < >> rndgstn@gmail.com> >> > > > > > > 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 thin= k >> there are >> > > > > > > some >> > > > > > > > > > > things we should clarify. >> > > > > > > > > > > >> > > > > > > > > > > 1) It is possible to use TLS connectivity to >> Zookeeper from Apache >> > > > > > > > > Kafka >> > > > > > > > > > > 2.4 -- the problem is that configuration information >> has to be >> > > > > > > passed >> > > > > > > > > via >> > > > > > > > > > > system properties as "-D" command line options on th= e >> java >> > > > > > > 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 >> configuration >> > > > > > > includes >> > > > > > > > > > > sensitive information (e.g. a keystore password), so >> we need a >> > > > > > > secure >> > > > > > > > > > > mechanism for passing the configuration values. I >> believe the real >> > > > > > > > > > > motivation for this KIP is to harden the >> configuration mechanism >> > > > > > > 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.ReassignPartitionsCommand >> > > > > > > > > > > c) kafka-configs.{sh, bat}/kafka.admin.ConfigComma= nd >> > > > > > > > > > > >> > > > > > > > > > > 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/adm= in/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-managed >> > > > > > > > > quorum >> > > > > > > > > > > referred to in KIP-500). >> > > > > > > > > > > >> > > > > > > > > > > I think it would be easier and simpler to harden the >> Zookeeper TLS >> > > > > > > > > > > configuration in both Kafka and in CLI tools compare= d >> 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, addin= g >> the >> > > > > > > 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 firs= t >> place. >> > > > > > > > > > > >> > > > > > > > > > > Regarding how to harden the TLS configuration for th= e >> 3 remaining >> > > > > > > CLI >> > > > > > > > > > > tools, it would be relatively straightforward to add >> support for a >> > > > > > > > > > > "--zk-tls-config-file > configuration system >> > > > > > > > > > > properties file path>" option to each one. >> > > > > > > > > > > >> > > > > > > > > > > Thoughts? >> > > > > > > > > > > >> > > > > > > > > > > Ron >> > > > > > > > > > > >> > > > > > > > > > > On Thu, Sep 12, 2019 at 8:13 AM Pere Urb=C3=B3n Baye= s < >> > > > > > > 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+Improvement+Prop= osals >> > > > > > > > > > >> ? >> > > > > > > > > > >> > >> > > > > > > > > > >> > I found the KIP number assigned to another. >> > > > > > > > > > >> > >> > > > > > > > > > >> > >> > > > > > > > > > >> > >> > > > > > > > > > >> > On Mon, Sep 2, 2019 at 2:23 PM Pere Urb=C3=B3n Ba= yes < >> > > > > > > > > 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 discussio= n >> 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 < >> kafka@harsha.io> del dia >> > > > > > > dv., >> > > > > > > > > 30 >> > > > > > > > > > >> >> d=E2=80=99ag. >> > > > > > > > > > >> >> >> 2019 a les 19:00: >> > > > > > > > > > >> >> >> >> > > > > > > > > > >> >> >>> Hi Pere, >> > > > > > > > > > >> >> >>> Thanks for the KIP. Enabling SSL >> for zookeeper >> > > > > > > for >> > > > > > > > > Kafka >> > > > > > > > > > >> >> makes >> > > > > > > > > > >> >> >>> sense. >> > > > > > > > > > >> >> >>> "The changes are planned to be introduced in >> a compatible >> > > > > > > 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 >> 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 to have >> > > > > > > this for >> > > > > > > > > > >> this >> > > > > > > > > > >> >> >>>> release, do you think we can make it? >> > > > > > > > > > >> >> >>>> >> > > > > > > > > > >> >> >>>> -- Pere >> > > > > > > > > > >> >> >>>> >> > > > > > > > > > >> >> >>>> Missatge de Pere Urb=C3=B3n Bayes < >> pere.urbon@gmail.com> 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, 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 communicatio= n >> in the new >> > > > > > > > > Zookeeper >> > > > > > > > > > >> >> 3.5.5. >> > > > > > > > > > >> >> >>>> Specially interesting it the Zookeeper >> Security Migration, >> > > > > > > > > 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+ZK+c= lient+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/ >> > > > > > > > > > >> >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > >> > >> > --000000000000684ee0059c3fd2a2--