Support Questions
Find answers, ask questions, and share your expertise

5.16.1 CDH Enabled Kerberos of Zookeeper in Big Data Appliance cluster, while Zookeeper can access without principal


In Kerberos cluster, zookeeper-client utility should ask for kinit of zookeeper principal however it is not happening(It is big security concern)


bug mentioned below in the post will be fixed at Zookeeper 3.6.0. And I have checked  in latest release CDH6.2.1, Zookeeper version in CDH6.2.1 is 3.4.5 also, there still have this issue.


Would you show us which BDA version will include Zookeeper 3.6.0?  

And is it possible to upgrade Zookeeper 3.4.5 to Zookeeper 3.6.0 independently in BDA?

Any remote zookeeper client can connect zookeeper server to read znode without authentication. I agree, there is way to enforce SASL authentication but currently there is no way to enforce authentication using the plugin mechanism. Enforcing authentication for that is more tricky since authentication can come any time later. This option doesn't drop the connection if there was no authentication. It is only throwing NoAuth for any operation until the Auth packet arrives.


As far as I know and understands,  Security of zookeeper is "open" and if you want to create something "protected" you have to do it explicitly.


Create a protected znode from within the ZooKeeper CLI. Make sure that you substitute YOUR-REALM as appropriate.

Example -

create /znode1 znode1data sasl:zkcli@{{YOUR-REALM}}:cdwra


Bugs and enhancements for your reference –

Proposal to ZooKeeper: authentication enforcement

Force authentication/authorization


Zookeeper grants permissions through ACLs through different schemas or authentication methods, such as 'world', 'digest', or 'sasl' if we use Kerberos.

Here a sample in a Big Data Appliance.

[zk: localhost:2181(CONNECTED) 1] ls /
[zookeeper, yarn-leader-election, hadoop-ha, rmstore, kmsZKRoot, zkdtsm, hive_zookeeper_namespace_hive, keytrustee, sentry]
[zk: localhost:2181(CONNECTED) 2] getAcl /hadoop-ha
: cdrwa
[zk: localhost:2181(CONNECTED) 4] ls /hadoop-ha
[templatecluster-ns, TOTO-ns]
[zk: localhost:2181(CONNECTED) 5]  getAcl /hadoop-ha/TOTO-ns
: cdrwa
[zk: localhost:2181(CONNECTED) 6] ls /hadoop-ha/TOTO-ns
Authentication is not valid : /hadoop-ha/TOTO-ns

[zk: localhost:2181(CONNECTED) 0] addauth digest hdfs-fcs:2pHx7qw0LkHwy9E3Qbj3vxgh9A6e34

[zk: localhost:2181(CONNECTED) 1]  ls /hadoop-ha/TOTO-ns
[ActiveBreadCrumb, ActiveStandbyElectorLock]

[zk: localhost:2181(CONNECTED) 2] create /zkPro myData
Created /zkPro

[zk: localhost:2181(CONNECTED) 4]  getAcl /zkPro
: cdrwa

[zk: localhost:2181(CONNECTED) 13] setAcl /zkPro digest:hdfs-fcs:I/OoJriH1A7bSgK8vK6NPgJIJHI=:rwcda;
Unknown perm type: ;
cZxid = 0x13001bbef5
ctime = Mon Nov 18 14:21:52 UTC 2019
mZxid = 0x13001bbef5
mtime = Mon Nov 18 14:21:52 UTC 2019
pZxid = 0x13001bbef5
cversion = 0
dataVersion = 0
aclVersion = 1
ephemeralOwner = 0x0
dataLength = 6
numChildren = 0

[zk: localhost:2181(CONNECTED) 19]  getAcl /zkPro
: cdrwa

If I try again without doing addauth + digest, I will have an error

[zk: localhost:2181(CONNECTED) 1] ls /zkPro
Authentication is not valid : /zkPro

You can find the digest in the core-site.xml.




Super Collaborator

@pra_big ,


Thanks for reaching out to the community.


We do have an old internal jira CDH-24088 open which is associated to the upstream zookeeper jiras you mentioned. It looks like the ZOOKEEPER-1634 was recently resolved upsteam. It usually take some time to bring the fix into CDH.


I have just updated the internal jira to bring attention to our engineering team and if there is any new update, will definitely let you know.




Li Wang, Technical Solution Manager

Was your question answered? Make sure to mark the answer as the accepted solution.
If you find a reply useful, say thanks by clicking on the thumbs up button.

Learn more about the Cloudera Community:

Terms of Service

Community Guidelines

How to use the forum

Take a Tour of the Community
Don't have an account?
Your experience may be limited. Sign in to explore more.