Securing Solr Deployments – SearchStax
SearchStax® Managed Solr takes the security of your Solr search infrastructure very seriously. We have built-in industry-standard security at the level of the cluster, network and Managed Solr dashboard. Custom firewall rules enable you to lock down your search infrastructure to a whitelist of IP addresses and IP address ranges. Solr basic authentication lets you restrict search access to clients with appropriate user credentials.
The Managed Solr dashboard and all communications between SearchStax and your search engine use Secure-Sockets Layer encryption (SSL). This is the system’s default behavior out of the box.
SearchStax requires Zookeeper to be locked down by IP Filters.
See our Help Center page, How can I Secure Zookeeper? for additional information.
All SearchStax users log in using their business email address and a strong password. Each user may optionally enable two-factor authentication as a standard SearchStax feature.
Premium clients may request SAML-based single sign-on (SSO) using Microsoft Azure Active Directory as an add-on service.
Advanced Security Options
Premium customers may also request at-rest encryption for their data files. Please contact us for more information.
- Cluster Security
- Activity Log
You can lock down your clusters as described below.
Connecting to the Cluster
SearchStax recommends that you situate your application infrastructure in the same local network as your hosting provider (for example, AWS or Azure). Internal network security for these hosting providers is extremely high and eliminates any chance of a hacker potentially sniffing your network traffic.
If your application is hosted elsewhere, try to host it as close to your search infrastructure as possible. This can be done by choosing the Cloud Provider Region which is closest to your application. This improves both security and performance.
Solr Basic Authentication
You can optionally enable the Solr Basic Authentication Plugin through the Managed Solr Dashboard. This restricts access to your Solr dashboard and demands authorization for query requests and index updates.
Warnings: Effects of Basic Authentication
- Enabling/Disabling this feature will suspend service for a couple of minutes while it restarts
all of your Solr nodes.
- Once enabled, Solr will require a username and password for:
- Opening the Solr Dashboard.
- Making a query request (via the /select command).
- Adding records to the index (via the /update command).
- When disabled, Solr will delete all existing Solr users.
To enable the Basic Authentication plugin:
- Select the desired Deployment and click the Security > Auth command in the menu bar.
- Click the Enable button.
- Add a user, entering the username, password and role (see below). Click Add.
Note that Solr user accounts are independent of SearchStax user accounts.
To disable the Authentication and Authorization plugin, click on the Disable Auth button and confirm the action. Disabling Basic Auth erases all Solr users. (Again, Solr services will be restarted.)
Solr Basic Authentication provides four user roles:
- Admin users have full access to the Solr Dashboard. They can query the index from an external location using a /select command, and they can load new records into the index using a /update command.
- Read users can query the index using /select.
- Write users can add new records to the index using /update.
- ReadWrite users can use both /select and /update, but cannot access the Solr Dashboard.
Using /select and /update with Solr Basic Auth
After enabling Solr authentication, your /select and /update interactions with
Solr must include the username and password of a Solr user.
For cURL, add the Solr credentials using the
-u 'username:password' parameter.
If your search application doesn’t use cURL, your <Solr HTTP Endpoint> changes from
Connections to Zookeeper remain unchanged.
When Solr or ZooKeeper become Unreachable
Most IT departments and ISPs issue IP addresses using the Dynamic Host Configuration Protocol (DHCP).Your workstation’s IP address can change without warning. When it does, you’ll have to update your IP filter settings.
You can limit access to a Solr deployment to a list of IP addresses using the Security > IP Filter menu.
You can configure access for Solr+Zookeeper, Solr, and Zookeeper endpoints separately.
CIDR notation can be daunting, but note the following three examples of typical CIDR rules:
- 0.0.0.0/0 This rule permits unrestricted access to Solr. Any IP address whatsoever may connect. (Managed Solr will refuse to accept this value if you try to enter it for Zookeeper.)
- 22.214.171.124/32 This rule permits a connection from exactly one IP address.
- 126.96.36.199/24 This rule allows Solr access from any of the 256 IP addresses on a subnet.
The /n at the end of each rule is called the prefix length.
To limit access to a specific IP address or IP address range:
- From within a Deployment’s details page, click on the Security > IP filter menu.
- Click on Add Row.
- Add a specific IP address in the appropriate field. Note that Managed Solr can detect your computer’s IP address. Click My current IP to enter it automatically.
- Select a service you need to limit access to (Solr+Zookeeper, Solr, or Zookeeper).
- Click Save changes.
To remove a filter, click on the X button and then Save changes.
The Security > API Keys menu option exposes a table of the deployment’s API Keys.
Note a subtle ease-of-use feature here: This is the only place in the Managed Solr Dashboard where you can mark/copy the API Key, the Account Name, and the Deployment ssID Number. These values are heavily used in the SearchStax API.
SearchStax User Roles
Each SearchStax account is restricted to the Owner of that account plus any SearchStax users who have been granted access to that account by the owner. The additional users may be limited to specific roles at the Owner’s discretion. See SearchStax User Roles.
The Managed Solr activity log provides you with a list of all user actions within your account, including those of the SearchStax Support team. The list consists of a User column including email of the user who performed the logged change, his/her role, Timestamp of action in UTC, Action itself, Action detail and IP address where the action originated.