Scylla Encryption Guide

Scylla 1.1 supports secure SSL/TLS communication for both server-to-server and client connection, more or less identical to Apache Cassandra. In general, the only difference is that Scylla, like most native applications, uses PEM encoded certificates and keys, instead of Java keystore managed ones.

Node-to-node SSL

Communication between all or some nodes can be encrypted. The controlling setting is server_encryption_options.

SSL configuration appears in the Scylla configuration file /etc/scylla/scylla.yaml.

server_encryption_options:
    internode_encryption: <none|rack|dc|all>
    certificate: <path to PEM encoded certificate file>
    keyfile: <path to PEM encoded key for certificate>
    truststore: <optional path to PEM encoded trust store>
  • Internode_encryption - The available options are:
    • none (default)
    • all
    • dc: encrypts the traffic between the data centers.
    • rack: encrypts the traffic between the racks.
  • certificate - A PEM format certificate, either self-signed, or provided by a certificate authority (CA).
  • keyfile - The corresponding PEM format key for the certificate
  • truststore - Optional path to a PEM format certificate store of trusted CA:s. If not provided, Scylla will attempt to use the system trust store to authenticate certificates.

CQL client SSL

Communication between connecting clients and node(s) can be secured using SSL. The controlling setting is client_encryption_options.

Syntax:

client_encryption_options:
    enabled: <true|false>
    certificate: <path to PEM encoded certificate file>
    keyfile: <path to PEM encoded key for certificate>
  • enabled - default is false. When set to true, all incoming CQL connections require TLS/SSL connectivity.
  • certificate - A PEM format certificate, either self-signed, or provided by a CA authority.
  • keyfile - The corresponding PEM format key for the certificate

Generating a self-signed certificate chain using openssl

For local communication, self-signed certificates and a private trust store are usually sufficient for securing communication. Indeed, several nodes can share the same certificate, as long as we ensure that our trust configuration is not tampered with.

To build a self-signed certificate chain, begin by creating a certificate configuration file like this:

RANDFILE = NV::HOME/.rnd
[ req ]
default_bits = 4096
default_keyfile = <hostname>.key
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[ req_distinguished_name ]
C = <country code>
ST = <state>
L = <locality/city>
O = <domain>
OU = <organization, usually domain>
CN= <hostname>.<domain>
emailAddress = <email>
[v3_ca]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true
[v3_req]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

Substitute the values in <> with whichever suits your organization. For this example, let’s call our host db, and our domain foo.bar, and create a file called db.cfg:

RANDFILE = NV::HOME/.rnd
[ req ]
default_bits = 4096
default_keyfile = db.key
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[ req_distinguished_name ]
C = SE
ST = Stockholm
L = Stockholm
O = foo.bar
OU = foo.bar
CN= db.foo.bar
emailAddress = postmaster@foo.bar
[v3_ca]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true
[v3_req]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

Then, begin by generating a self-signing certificate authority key:

openssl genrsa -out cadb.key 4096

And using this, a certificate signing authority:

openssl req -x509 -new -nodes -key cadb.key -days 3650 -config db.cfg -out cadb.pem

Now, generate a private key for our certificate:

openssl genrsa -out db.key 4096

And from this, a signing request:

openssl req -new -key db.key -out db.csr -config db.cfg

Then we can finally create and sign our certificate:

openssl x509 -req -in db.csr -CA cadb.pem -CAkey cadb.key -CAcreateserial  -out db.crt -days 365

As a result, we should now have:

  • db.crt - PEM format certificate
  • db.key - PEM format key for the above certificate
  • cadb.pem - PEM format signing identity that can be used as a trust store.

Place the files in a directory of your choice and make sure you set permissions so your Scylla instance can read them. Then update the server/client configuration to reference them.

When restarting Scylla with the new configuration, you should see the following messages in the log:

When node-to-node encryption is active:

Starting Encrypted Messaging Service on SSL port 7001

When client to node encryption is active:

Enabling encrypted CQL connections between client and server