Apache ZooKeeper ACLs Best Practices
As more and more components begin to rely on ZooKeeper within a Hadoop cluster, there are various permissions that need to be maintained to ensure the integrity and security of the znodes. These permissions are different from component to component. You must follow the required steps for tightening the ZooKeeper ACLs or permissions when provisioning a secure cluster as a best practices guideline.
Introduction
Some components only use ZooKeeper when they are running in their component specific HA mode. Others have separate secure and unsecure ACLs defined and switch between which to enforce based on the component knowledge of whether the cluster is secured or not.
In general, ACLs are pretty open and assume an unsecure cluster by default. These permissions need to be hardened for secure clusters in order to avoid inappropriate access or modification of this critical platform state.
Unaffected Components
-
Ambari
-
ZooKeeper Usage: Ambari does not use ZooKeeper; however it does install, configure, and manage it so that services running on the cluster can use it.
-
Default ACLs: None. Ambari does not create or use any znodes.
-
Security Best Practice ACLs/Permissions and Required Steps: None. Ambari does not create or use any znodes.
-
-
Calcite
-
DataFu
-
Knox
-
MapReduce
-
Phoenix
-
ZooKeeper Usage: Phoenix does not use ZooKeeper on its own. All usages are covered in the HBase section.
-
Security Best Practice ACLs/Permissions and Required Steps: None. HBase correctly protects all znodes in ZooKeeper automatically.
-
-
Pig
-
Spark
-
Sqoop
-
Stargate/HBase RestServer
-
No ZooKeeper usage outside of normal HBase client usage.
-
-
Tez
-
Zeppelin