DSE Advanced Security FAQs

DataStax Enterprise security features frequently asked questions.

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

New security features in DSE 5.1

New security features include granular access control that allows permissions on table rows and search indexes; role assignment managed by LDAP groups; DSE proxy authentication for database clients; and JMX authentication integrated with DSE Unified Authentication (LDAP or internal).

General

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, for a list of ports used by DSE see Securing DataStax Enterprise ports.

Authentication and authorization

What are the restrictions to the default cassandra user?
The cassandra default account has access to all database resources. When logging in or performing an action, DSE sets the consistency level to QUORUM for this account. In a production environment, using the cassandra account may negatively affect performance and encounter failures. DataStax recommends Creating superuser accounts immediately after enabling DSE Unified Authentication with role based access control.
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 the initial setup of new users and superusers, and then disable it. The DSE Role Manager determines which roles to assign to authenticated users. See About roles.
How are user groups supported?
DSE supports role management based on LDAP group membership. Configure an LDAP scheme with group lookup, set the Role Management mode option to LDAP, and create roles that match the group names and then assign permissions. See Defining an LDAP scheme.
Note: For efficiency, DataStax recommends using the memberof search method for group lookup; however DataStax also supports directory search.
How are user-action permissions supported?
DSE supports standard object permission management to assign roles specific permissions at the table and row level. Permissions to access all keyspaces, a named keyspace, a table, function, or MBean can be granted to a role. See Managing roles
What authentication mechanisms are supported?
  • Internal: Connections provide credentials for a role that has an internally stored password, no additional configuration is required, see Managing roles.
  • LDAP: Connections provide LDAP credentials and DSE passes the credentials for verification to LDAP, see Defining an LDAP scheme.
  • 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, see Defining a Kerberos scheme
What LDAP servers are supported?
Microsoft Active Directory, OpenLDAP, and Oracle Directory Server Enterprise Edition, see Defining an LDAP scheme.
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?
Authorization is granted or revoked at the row level for data.
What is the difference between RBAC and RLAC
Role-based access control (RBAC) refers to authorization to any database resource including row-level access control (RLAC). Row-level access control refers to the feature that allows permissions to be granted/revoked on rows within a table by filtering a text-based partition column.

Row-level access control (RLAC)

Frequently asked questions about setting row-level permissions.
How do I restrict access to a row?
Each table can have a single UTF-8 partition key column on which you build filters to grant access (separate command) to rows within the table. RESTRICT only sets the filtering column name:
RESTRICT ROWS ON [keyspace_name.]table_name 
USING partition_key;
Note: After setting the column name, use the GRANT command to configure access to rows.
Can I unrestrict access to rows in a table with RLAC authorization?
The partition key to filter on using GRANT can be unselected from the table:
UNRESTRICT ROWS ON [keyspace_name.]table_name 
USING partition_key;
Tip: Use the LIST command on the table to display all roles that have been granted permissions.
Note: Unrestricting the column does not grant access to all columns within the table; it invalidates existing filters. Users that are granted access with a filter will be unable to access any rows within the table. To grant permissions to all rows, grant permission on the table to the role.
How do I grant permissions for rows in a table?

Configure access to rows within a table by specifying a filtering string that is applied to the partition key column selected in the RESTRICT command. Use case-sensitive literal text in the filter string. Row-level authorization applies only to rows that exactly match the filtering_data. You can create as many RLAC grant variations as required by your security policies. To allow access to rows within a table:

GRANT permission 
on 'filtering_data' ROWS IN keyspace_name.table_name 
to role_name;
Tip: Use the LIST command to display all permissions a role has on a resource.
How do I revoke permissions for rows in a table?
Row permissions are stored based on the filtering string, to remove a permission use the REVOKE command with the exact filtering string you want to remove:
REVOKE permission on 'filtering_data' ROWS IN keyspace_name.table_name;
Tip: LIST ALL PERMISSIONS ON TABLE table_name shows all filters granted to roles.
What happens if you run a RESTRICT command on a table that already has a restriction?
Tables have only a single restriction. Running the RESTRICT command replaces the existing restriction. Use DESCRIBE TABLE to view the existing restrictions on the table.
What happens if there a role has access to the keyspace/table level and I grant row access?
Permission is hierarchical, if permission was also granted to the keyspace or table the user has access to all rows in the table. The RLAC permissions have no affect.
Is RLAC supported for use with DSE Graph?
No. Although permissions are shown and errors are not thrown with this statement:
GRANT SELECT ON 'custom_key' ROWS IN graph_keyspace.graph_table to 'alice';
Permissions are not enforced. RLAC is not supported for use with DSE Graph.
Warning: Granting access on rows in a table provides access to data in all graph keyspaces.

Encryption

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 locally in the memory heap when used by DSE.
  • Use local encryption keys and secure using Linux permissions to restrict access.
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.
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.

Auditing

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 database 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