Securing Solr
|
No Solr API, including the Admin UI, is designed to be exposed to non-trusted parties. Tune your firewall so that only trusted computers and people are allowed access. Because of this, the project will not regard e.g., Admin UI XSS issues as security vulnerabilities. However, we still ask you to report such issues in JIRA. |
When planning how to secure Solr, you should consider which of the available features or approaches are right for you:
Encryption with TLS (SSL) Certificates
Encrypting traffic to/from Solr and between Solr nodes prevents sensitive data to be leaked out on the network. TLS is also normally a requirement to prevent credential sniffing when using Authentication.
See the section Enabling SSL for details.
Authentication and Authorization
Use the Security UI screen in the Admin UI to manage users, roles, and permissions.
See section Configuring Authentication and Authorization to learn how to work with the security.json file.
Authentication Plugins
Authentication makes sure you know the identity of your users. The authentication plugins that ship with Solr are:
Audit Logging
Audit logging will record an audit trail of incoming reqests to your cluster, such as users being denied access to admin APIs. Learn more about audit logging and how to implement an audit logger plugin in the section Audit Logging.
IP Access Control
Restrict network access to specific hosts, by setting SOLR_IP_ALLOWLIST/SOLR_IP_DENYLIST via environment variables or in solr.in.sh/solr.in.cmd.
# Allow IPv4/IPv6 localhost, the 192.168.0.x IPv4 network, and 2000:123:4:5:: IPv6 network.
SOLR_IP_ALLOWLIST="127.0.0.1, [::1], 192.168.0.0/24, [2000:123:4:5::]/64"
# Explicitly deny access to two problematic hosts.
SOLR_IP_DENYLIST="192.168.0.3, 192.168.0.4"Securing ZooKeeper Traffic
ZooKeeper is a central and important part of a SolrCloud cluster and understanding how to secure its content is covered in the section ZooKeeper Access Control.
Network Configuration
Administrators should consider their security setup carefully as an important step in moving to production. Solr provides a number of features out of the box to meet the security needs of users: authentication and authorization can be configured using a range of security plugins, privacy can be bolstered by enabling SSL/TLS, and (in SolrCloud) ZooKeeper data can be protected with ACL rules to prevent unauthorized reads and writes.
Even if these measures or others are taken, it is strongly recommended that Solr always be protected by a firewall. Solr is not designed to be exposed on the open internet.
It is also strongly recommended that Solr listen to only those network interfaces that are strictly required.
To prevent administrators from unintentionally exposing Solr more broadly, Solr only listens on the loopback interface ("127.0.0.1") by default.
Most deployments will need to change this value to something less restrictive so that it can be reached from other boxes.
This can be done by setting a SOLR_JETTY_HOST value in your environment’s "include script" (solr.in.sh or solr.in.cmd):
----
SOLR_JETTY_HOST="0.0.0.0"
----The same setting is also available as the -Dsolr.jetty.host System Property.
The same is true for the embedded Zookeeper, if it is run with Solr.
By default, the embedded Zookeeper only listens on the loopback interface ("127.0.0.1")
The bind host is controlled via the SOLR_ZK_EMBEDDED_HOST value in your environment’s "include script" (solr.in.sh or solr.in.cmd):
----
SOLR_ZK_EMBEDDED_HOST="0.0.0.0"
----The same setting is also available as the -Dsolr.zk.embedded.host System Property.