Apache Solr Reference Guide Covering Apache Solr 6.0

When solr wants to create a new znode, it determines which ACLs to put on the znode by calling the getACLsT
oAdd() method of the given acl provider. If no provider has been configured, the default implementation, Defau
ltZkACLProvider is used.
Out of the Box Implementations
You can always make you own implementation, but Solr comes with:
org.apache.solr.common.cloud.DefaultZkACLProvider: It returns a list of length one for all z
NodePath-s. The single ACL entry in the list is "open-unsafe". This is the default and is used if you do not
configure a provider in solr.xml.
org.apache.solr.common.cloud.VMParamsAllAndReadonlyDigestZkACLProvider: This lets
you define your ACLs using system properties. Its getACLsToAdd() implementation does not use zNod
ePath for anything, so all znodes will get the same set of ACLs. It supports adding one or both of these
options:
A user that is allowed to do everything.
The permission is " ALL" (corresponding to all of CREATE, READ, WRITE, DELETE, and ADMI
N), and the schema is "digest".
The username and password are defined by system properties " zkDigestUsername" and "
zkDigestPassword", respectively.
This ACL will not be added to the list of ACLs unless both username and password are
provided.
A user that is only allowed to perform read operations.
The permission is " READ" and the schema is "digest".
The username and password are defined by system properties "zkDigestReadonlyUsern
ame" and " zkDigestReadonlyPassword, respectively.
This ACL will not be added to the list of ACLs unless both username and password are
provided.
If neither of the above ACLs is added to the list, the (empty) ACL list of DefaultZkACLProvider will
be used by default.
Notice the overlap in system property names with credentials provider VMParamsSingleSetCredentialsDig
estZkCredentialsProvider (described above). This is to let the two providers collaborate in a nice and
perhaps common way: we always protect access to content by limiting to two users - an admin-user and a
readonly-user - AND we always connect with credentials corresponding to this same admin-user, basically so
that we can do anything to the content/znodes we create ourselves.
You can give the readonly credentials to "clients" of your SolrCloud cluster - e.g. to be used by SolrJ clients.
They will be able to read whatever is necessary to run a functioning SolrJ client, but they will not be able to
modify any content in ZooKeeper.
Changing ACL Schemes
Over the lifetime of operating your Solr cluster, you may decide to move from an unsecured ZooKeeper to a
secured instance. Changing the configured zkACLProvider in solr.xml will ensure that newly created nodes
are secure, but will not protect the already existing data. To modify all existing ACLs, you can use: ZkCLI -cmd
updateacls /zk-path.
Changing ACLs in ZK should only be done while your SolrCloud cluster is stopped. Attempting to do so while
Solr is running may result in inconsistent state and some nodes becoming inaccessible. To configure the new
ACLs, run ZkCli with the following VM properties: -DzkACLProvider=...
-DzkCredentialsProvider=....
The Credential Provider must be one that has current admin privileges on the nodes. When omitted, the
process will use no credentials (suitable for an unsecure configuration).
The ACL Provider will be used to compute the new ACLs. When omitted, the process will set all
Apache Solr Reference Guide 6.0
563