If you use Apache SolrCloud you shouldn’t rely only on firewalls to shield both Zookeeper and the Solr Admin UI from the outside worlds. Firewall rules simply aren’t a sufficient path to securing a SolrCloud cluster because firewall rules often change for a variety of reasons. And usually not great ones. Case in point when administrators from disparate groups open ports that were previously closed because either a new application (or a new perimeter defense system for managing those rules) came online. 

The other reason firewall rules are simply not enough is the person wishing to take down SolrCloud could be in your network. The correct approach to securing a SolrCloud cluster is to implement one of the many authentication plugins available in open source for securing Solr, in addition to network defense. 

Securing With Basic Authentication

The simplest path to securing your SolrCloud cluster is the Basic Authentication plugin, also known as Basic Auth, but it has some gotchas. In fact, conventional wisdom is that Basic Auth is not secure as credentials are sent as cleartext and can be vulnerable to packet sniffing. However, if that connection is secured using TLS/SSL then it is as secure as other methods that use encryption.

In this blog post covering my presentation at Activate 2019, the Search and AI conference, I will introduce a backward-incompatible change I added to Solr 9 to add even more security to Basic Auth — and what it means for your users. 

Basic Auth, like the Kerberos and JWT plugins, is configured in the security.json file. This file is stored in Zookeeper like most configuration files in the SolrCloud world. The file informs SolrCloud which authentication class to invoke, who has what permissions, and whether or not the authentication defined in the file should actually be enforced. 

That’s right, even if you “enable” the Basic Auth plugin by simply adding the class to the security.json, authentication will not be invoked in versions before the unreleased version 9.0 where I made the contribution until you add the parameter “blockUnknown” and set it to “true” because that parameter defaults to “false”. Most users set the parameter appropriately, but let’s jump into the anatomy of the file to ensure that you set it up correctly in your cluster. 

A fully-baked and blocking  unauthorized users–security.json looks like this when enabling BasicAuth:


How to Curl Basic Auth and the zkCLI

To quickly test if you have security enabled you can run:
curl http://localhost:8983/solr/admin/authentication

curl http://localhost:8983/solr/admin/authorization
To put a security.json file in Zookeeper, use the Zookeeper CLI (ZKcli):

server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983 -cmd putfile /security.json security.json

In Solr 9, if you have Basic Auth enabled but do not have any users configured, Solr will return a server error because all unauthenticated requests made against the API will be blocked. That will interrupt some developers’ workflow who were accustomed to setting up users for Basic Auth after first enabling the plugin. 

Most advanced users will say, an SSH tunnel to Solr Administrative capabilities is the best way to go in production development tiers. I agree with them. However, for many users, that’s not even an option. For others, it’s overkill. Basic Auth was designed to be exactly what it is called, “basic.” In that way, it may be protecting some of the most vulnerable users on the internet. That’s why I made it better. 

Here’s a link to the JIRA: https://issues.apache.org/jira/browse/SOLR-1364


Here’s a video of my talk at Activate:

Please accept statistics, marketing cookies to watch this video.

Here’s a video on how to get Basic Auth set up in seven minutes: 

Please accept statistics, marketing cookies to watch this video.


About Marcus Eagan

Read more from this author


Contact us today to learn how Lucidworks can help your team create powerful search and discovery applications for your customers and employees.