DSE Search security checklist
DataStax Enterprise supports secure enterprise search. All of the DataStax Enterprise security checklists in this section summarize the security features of DSE Search as well as other integrated components.
-
Authentication
DataStax recommends using Kerberos authentication with the Solr Admin UI and when running commands with cURL using the SolrJ API.
-
To authenticate DSE Search clients with Kerberos authentication, use Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO).
-
To use the SolrJ API against DSE Search clusters with Kerberos authentication, client applications must use the SolrJ-Auth library and the DataStax Enterprise SolrJ component as described in the solrj-auth-README.md file.
-
Perform index management tasks with the CQL shell using Enabling DSE Unified Authentication.
-
-
Authorization
Use role-based access control (RBAC) for authenticated users to provide search index related permissions, see Setting up logins and users and Controlling access to search indexes. Setting row-level permissions with row-level access control (RLAC) is not supported for use with DSE Search or DSE Graph.
-
Audit activity
Log and monitor activity for database resources, see Setting up database auditing.
-
Transparent Data Encryption (TDE)
Protect data at-rest. DSE provides KMIP or local encryption for sensitive data in search indexes, see Encrypting Search indexes.
-
Encrypt data in-flight using SSL
Encrypt connections using SSL between HTTP clients and CQL shell to with client-to-node encryption on the DSE Search node. See Configuring SSL [Configuring SSL].
To satisfy specific security requirements with SSL, you can change the IP address for client connections to DSE Search. You can do this, for example, to isolate a subnet.
The default location of the Tomcat
server.xmlfile depends on the installation type:Package installations
/etc/dse/tomcat/conf/server.xmlTarball installations
<installation_location>/resources/tomcat/conf/server.xmlSecurity configuration on a DSE Search node is managed by the DataStax Enterprise configuration. Additional configuration is not required for Tomcat and Solr. Change your
web.xmlorserver.xmlfiles only for custom, advanced setups.Restriction: DSE Search security features have the following limitations:
-
TDE: Cached data is not encrypted. Encryption occurs only in the DSE database and impacts performance slightly. -
Authorization: Permissions apply only to
CQLrequests, such as search index management and access to data stored in the database. Permissions do not apply to search file resources such as the cache and index configuration. -
Setting row-level permissions with row-level access control (RLAC) is not supported for use with DSE Search.
-
HTTP access to the DSE Search data is protected using SSL (client-to-node encryption). Node-to-node encryption using SSL protects internal Solr communication.
About HTTP Basic Authentication and DSE Search clusters
|
Only use HTTP Basic Authentication with DSE Search clusters in your testing and development environments. Do not use internal authentication on DSE Search clusters in production. |
You can use HTTP Basic Authentication with DSE Search clusters, however it’s not recommended for production.
To secure DSE Search in production, enable DataStax Enterprise Kerberos authentication, or search using CQL.
If instead 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 option can have a significant performance impact because 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.
