On Fri, Aug 28, 2015 at 7:15 AM, Daniel Kashtan <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> > 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 <[email protected]> >> >> 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
