Securing a DSE Search cluster

DSE Search data is completely or partially secured by using DataStax Enterprise security features.

DataStax Enterprise supports secure enterprise search using Apache Solr and Lucene. The security table summarizes the security features of DSE Search and other integrated components.

For optimal security, DataStax recommends using CQL Solr queries in DSE Search.

DSE Search data is completely or partially secured by using DataStax Enterprise security features:

Object permission management
Access to Solr documents, excluding cached data, can be limited to users who have been granted access permissions. Object permission management also secures tables used to store Solr data.
Transparent data encryption
Data at rest in Cassandra tables, excluding cached and Solr-indexed data, can be encrypted. Transparent data encryption occurs on the Cassandra side and impacts performance slightly.
Internode (node-to-node) encryption
Internal, node-to-node Solr communication uses the netty transport. Enable and set the server_encryption_options in the cassandra.yaml file to secure your Solr internode communication.
Client-to-node encryption
You can use SSL to encrypt HTTP access to Solr data. Enable SSL Client-to-node encryption on the DSE Search node.
Strong cipher suites
If you use strong cipher suites to ensure secure node-to-node and client-to-node communication, you must install JCE to ensure support for all encryption algorithms. Some of the cipher suites in the default set of server_encryption_options in cassandra.yaml are included only in the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. To ensure support for all encryption algorithms, install the JCE Unlimited Strength Jurisdiction Policy Files.
Kerberos authentication: required for DSE Search in production 
You can authenticate DSE Search users through Kerberos authentication using Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO). To use the SolrJ API against DSE Search clusters with Kerberos authentication, configure client applications to use the SolrJ-Auth library and the DataStax Enterprise SolrJ component as described in the solrj-auth-README.md file.
Cassandra internal authentication or DataStax Enterprise LDAP authentication
To configure DSE Search to use Cassandra internal authentication:
  1. Comment AllowAllAuthenticator and uncomment the PasswordAuthenticator in cassandra.yaml to enable HTTP Basic authentication for Solr.
    #authenticator: org.apache.cassandra.auth.AllowAllAuthenticator
    authenticator: org.apache.cassandra.auth.PasswordAuthenticator
    #authenticator: com.datastax.bdp.cassandra.auth.PasswordAuthenticator
    #authenticator: com.datastax.bdp.cassandra.auth.KerberosAuthenticator
  2. Configure the replication strategy for the system_auth keyspace.
  3. Start the server.
  4. Open a browser, and go to the service web page. For example, assuming you ran the Wikipedia demo, go to http://localhost:8983/demos/wikipedia/.
    When prompted, provide the Cassandra username and password.
    Note: Security configuration on a DSE Search node is automatic and internal. Additional configuration is not required for Tomcat and Solr. Change your web.xml or server.xml files only for custom advanced setups.
HTTP Basic Authentication (testing and development only)
You can use HTTP Basic Authentication, but this is not recommended for production. To secure DSE Search in production, enable DataStax Enterprise Kerberos authentication or search using CQL instead.

When you enable Cassandra internal authentication by specifying authenticator: org.apache.cassandra.auth.PasswordAuthenticator in cassandra.yaml, clients must use HTTP Basic Authentication to provide credentials to Solr services. Due to the stateless nature of HTTP Basic Authentication, this can have a significant performance impact as the authentication process must be executed on each HTTP request. For this reason, DataStax does not recommend using internal authentication on DSE Search clusters in production.

The location of the cassandra.yaml file depends on the type of installation:
Package installations /etc/dse/cassandra/cassandra.yaml
Tarball installations install_location/resources/cassandra/conf/cassandra.yaml
The location of the dse.yaml file depends on the type of installation:
Installer-Services /etc/dse/dse.yaml
Package installations /etc/dse/dse.yaml
Installer-No Services install_location/resources/dse/conf/dse.yaml
Tarball installations install_location/resources/dse/conf/dse.yaml
Note: Security configuration on a DSE Search node is automatic and internal. Additional configuration is not required for Tomcat and Solr. Change your web.xml or server.xml files only for custom advanced setups.

To configure DSE Search to use Cassandra internal authentication:

  1. Comment AllowAllAuthenticator and uncomment the PasswordAuthenticator in cassandra.yaml to enable HTTP Basic authentication for Solr.
    #authenticator: org.apache.cassandra.auth.AllowAllAuthenticator
    authenticator: org.apache.cassandra.auth.PasswordAuthenticator
    #authenticator: com.datastax.bdp.cassandra.auth.PasswordAuthenticator
    #authenticator: com.datastax.bdp.cassandra.auth.KerberosAuthenticator
  2. Configure the replication strategy for the system_auth keyspace.
  3. Start the server.
  4. Open a browser, and go to the service web page. For example, assuming you ran the Wikipedia demo, go to http://localhost:8983/demos/wikipedia/.

    When prompted, provide the Cassandra username and password.