Security management

DataStax Enterprise includes advanced data protection for enterprise-grade databases including LDAP authentication support, internal authentication, object permissions, encryption, Kerberos authentication, and data auditing.

DataStax Enterprise includes advanced data protection for enterprise-grade databases:

The TCP-communications layer for Solr supports client-to-node and node-to-node encryption using SSL, but does not support Kerberos.

If you use the bring your own Hadoop (BYOH) model and use Kerberos to protect your data, configure external Hadoop security under Kerberos on your cluster. For information about configuring Hadoop security, see "Using Cloudera Manager to Configure Hadoop Security" or the Hortonworks documentation.

Some Datastax drivers provide Kerberos support and SSL for client/server communication. Get any driver from DataStax Academy downloads.


Assuming you configure security features, this table describes which data is secured (or not) based on the workload type: real-time Cassandra (DSE/Cassandra), analytics (Hadoop/Spark), and DSE/Search (Solr).

Feature DSE/Cassandra DSE Hadoop Solr Spark
Internal authentication Yes Yes [10] No Yes [9]
Object permission management Yes Partial [1] Partial [1] Partial [1]
Client to node encryption Yes [2] Yes [3] Yes [4] No
Kerberos authentication Yes [5] Yes Yes No
Transparent data encryption Yes [6] Yes Partial [7] No
Data auditing Yes Partial [8] Full Partial [8]

[1] Permissions to access objects stored in Cassandra are checked. The Solr cache and indexes and the DSE Hadoop cache are not under control of Cassandra, and therefore are not checked. You can, however, set up permission checks to occur on tables that store DSE Hadoop or Solr data.

[2] The inter-node gossip protocol is protected using SSL.

[3] The Thrift interface between DSE Hadoop and the Cassandra File System (CFS) is SSL-protected. Inter-tracker communication is Kerberos authenticated, but not SSL secured. Hadoop access to Cassandra is SSL- and Kerberos-protected.

[4] HTTP access to the DSE Search/Solr data is protected using SSL. Node-to-node encryption using SSL protects internal Solr communication.

[5] The inter-node gossip protocol is not authenticated using Kerberos. Node-to-node encryption using SSL can be used.

[6] Cassandra commit log data is not encrypted, only at rest data is encrypted.

[7] Data in DSE/Search Solr tables is encrypted by Cassandra. Encryption has a slight performance impact, but ensures the encryption of original documents after Cassandra permanently stores the documents on disk. However, Solr cache data and Solr index data (metadata) is not encrypted.

[8] DSE Hadoop and Spark data auditing is done at the Cassandra access level, so requests to access Cassandra data is audited. Node-to-node encryption using SSL protects communication over inter-node gossip protocol.

[9] Password authentication pertains to connecting Spark to Cassandra, not authenticating Spark components between each other, and authenticating changes to the Shark configuration.The Spark Web UI is not secured and might show the Spark configuration, including username, password, or delegation token when Kerberos is used.

[10] Password authentication pertains to connecting Hadoop to Cassandra, not authenticating Hadoop components between each other.

Using Kerberos and SSL at the same time 

Both the Kerberos and SSL libraries provide authentication, encryption, and integrity protection:

  • Kerberos - If you enable Kerberos authentication, integrity protection is also enabled. However, you can enable integrity protection without encryption.
  • SSL - If you use SSL, authentication, integrity protection, and encryption are all enabled or disabled.
  • Kerberos and SSL - It is possible to enable both Kerberos authentication and SSL together. However, this causes some overlap because authentication is performed twice by two different schemes: Kerberos authentication and certificates through SSL. DataStax recommends choosing one and using it for both encryption and authentication. These settings are described in the dse.yaml configuration file.

Securing DSE Search services 

The security table summarizes the security features of DSE Search/Solr and other integrated components. DSE Search data is completely or partially secured by using these DataStax Enterprise security features:

  • Managing object permissions using internal authorization

    Access to Solr documents, excluding cached data, can be limited to users who have been granted access permissions. 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. Encryption occurs on the Cassandra side and impacts performance slightly.

  • Client-to-node encryption

    You can encrypt HTTP access to Solr data and internal, node-to-node Solr communication using SSL. Enable SSL node-to-node encryption on the Solr node by setting encryption options in the dse.yaml file as described in Client-to-node encryption.

  • Kerberos authentication

    You can authenticate DSE Search users through Kerberos authentication using Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO).

You can also use HTTP Basic Authentication, but this is not recommended.

sstableloader security options 

The procedure for securing sstableloader has changed slightly from previous releases.