Apache Solr Reference Guide Covering Apache Solr 6.0

Changing ACL Schemes
Example Usages
About ZooKeeper ACLs
SolrCloud uses ZooKeeper for shared information and for coordination.
This section describes how to configure Solr to add more restrictive ACLs to the ZooKeeper content it creates,
and how to tell Solr about the credentials required to access the content in ZooKeeper. If you want to use ACLs
in your ZooKeeper nodes, you will have to activate this functionality; by default, Solr behavior is open-unsafe
ACL everywhere and uses no credentials.
Changing Solr-related content in ZooKeeper might damage a SolrCloud cluster. For example:
Changing configuration might cause Solr to fail or behave in an unintended way.
Changing cluster state information into something wrong or inconsistent might very well make a SolrCloud
cluster behave strangely.
Adding a delete-collection job to be carried out by the Overseer will cause data to be deleted from the
cluster.
You may want to enable ZooKeeper ACLs with Solr if you grant access to your ZooKeeper ensemble to entities
you do not trust, or if you want to reduce risk of bad actions resulting from, e.g.:
Malware that found its way into your system.
Other systems using the same ZooKeeper ensemble (a "bad thing" might be done by accident).
You might even want to limit read-access, if you think there is stuff in ZooKeeper that not everyone should know
about. Or you might just in general work on need-to-know-basis.
Protecting ZooKeeper itself could mean many different things. This section is about protecting Solr content
in ZooKeeper. ZooKeeper content basically lives persisted on disk and (partly) in memory of the ZooKeeper
processes. This section is not about protecting ZooKeeper data at storage or ZooKeeper process levels -
that's for ZooKeeper to deal with.
But this content is also available to "the outside" via the ZooKeeper API. Outside processes can connect to
ZooKeeper and create/update/delete/read content; for example, a Solr node in a SolrCloud cluster wants to
create/update/delete/read, and a SolrJ client wants to read from the cluster. It is the responsibility of the outside
processes that create/update content to setup ACLs on the content. ACLs describe who is allowed to read,
update, delete, create, etc. Each piece of information (znode/content) in ZooKeeper has its own set of ACLs, and
inheritance or sharing is not possible. The default behavior in Solr is to add one ACL on all the content it creates
- one ACL that gives anyone the permission to do anything (in ZooKeeper terms this is called "the open-unsafe
ACL").
How to Enable ACLs
We want to be able to:
1.
2.
3.
Control the credentials Solr uses for its ZooKeeper connections. The credentials are used to get
permission to perform operations in ZooKeeper.
Control which ACLs Solr will add to znodes (ZooKeeper files/folders) it creates in ZooKeeper.
Control it "from the outside", so that you do not have to modify and/or recompile Solr code to turn this on.
Solr nodes, clients and tools (e.g. ZkCLI) always use a java class called SolrZkClient to deal with their
ZooKeeper stuff. The implementation of the solution described here is all about changing SolrZkClient. If you
use SolrZkClient in your application, the descriptions below will be true for your application too.
Controlling Credentials
You control which credentials provider will be used by configuring the zkCredentialsProvider property in so
Apache Solr Reference Guide 6.0
561