zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: Zookeeper server with SASL allows any old zkCli instance to connect
Date Fri, 28 Aug 2015 14:36:32 GMT
On Fri, Aug 28, 2015 at 7:15 AM, Daniel Kashtan <djkashtan@gmail.com> wrote:
> I understand, I got lost quite a bit trying to follow the documentation out
> on the internet. The official documentation needs to be updated with this
> information. I actually figured this out yesterday and I have my Zookeeper
> setup with satisfactory security.
>

Fixing issues you find is a great way to get involved. That includes
docs or just entering a jira.

> Also, in 3.5 there is going to be SSL encryption, and excuse my naivety,
> but will that block users from connecting if they are not authenticated or
> will it use authorization via ACLs?
>

I believe you can do bi-di certs on SSL, but I've not tried that.

Patrick

> On Thu, Aug 27, 2015 at 10:36 PM, Patrick Hunt <phunt@apache.org> wrote:
>
>> Hi Daniel. We provide authorization on znodes via ACL, but we don't
>> use authentication to exclude particular clients from using the
>> service. Just because you can authenticate doesn't mean much. Say you
>> have valid kerberos credentials, what does that mean in the context of
>> a particular znode w/o ACL?
>>
>> ZK was meant as a multi-application service. We protect against one
>> application impacting another if ACLs are used. Say you have two
>> services A and B using ZK, they both have valid credentials. It is
>> still likely the case that they shouldn't access each other's znodes
>> (say HBase and Solr as concrete examples, they might be managed by
>> totally different teams with different security constraints)
>>
>> Hope this helps,
>>
>> Patrick
>>
>> On Wed, Aug 26, 2015 at 8:23 AM, Daniel Kashtan <djkashtan@gmail.com>
>> wrote:
>> > also, just to be clear, my zoo.cfg does have
>> "requireClientAuthScheme=sasl"
>> > in it, but non-authenticated clients are still able to create, delete,
>> > read, and update znodes...
>> >
>> > On Wed, Aug 26, 2015 at 10:58 AM, Daniel Kashtan <djkashtan@gmail.com>
>> > wrote:
>> >
>> >> As an update, I found out that this issue is not confined to just
>> >> zkCli.sh. If I launch my java applications that create zookeeper clients
>> >> without the JVM argument
>> >> "-Djava.security.auth.login.config=<my-client-jaas.conf>", then my
>> client
>> >> can log in to my zookeeper server. Why is it that my zookeeper client is
>> >> rejected if I have the wrong password in my client jaas.conf file, but
>> if I
>> >> fail to specify my client as using any security, it just connects to the
>> >> server? Surely I am missing something on my server side to block these
>> >> client connections right?
>> >>
>> >> On Tue, Aug 25, 2015 at 5:37 PM, Daniel Kashtan <djkashtan@gmail.com>
>> >> wrote:
>> >>
>> >>> I am using SASL with Digest-MD5 and I have the flag
>> >>> "-Dzookeeper.allowSaslFailedClients=false" set so that your connection
>> is
>> >>> dropped from the Zookeeper Server if your SASL authentication fails.
>> This
>> >>> is great! This only works for the Zookeeper clients created in java
>> code
>> >>> though.
>> >>>
>> >>> If I do a zkCli.sh -server 127.0.0.1:2181 then I can connect to my
>> >>> Zookeeper server with no issues. This is unexpected behavior to me.
It
>> even
>> >>> says in the output from zkCli.sh, "Will not attempt to authenticate
>> using
>> >>> SASL." How does this still work? I configured the Zookeeper server to
>> drop
>> >>> those connection attempts.
>> >>>
>> >>> After much searching I turned up this link
>> >>> <
>> https://groups.google.com/a/cloudera.org/forum/#!topic/cdh-user/Hxqv7b2957w
>> >,
>> >>> but it is just some forum post for CDH. Is this true? The thought of
>> >>> setting ACLs on all my znodes is daunting and verbose. Please let me
>> know
>> >>> if setting ACL nodes using SASL is my best and/or only option for
>> securing
>> >>> zkCli.sh and my Zookeeper server in general.
>> >>> --
>> >>> -Daniel
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> -Daniel
>> >>
>> >
>> >
>> >
>> > --
>> > -Daniel
>>
>
>
>
> --
> -Daniel

Mime
View raw message