Hi Rajini. Thanks. Yes, I’ll update the KIP, and then I’ll start the vote.
Ron
> On Jan 20, 2020, at 6:30 AM, Rajini Sivaram wrote:
>
> Hi Ron,
>
> Good point. Keystore and truststore configs (type/location/password) are
> dynamically reconfigurable. A few of them like protocol, enabled.prot
Hi Ron,
Good point. Keystore and truststore configs (type/location/password) are
dynamically reconfigurable. A few of them like protocol, enabled.protocols,
cipher.suites and endpoint.identification.algorithm are not. But to keep it
simple, it may be better not to inherit any of the SSL configs. P
Thanks, Rajini. Still not sure what the answer is, but I thought of a
couple more issues with config inheritance that I wanted to raise.
The first is a minor issue, but just to document it (and I will add it
to the KIP as well), ZooKeeper does not support a key password that
differs from the keyst
Hi Ron,
For Kafka, we moved from hostname verification disabled-by-default to
enabled-by-default under
https://cwiki.apache.org/confluence/display/KAFKA/KIP-294+-+Enable+TLS+hostname+verification+by+default.
So we have tested empty String for disabling hostname verification and we
know that it wor
Hi again, Rajini. I've updated the KIP, and while doing it I became
concerned about using zookeeper.ssl.endpoint.identification.algorithm
for enabling/disabling hostname verification. The KIP reflects what
we decided, but upon reading it, I wonder if it is workable. Here's
what it says for this
Hi Rajini. I’ll submit a documentation PR to clarify the Kafka behavior of #1
and will adopt the same config for ZK. I agree now we should inherit for
AclAuthorizer too — I was just stuck on the “no inheritance” idea more than I
realized, and while the ZK quorums are different that doesn’t nec
Hi Ron,
Unresolved item #1: Yes, Kafka disables hostname verification if
"ssl.endpoint.identification.algorithm" is an empty string.
Unresolved item #2: Yes, those 9 plus hostname verification. If we do
decide to inherit Kafka configs, wouldn't we inherit these 10 in
AclAuthorizer as well?
Unres
Hi Colin. TLS to ZooKeeper will remain an opt-in. The configuration
value that turns it on is zookeeper.ssl.client.enable (which used to
be called zookeeper.client.secure before we renamed everything to be
consistent with Kafka's config naming style and eliminate confusion).
The default value for
On Thu, Jan 16, 2020, at 02:58, 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
Hi Rajini. Thanks for the feedback. I have now come around to the
idea of abandoning the ZooKeeper camelCase style in favor of being
consistent with the existing Kafka broker configs. Here's what I've
done:
#1) ZK style vs. Kafka style
I've updated the KIP to convert all of the following confi
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
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.cipher
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
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 brok
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 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
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 dat
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
> start
Hi Manikumar. Yes, you are correct: if the ZK Security Migrator session
authenticates to ZooKeeper with multiple identities — SASL and certificate —
then ACLs are applied authorizing both the SASL principal and the certificate
DN.
Ron
> On Jan 15, 2020, at 6:33 AM, Manikumar wrote:
>
> Hi R
Hi Ron,
Thanks for the KIP. KIP looks good to me.
Am I correct in understanding that, when we run ZkSecurityMigrator with
SASL + SSL, multiple identities will be added to the ACLs?
Thanks,
On Wed, Jan 15, 2020 at 1:19 AM Rajini Sivaram
wrote:
> Hi Ron,
>
> Thanks for the detailed explanation,
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
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
Hi Rajini. Thanks for pointing out kafka-acls as another bootstrap use
case. I will update the KIP to mention it. (BTW, I sent an email on 1/8
stating that I had updated the KIP to reflect the current understanding and
discussion, but that email did not go through -- the KIP has undergone a
major
Resending this note which wasn't delivered when it was sent on Jan 6th:
Hi Ron,
Thanks for taking over this KIP. Is it possible to use SASL/GSSAPI with SSL
for ZooKeeper like we do in Kafka? If not, we need to describe that in the
migration section. We should also document the principals used for
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
Hi Pere,
It is a very meaningful KIP to make kafka broker -> ZK connection secured.
In the meanwhile, there is another KIP under discussion talking about making
SSLContext pluggle on broker side -
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=128650952.
Instead of putting cre
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 kaf
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
wit
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 pa
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 del dia
dt., 3 de set. 2019 a les 13:43:
> Hi Pere,
>
> Have you add your KIP to the list here
>
Hi Ismael,
fair point and totally reasonable point. I added the CLI part to bring
compatibility, but I can agree with not doing it right now per
compatibility reasons. However, I do have a question for you: You say most
of the CLI tools, is there anyone in your mind that you recall that
would br
Hi Pere,
Thanks for the KIP. With regards to the CLI tools, most of them support
direct access to ZK for compatibility reasons and we encourage usage of the
Kafka protocol instead. I am not sure we should be extending them as
described in the KIP. What are your thoughts on that?
Ismael
On Thu, A
Hi Pere,
Have you add your KIP to the list here
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals?
I found the KIP number assigned to another.
On Mon, Sep 2, 2019 at 2:23 PM Pere Urbón Bayes
wrote:
> Thanks for your time Harsha,
>anyone else with comments? loo
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’ag.
2019 a les 21:59:
> Thanks Pere. KIP looks good to me.
> -Harsha
>
>
> On Fri, Aug 30,
Thanks Pere. KIP looks good to me.
-Harsha
On Fri, Aug 30, 2019 at 10:05 AM, Pere Urbón Bayes
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 y
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 di
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
It helps as a beginner! thanks for sharing!
any tip for getting reviewers to take a look? :pray:, :pray: ;-)
-- Pere
Missatge de Colin McCabe del dia dv., 30 d’ag. 2019 a
les 18:57:
> Hi Pere,
>
> It will depend on how quickly the KIP can be voted in, and then
> implemented.
>
> Manikumar Redd
Hi Pere,
It will depend on how quickly the KIP can be voted in, and then implemented.
Manikumar Reddy is going to be the release manager for Apache Kafka 2.4.0.
Right now, the KIP freeze is scheduled for Sep 25, 2019. A KIP must be
accepted by this date in order to be part of 2.4.0. (Being a
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ón Bayes del dia dj., 29 d’ag.
2019 a les 20:10:
> Hi,
> this is my first KIP for a c
39 matches
Mail list logo
