Skip to content

Apache Cassandra

Export Configuration#

Exporting Cassandra through a Tranquil Data peer extends the configuration object with the following fields:

Field Name Type Required Default
clusterPort integer 9042
cluster array of hosts an array containing defaultServiceHost
user string
password string
certificate string containing a PEM-encoded PKC

The value of type must be cassandra.

The value of clusterPort and cluster identify (respectively) the port and the set of hosts where the backing service is available.

The value of user and password make up the credentials used to connect to the backing service.

Security Support#

If user is unspecified, Tranquil Data will assume no authentication is required when connecting to the Cassandra cluster. If certificate is unspecified then connections will not be secured with TLS.

Context Interaction#

The CQL v3+ binary protocol is supported. Tranquil Data supports all Cassandra query execution modes. However, it will only form context and check policies for single CQL command operations, including prepared statements. Batched statements are handed off directly to the backing Cassandra without any inspection. Only the following commands will interact with the context model:

  • CREATE TABLE
  • USE
  • INSERT
  • SELECT

All other CQL commands (e.g., ALTER TABLE), or unsupported flavors of the recognized commands (e.g., INSERT with a JSON value) are similarly handed off to Cassandra outside of the context model. More specifically, the following INSERT command flavor is recognized:

INSERT INTO table_name
  ( column_name [, ...] ) VALUES '(' value1 [, ...] ')' 
  [ IF NOT EXISTS ] [ USING update_param [ AND update_param *]]

Tranquil Data recognizes certain flavors of SELECT commands for context model and policy checks:

  1. Commands that contain in their payload all columns constituting the table primary key
  2. Commands that do not include name aliases for table or column names (i.e., do not use the AS keyword)

All other flavors of the SELECT command are directly handed off to the Cassandra cluster without any inspection.

Sessions are mapped to a single command execution within a client connection. The session ends when a response is sent to the client. Since the CQL protocol is asynchronous, several sessions can be active simultaneously within a given connection. When a client closes its connection, all still-active sessions end.