DSE Advanced Security FAQs

Frequently asked questions about DSE Advanced Security.

Questions and answers about DSE Advanced Security are provided in these categories:


What communication protocols are used?
All communication occurs over TCP sockets and can be secured by using the standard Java Security SSL/TLS implementation in the JVM. Additional application specific protocols like gossip and the CQL Binary Protocol rely on these sockets for transport.
How is DSE Graph secured?
DataStax Enterprise supports secure enterprise graph-database operations. Use Kerberos authentication for DSE Graph in production. DSE Graph authentication is accomplished with DSE Authentication because the underlying storage is Cassandra. CQL and cqlsh are used to grant permissions. See Securing DSE Graph.
How is Spark with DSE secured?
Securing Spark within DataStax Enterprise consists of two different security concepts:
How is DSE Search secured?
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. See Securing DSE Search

Authentication and authorization

What are the restrictions to the default cassandra user?
By default, each installation of Cassandra includes a superuser account named cassandra whose password is also cassandra. DataStax recommends Changing the default superuser for non-development environments.
  • Logins for the cassandra user are performed with QUORUM consistency.

    Do not use the default cassandra user in production, because QUORUM consistency has significant performance degradation for multiple datacenters.

  • Logins for all other users are performed with LOCAL_ONE consistency. See Configuring consistency levels.
How are user permissions managed?
Superuser permissions allow creation and deletion of other users and the ability to grant or revoke permissions. Use the default cassandra user only to assist with initial setup of new users and superusers, and then disable it. See Changing the default superuser and Configuring authentication with the DSE Unified Authenticator.
How are user groups supported?
Role-based access authenticates users based on the user association with LDAP groups or Cassandra roles. DSE supports assigning LDAP-based users to database groups. Any users mapped to the LDAP group can authenticate with the cluster. For efficiency, DataStax recommends that the target LDAP directory server have memberof support. The specific attribute that stores the role assignment in the LDAP is configurable by the DSE administrator. See Configuring LDAP authentication.
How are user-action permissions supported?
DSE supports standard object permission management to assign roles specific permissions at the table level. Permissions to access all keyspaces, a named keyspace, a table, function, or MBean can be granted to a role.

Use the familiar relational database GRANT/REVOKE paradigm to grant or revoke permissions to access Cassandra data. A superuser grants initial permissions, and subsequently a role may or may not be given the permission to grant/revoke permissions.

What authentication mechanisms are supported?
DSE Authenticator supports validating user identity against any of the following authentication schemes:
  • Internal: Connections provide credentials for a role that has an internally stored password, no additional configuration is required, see Role-based access.
  • LDAP: Connections provide LDAP credentials and DSE passes the credentials for verification to LDAP, see About authentication with LDAP.
  • Kerberos: Connections provide a Kerberos ticket, DSE is configured as a Service Principal (see Setting up Kerberos) and passes the tickets to KDS for verification.
What LDAP servers are supported?
Microsoft Active Directory, OpenLDAP, and Oracle Directory Server Enterprise Edition.
Can access be restricted using IP whitelisting and blacklisting?
In general, arbitrary client programs do not access the database. Database access by the general user population is controlled at the application layer. Application node to database node access should be controlled by using conventional firewall mechanisms, such as Linux iptables. However, database administrators are an exception to allow connections from DBA hosts.
What granularity of access to specific elements of data is supported?
None. DSE security checks occur at the table level. Perform more granular security checks in the application layer.


How are encryption keys secured and managed?
Encryption keys can be managed off-server or locally:
  • KMIP (Key Management Interoperability Protocol) encryption for encryption keys stored on another server and are cached by Cassandra locally in the memory heap when in use by the DSE process.
  • Use local encryption keys and secure using Linux permissions to restrict access.
What data is encrypted?

DataStax Enterprise supports encryption for in-flight data (node-to-node and client-to-node) and at-rest data.

Can the client-to-node encryption be configured as a two-way SSL?
Yes, although the client certificate DN is not used as a database user principal. Client-to-node encryption protects in-flight data from client machines to a database cluster using SSL (Secure Sockets Layer) and establishes a secure channel between the client and the coordinator node.
How is encryption of at-rest data supported?
Protects sensitive at-rest data using a local encryption key file or remotely stored and managed KMIP encryption key.
When Java Cryptography Extension (JCE) is installed, the cipher_algorithm options and acceptable secret_key_strength values for the algorithms are:
cipher_algorithm secret_key_strength
AES/CBC/PKCS5Padding 128, 192, or 256
AES/ECB/PKCS5Padding 128, 192, or 256
DES/CBC/PKCS5Padding 56
DESede/CBC/PKCS5Padding 112 or 168
Blowfish/CBC/PKCS5Padding 32-448
RC2/CBC/PKCS5Padding 40-128
Can encryption keys be changed for a particular table?
Yes, by designating transparent data encryption (TDE) on a per table basis. Using encryption, your application can read and write to SSTables that use different encryption algorithms or use no encryption at all. Use a single ALTER TABLE statement to set encryption and compression.
Would encryption of EBS in AWS be a good replacement for using TDE, or is EBS better as a supplement to TDE (or neither)?
EBS encryption is another way to encrypt the data files. EBS encryption ensures encryption of audit logs, system logs, and the SSTable index files, which have partition keys in plain text if using TDE. In general, EBS encryption may be operationally simpler. Primarily, use TDE when full disk encryption is cost prohibitive or not feasible.
Is encryption supported at granular data layers? For example record-level or column- or field-level?
No. Designate transparent data encryption (TDE) only on a per table basis.


Which user actions and events are logged?
When you configure audit logging, you can specify which categories of audit events (administration, authentication, DML, DDL, DCL, and query operations) to log, and whether to omit operations against specific keyspaces from audit logging.
Where are audit logs stored and who has access?
Audit logs can be written to either file system log files using logback, or to a Cassandra table. Audit events stored in database tables can be secured like any other database table using RBAC. File-based audit logs are stored per-node and can be secured with standard Linux file system permissions. See