DataStax Enterprise 3.0 Documentation

Security management

This documentation corresponds to an earlier product version. Make sure this document corresponds to your version.

Latest DSE documentation | Earlier DSE documentation

DataStax Enterprise 3.0 and later includes a number of features for securing data. The security framework provides advanced data protection for enterprise-grade databases. You can secure a DataStax Community or DataStax Enterprise cluster using these features.

DataStax Enterprise offers additional security, not included in DataStax Community, to enterprises for mission-critical data:

  • Kerberos authentication: a network authentication protocol that allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner using tickets.
  • Transparent data encryption: the encoding of data flushed from the memtable in system memory to the SSTables on disk (at rest data) to be unreadable to unauthorized users. Encryption and decryption occurs without user intervention.
  • Data auditing: the administrator capability to create detailed audit trails of cluster activity.

DataStax Enterprise 3.0 uses the versions of CQL available in Cassandra 1.1.x and backports additional CQL security commands from later versions of Cassandra.

Limitations

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

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

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

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

[3] The Thrift interface between 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 column families 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] Hadoop and Solr 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.

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:

  • Object permission management

    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). To use the SolrJ API against DSE Search clusters with Kerberos authentication, client applications should use the SolrJ-Auth library and the DataStax Enterprise SolrJ component as described in the solrj-auth-README.md file.

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

Configuring HTTP Basic Authentication for Solr

When you enable Cassandra's internal authentication by specifying authenticator: com.datastax.bdp.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. To secure DSE Search in production, enable DataStax Enterprise Kerberos authentication.

To configure DSE Search to use Cassandra's internal authentication, follow this configuration procedure:

To configure password authentication for accessing DSE Search/Solr data:

  1. Uncomment the PasswordAuthenticator in cassandra.yaml to enable HTTP Basic authentication for Solr.

    #authentication backend, implementing IAuthenticator; used to identify users
    #authenticator: org.apache.cassandra.auth.AllowAllAuthenticator
    authenticator: com.datastax.bdp.cassandra.auth.PasswordAuthenticator
    #authenticator: com.datastax.bdp.cassandra.auth.KerberosAuthenticator
    
  2. Configure the replication strategy for the dse_auth keyspace.

  3. Start the server.

  4. Open a browser, and go to the service web page, for example http://localhost:8983/demos/wikipedia/.

    The browser asks you for a Cassandra username and password.