Securing client to cluster connections

Client-to-node encryption protects data in flight from client machines to a database cluster using SSL and establishes a secure channel between the client and the coordinator node.

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. Unlike Kerberos, does not require setting up a shared authentication service.

Note: If you are using DSE Search, enabling SSL automatically enables in the DSE Search web.xml file and configures an SSL connector in Tomcat using the authentication/authorization filters. You do not have to change your web.xml or server.xml files.

If the TomcatSolrRunner doesn't find a connector in server.xml it creates a default connector. The default connector binds to the native_transport_address in cassandra.yaml.

cassandra.yaml

The location of the cassandra.yaml file depends on the type of installation:
Package installations /etc/dse/cassandra/cassandra.yaml
Tarball installations installation_location/resources/cassandra/conf/cassandra.yaml

server.xml

The default location of the Tomcat server.xml file depends on the installation type:
Package installations /etc/dse/tomcat/conf/server.xml
Tarball installations installation_location/resources/tomcat/conf/server.xml

dse.yaml

The location of the dse.yaml file depends on the type of installation:
Package installations /etc/dse/dse.yaml
Tarball installations installation_location/resources/dse/conf/dse.yaml

Prerequisites

Procedure

To enable encryption, perform these steps on each node:

Note: DSE Search and Spark nodes require the truststore entries in cassandra.yaml.

  1. Production clusters: In the cassandra.yaml file, in the client_encryption_options section:
    • Set enabled to true.
    • Set the paths to your .keystore and .truststore files.
    • Provide the passwords that were used when generating the keystore and truststore.
    • To enable client certificate authentication, set require_client_auth to true.
    • Use an SSL production certificate.
    client_encryption_options:
        enabled: true
        keystore: resources/dse/conf/.keystore  ## Path to your .keystore file
        keystore_password: keystore_password  ## Password that you used to generate the keystore
        require_client_auth: true
        # Set truststore and truststore_password when require_client_auth: true
        truststore: resources/dse/conf/.truststore  ## Path to your .truststore
        truststore_password: truststore_password  ## Password that you used to generate the truststore
        protocol: ssl
        algorithm: SunX509
        store_type: JKS
        cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA]
    For information about using Kerberos with SSL, see Using CQL shell (cqlsh) with SSL. To encrypt the truststore and keystore passwords with KMIP, see Encrypting table data.
  2. Development clusters: In the cassandra.yaml file, in the client_encryption_options section:
    • Set enabled to true.
    • Provide the passwords that were used when generating the keystore and truststore.
    • Set the paths to your .keystore and .truststore files.
    • If two-way certificate authentication is desired, set require_client_auth to true. Enabling two-way certificate authentication allows tools to connect to a remote node.
    • Complete Setting up SSL certificates.

    For local access to run cqlsh on a local node with SSL encryption, require_client_auth can be set to false.

    client_encryption_options:
        enabled: true
        # If enabled and optional is set to true encrypted and unencrypted connections are handled.
        optional: false
        keystore: conf/keystore.node0 
        keystore_password: cassandra
        
        require_client_auth: true
        # Set trustore and truststore_password if require_client_auth is true
        truststore: conf/truststore.node0
        truststore_password: cassandra
        protocol: TLS
        algorithm: SunX509
        store_type: JKS
        cipher_suites: [TLS_RSA_WITH_AES_256_CBC_SHA]
  3. If the client_encryption_options are set in dse.yaml file, remove them.
  4. If you are not using the JCE Unlimited Strength Jurisdiction Policy, make sure that your ticket granting principal does not use AES-256.
    If your ticket granting principal uses AES-256, you might see a warning like this in the logs:
    WARN [StreamConnectionEstablisher:18] 2015-06-22 14:12:18,589 SSLFactory.java (line 162) Filtering out 
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as it isnt supported by the socket
  5. Restart DataStax Enterprise.