zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kashtan <djkash...@gmail.com>
Subject Re: Zookeeper server with SASL allows any old zkCli instance to connect
Date Fri, 28 Aug 2015 14:15:16 GMT
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.

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?

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message