Skip to content

Setting up client encryption in Cassandra

Jump to bottom
jeanpaulazara edited this page Feb 3, 2017 · 22 revisions

Cassandra allows you to secure the client transport (CQL) as well as the cluster transport (storage transport).

SSL/TLS have some overhead. This is especially true in the JVM world which is not as performant for handling SSL/TLS unless you are using Netty/OpenSSl integration.

If possible, use no encryption for the cluster transport (storage transport), and deploy your Cassandra nodes in a private subnet, and limit access to this subnet to the client transport. Also if possible avoid using TLS/SSL on the client transport and do client operations from your app tier, which is located in a non-public subnet.

However, that is not always possible. You may work in an industry that requires the use of encrypted transports like the U.S. Health Insurance Portability and Accountability Act (HIPAA), Germany’s Federal Data Protection Act, The Payment Card Industry Data Security Standard (PCI DSS), or U.S. Sarbanes-Oxley Act of 2002. Or you might work for a bank or other financial institution. Or it just might be a corporate policy to encrypt such transports.

Another area of concern is for compliance is authorization, and encrypted data at rest. Cassandra’s has essential security features: authentication, role-based authorization, transport encryption (JMX, client transport, cluster transport), as well as data at rest encryption (encrypting SSTables).

This article will focus just on setting up encryption for the Cassandra client transport (CQL) and the cluster transport. Later articles will cover various aspects of compliance and encryption.

Encrypting the transports

Data that travels over the client transport across a network could be accessed by someone you don't want accessing said data with tools like wire shark. If data includes private information, SSN number, credentials (password, username), credit card numbers or account numbers, then we want to make that data unintelligible (encrypted) to any and all 3rd parties. This is especially important if we don't control the network. You can also use TLS to make sure the data has not been tampered with whilst traveling the network. The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols are designed to provide these features (SSL is the old name for what became TLS but many people still refer to TLS as SSL).

Cassandra is written in Java. Java defines the JSSE framework which in turn uses the Java Cryptography Architecture (JCA). JSSE uses cryptographic service providers from JCA.

If any of the above is new to you, please take a few minutes to read through the [TLS/SSL Java guide] (http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html).

Setting up client config

The client transport encryption protects data as it moves from clients to server nodes in the cluster.

The client_encryption_options are stored in the cassandra.yaml. Here is an example config.

Sample config


# enable or disable client/server encryption.
client_encryption_options:
    enabled: false
    # If enabled and optional is set to true encrypted and unencrypted connections are handled.
    optional: false
    keystore: conf/.keystore
    keystore_password: cassandra
    require_client_auth: false
    # Set trustore and truststore_password if require_client_auth is true
    # truststore: conf/.truststore
    # truststore_password: cassandra
    protocol: TLS
    algorithm: SunX509
    store_type: JKS
    cipher_suites: [TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_anon_WITH_AES_256_CBC_SHA]

Setup keys

Before we go into the details of setting up the cassandra.yaml file, let's create some trust stores, key stores, and export some keys. The following script generates cluster and client keys.

setupkeys-cassandra-security.sh

#!/bin/bash

KEY_STORE_PATH="$PWD/resources/opt/cassandra/conf/certs"
mkdir -p "$KEY_STORE_PATH"
KEY_STORE="$KEY_STORE_PATH/cassandra.keystore"
PKS_KEY_STORE="$KEY_STORE_PATH/cassandra.pks12.keystore"
TRUST_STORE="$KEY_STORE_PATH/cassandra.truststore"
PASSWORD=cassandra
CLUSTER_NAME=test
CLUSTER_PUBLIC_CERT="$KEY_STORE_PATH/CLUSTER_${CLUSTER_NAME}_PUBLIC.cer"
CLIENT_PUBLIC_CERT="$KEY_STORE_PATH/CLIENT_${CLUSTER_NAME}_PUBLIC.cer"

### Cluster key setup.
# Create the cluster key for cluster communication.
keytool -genkey -keyalg RSA -alias "${CLUSTER_NAME}_CLUSTER" -keystore "$KEY_STORE" -storepass "$PASSWORD" -keypass "$PASSWORD" \
-dname "CN=CloudDurable Image $CLUSTER_NAME cluster, OU=Cloudurable, O=Cloudurable, L=San Francisco, ST=CA, C=USA, DC=cloudurable, DC=com" \
-validity 36500

# Create the public key for the cluster which is used to identify nodes.
keytool -export -alias "${CLUSTER_NAME}_CLUSTER" -file "$CLUSTER_PUBLIC_CERT" -keystore "$KEY_STORE" \
-storepass "$PASSWORD" -keypass "$PASSWORD" -noprompt

# Import the identity of the cluster public cluster key into the trust store so that nodes can identify each other.
keytool -import -v -trustcacerts -alias "${CLUSTER_NAME}_CLUSTER" -file "$CLUSTER_PUBLIC_CERT" -keystore "$TRUST_STORE" \
-storepass "$PASSWORD" -keypass "$PASSWORD" -noprompt


### Client key setup.
# Create the client key for CQL.
keytool -genkey -keyalg RSA -alias "${CLUSTER_NAME}_CLIENT" -keystore "$KEY_STORE" -storepass "$PASSWORD" -keypass "$PASSWORD" \
-dname "CN=CloudDurable Image $CLUSTER_NAME client, OU=Cloudurable, O=Cloudurable, L=San Francisco, ST=CA, C=USA, DC=cloudurable, DC=com" \
-validity 36500

# Create the public key for the client to identify itself.
keytool -export -alias "${CLUSTER_NAME}_CLIENT" -file "$CLIENT_PUBLIC_CERT" -keystore "$KEY_STORE" \
-storepass "$PASSWORD" -keypass "$PASSWORD" -noprompt

# Import the identity of the client pub  key into the trust store so nodes can identify this client.
keytool -importcert -v -trustcacerts -alias "${CLUSTER_NAME}_CLIENT" -file "$CLIENT_PUBLIC_CERT" -keystore "$TRUST_STORE" \
-storepass "$PASSWORD" -keypass "$PASSWORD" -noprompt



keytool -importkeystore -srckeystore "$KEY_STORE" -destkeystore "$PKS_KEY_STORE" -deststoretype PKCS12 \
-srcstorepass "$PASSWORD" -deststorepass "$PASSWORD"

openssl pkcs12 -in "$PKS_KEY_STORE" -nokeys -out "${CLUSTER_NAME}_CLIENT.cer.pem" -passin pass:cassandra
openssl pkcs12 -in "$PKS_KEY_STORE" -nodes -nocerts -out "${CLUSTER_NAME}_CLIENT.key.pem" -passin pass:cassandra

The keytool utility ships with Java SDK. We use this keytool command to create the cluster key. Let's break down the script that generates the keys and certificates.

Create the cluster key

keytool -genkey -keyalg RSA -alias "${CLUSTER_NAME}_CLUSTER" -keystore "$KEY_STORE" -storepass "$PASSWORD" -keypass "$PASSWORD" \
-dname "CN=CloudDurable Image $CLUSTER_NAME cluster, OU=Cloudurable, O=Cloudurable, L=San Francisco, ST=CA, C=USA, DC=cloudurable, DC=com" \
-validity 36500

Once we create the cluster key, we will want to export a public key from it.

Export a public key for the cluster key.

# Create the public key for the client to identify itself.
keytool -export -alias "${CLUSTER_NAME}_CLIENT" -file "$CLIENT_PUBLIC_CERT" -keystore "$KEY_STORE" \
-storepass "$PASSWORD" -keypass "$PASSWORD" -noprompt

Then we will import the public key into the trust store so that nodes can identify each other.

Import public key for the cluster key into the trust store so nodes can identify each other

# Import the identity of the cluster public cluster key into the trust store so that nodes can identify each other.
keytool -import -v -trustcacerts -alias "${CLUSTER_NAME}_CLUSTER" -file "$CLUSTER_PUBLIC_CERT" -keystore "$TRUST_STORE" \
-storepass "$PASSWORD" -keypass "$PASSWORD" -noprompt

We perform the same three tasks for the client keys. Then lastly we create pem files for the client keys by exporting our Java JKS keystore as a PKCS12 trust store.

Creating client pem files

keytool -importkeystore -srcalias "${CLUSTER_NAME}_CLIENT" -srckeystore "$KEY_STORE" -destkeystore "$PKS_KEY_STORE" -deststoretype PKCS12 \
-srcstorepass "$PASSWORD" -deststorepass "$PASSWORD"

openssl pkcs12 -in "$PKS_KEY_STORE" -nokeys -out "$KEY_STORE_PATH/${CLUSTER_NAME}_CLIENT.cer.pem" -passin pass:cassandra
openssl pkcs12 -in "$PKS_KEY_STORE" -nodes -nocerts -out "$KEY_STORE_PATH/${CLUSTER_NAME}_CLIENT.key.pem" -passin pass:cassandra

Here are the files that get generated.

Cert files, stores, private keys

$ pwd
~/github/cassandra-image

$ ls resources/opt/cassandra/conf/certs/
CLIENT_test_PUBLIC.cer		cassandra.pks12.keystore	test_CLIENT.key.pem
CLUSTER_test_PUBLIC.cer		cassandra.truststore
cassandra.keystore		test_CLIENT.cer.pem
  • CLIENT_test_PUBLIC.cer public client key for the test cluster.
  • cassandra.pks12.keystore PKS12 keystore for client used to generate pem
  • test_CLIENT.key.pem private client key in pem format used by csqlsh
  • CLUSTER_test_PUBLIC.cer public cluster key for the test cluster
  • cassandra.truststore Trust store used by cassandra
  • cassandra.keystore Key store used by cassandra
  • test_CLIENT.cer.pem public client key in pem format used by csqlsh

For the cassandra_image project, these files are copied to /opt/cassandra/conf/cert. To learn more about our Vagrant project see Setting up a Cassandra cluster with cassandra image and cassandra cloud project with Vagrant.

Use the keys that we setup.

As part of the provision script for cassandra_image(see Setting up a Cassandra cluster with cassandra image and cassandra cloud project with Vagrant). We added the following:

cassandra-image/scripts/040-install-certs.sh

#!/bin/bash

set -e

DESTINATION_DIRECTORY=/opt/cassandra/conf/certs
SOURCE_DIRECTORY="~/resources$DESTINATION_DIRECTORY"

if [ -d "$SOURCE_DIRECTORY" ]; then
    mkdir -p "$DESTINATION_DIRECTORY"

    cp -r "$SOURCE_DIRECTORY" "$DESTINATION_DIRECTORY"
fi


if [ ! -d "$SOURCE_DIRECTORY" ]; then
    echo "UNABLE TO INSTALL CERTS AS THEY WERE NOT FOUND"
fi

This will copy the certs to the right location if you generated a folder in resources (cassandra_image/resources/opt/cassandra/conf/cert), which the last script that we covered does.

Configure Cassandra to use the keys.

/opt/cassandra/conf


server_encryption_options:
    internode_encryption: all
    keystore: /opt/cassandra/conf/certs/cassandra.keystore
    keystore_password: cassandra
    truststore: /opt/cassandra/conf/certs/cassandra.truststore
    truststore_password: cassandra
    # More advanced defaults below:
    protocol: TLS

client_encryption_options:
    enabled: true
    # If enabled and optional is set to true encrypted and unencrypted connections are handled.
    optional: false
    keystore: /opt/cassandra/conf/certs/cassandra.keystore
    keystore_password: cassandra
    truststore: /opt/cassandra/conf/certs/cassandra.truststore
    truststore_password: cassandra
    require_client_auth: true
    protocol: TLS

Now let's test it.

Testing that our Cassandra nodes can talk to each other

$ vagrant up
# Get a coffee and otherwise relax for a minute.
# Now log into one of the nodes.
$ vagrant ssh node0

# Now check to see if the cluster is formed. 
[vagrant@localhost ~]$ /opt/cassandra/bin/nodetool describecluster
Cluster Information:
	Name: test
	Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
	Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
	Schema versions:
		86afa796-d883-3932-aa73-6b017cef0d19: [192.168.50.4, 192.168.50.5, 192.168.50.6]

We can see that the servers in the cluster can connect to each other (see Setting up a Cassandra cluster with cassandra image and cassandra cloud project with Vagrant).

Setup csql client

We are doing this in OSX. In this example, we have the virtual machines running CentOS 7 with Vagrant on VirtualBox. We can connect to those instances with Cassandra cqlsh.

Let's copy cert files so we can access them from the client (MacBook pro / OSX).

Copy cert files created earlier.

$ cd ~/github/cassandra-image/resources/opt/cassandra/conf/certs
$ mkdir /opt/cassandra/conf/certs
$ cp * /opt/cassandra/conf/certs

Now we will create a cqlshrc which is a file that dictates how we connect to Cassandra.

Create the cqlshrc in ~/.cassandra

$ mkdir ~/.cassandra
$ cd ~/.cassandra
$ touch cqlshrc
# edit this file

~/.cassandra/cqlshrc contents


[connection]
hostname = 192.168.50.4
port = 9042
factory = cqlshlib.ssl.ssl_transport_factory


[ssl]
certfile =  /opt/cassandra/conf/certs/test_CLIENT.cer.pem
validate = false
# Next 2 lines must be provided when require_client_auth = true in the cassandra.yaml file
userkey = /opt/cassandra/conf/certs/test_CLIENT.key.pem
usercert = /opt/cassandra/conf/certs/test_CLIENT.cer.pem

Note we specify the nodes and we are using the pem file as our credentials via SSL to prove who we are instead of a username/password. (We could use both.) We need the userkey and usercert in the cqlshrc because we set require_client_auth = true in the cassandra.yaml file for the cluster nodes.

Now let's test that the client connection works with SSL via cqlsh.

Testing client connection using cqlsh

$ /opt/cassandra/bin/cqlsh --ssl 
Connected to test at 192.168.50.4:9042.
[cqlsh 5.0.1 | Cassandra 3.9 | CQL spec 3.4.2 | Native protocol v4]
Use HELP for help.

Notice we can connect to Cassandra using SSL. Notice that we are connected to the test cluster, which is the cluster we setup in Setting up a Cassandra cluster with cassandra image and cassandra cloud project with Vagrant.

Review

We setup keys for client and clustering. We deployed keys to three Linux boxes using Vagrant provisioning. We then setup cqlsh to use SSL. We then logged into one of the nodes and checked that the network was setup with the nodetool describecluster. Then we locally setup csqlsh to connect to the cluster using SSL.

More to come.

Check back with us at the Cloudurable blog to find out more about cassandra-image and cassandra-cloud.

About Cloudurable

Cloudurable provides AMIs, cloudformation templates and monitoring tools to support Cassandra in production running in EC2. We also teach advanced Cassandra courses which teaches how one could develop, support and deploy Cassandra to production in AWS EC2.

References

Cloudurable provides AMIs, cloudformation templates and monitoring tools to support Cassandra in production running in EC2. We also teach advanced Cassandra courses which teaches how one could develop, support and deploy Cassandra to production in AWS EC2.

Kafka training, Kafka consulting, Cassandra training, Cassandra consulting, Spark training, Spark consulting.

Cloudurable provides AMIs, cloudformation templates and monitoring tools to support Cassandra in production running in EC2. We also teach advanced Cassandra courses which teaches how one could develop, support and deploy Cassandra to production in AWS EC2. Kafka training, Kafka consulting, Cassandra training, Cassandra consulting, Spark training, Spark consulting

Clone this wiki locally