About security management

An overview of DataStax Enterprise security.

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.

Data security by workload type

Assuming you configure security features, this table describes which data is secured based on the workload type: transactional DSE Cassandra, DSE Analytics (Hadoop/Spark), and DSE Search.

Feature DataStax Enterprise security DSE Hadoop DSE Search with Solr DSE Analytics with Spark DSE Graph
Internal authentication/LDAP Yes Yes [1] Partial [9] Yes [2] Partial [9]
Object permission management Yes Partial [3] Partial [3] Partial [3] Yes [12]
Client-to-node encryption Yes [4] Yes [5] Yes [6] Yes [7] Yes [4]
Kerberos authentication Yes [8] Yes Yes Yes [2] Yes [8]
Transparent data encryption Yes Yes Yes No Yes
Data auditing Yes Partial [10] Full Partial [10] Yes [11]

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

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

[3] 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.

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

[5] 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.

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

[7] SSL client-to-node encryption is for Spark Executor to Cassandra connections only.

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

[9] Search using CQL is supported for Internal authentication/LDAP, but is not supported over HTTP.

[10] 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.

[11] Limited, as Gremlin queries are not distinguished between query types like Cassandra.

[12] Permissions are enforced on a per vertex label and registered through CQL at the table level, using individual permissions using CQL.

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 - When using SSL, authentication, integrity protection, and encryption are all enabled or disabled.
  • Kerberos and SSL - You can 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.