Configuring TLS for Cassandra

How to configure TLS for Cassandra in the runtime plane

Cassandra provides secure communication between a client machine and a database cluster and between nodes within a cluster. Enabling encryption ensures that data in flight is not compromised and is transferred securely. In Apigee hybrid, TLS is enabled by default for any communication between Cassandra nodes and between clients and Cassandra nodes.

For hybrid Beta, TLS Between Cassandra nodes and clients to Cassandra is enabled by default. As part of TLS setup you must provide the server key, certificate, and root certificate.

Unsupported TLS features

  • Certificate Authority (CA) rotation is not supported.
  • A server certificate which is generated with passphrase is not supported.

Configure TLS for Cassandra

To configure TLS for your Cassandra database, do the following:
  1. Open the overrides.yaml file.
  2. Add the following configuration to provide to path to your server cert, key, and rootCA.
    cassandra:
      sslRootCAPath: path_to_your_cert_file/cert.pem
      sslCertPath: path_to_your_key_file/keystore.pem
      sslKeyPath: path_to_your_keystore_file/keystore.pem

Configure Cassandra authentication

The hybrid platform uses Cassandra as the backend datastore for runtime plane data. By default, any of the client communications to Cassandra requires authentication. There are three users used by clients that communicate with Cassandra. You are required to provide usernames and passwords for these users as part of the authentication setup described in this section. These users, including a default user, are described below:

  • DML User: Used by the client communication to read and write data to Cassandra (KMS, KVM, Cahce and Quota).
  • DDL User: Used by MART for any of the data definition tasks like keyspace creation, update, and deletion.
  • Admin User: Used for any administrative activities performed on cassandra cluster.
  • Default Cassandra user: Cassandra creates a default user when Authentication is enabled and the username is cassandra

In the overrides.yaml file, add the following configuration and apply the change.

All the usernames must be in lowercase.

cassandra:
   auth:
     default:  ## this is the new default user(cassandra) password
       password: changeme
     admin: ## this is the admin user
       user: admin
       password: adminpassword
     ddl: ## this is the ddl user for ddl operations
       user: ddl
       password: ddlpassword
     dml:
       user: dml ## this is the dml user for dml ops
       password: dmlpassword

Switch to multiple Kubernetes clusters

Follow the steps in this section if you are using multi-region clusters, as discussed in Multi-region deployment.

  1. Get the available kubernetes contexts:
    kubectl config get-contexts
    
    CURRENT   NAME                                         CLUSTER                                      AUTHINFO                                     NAMESPACE
              gke_my_username_us-central1_jai-perf-test    gke_my_username_us-central1_jai-perf-test    gke_my_username_us-central1_jai-perf-test
              gke_my_username_us-central1_cluster01        gke_my_username_us-central1_cluster01        gke_my_username_us-central1_cluster01
    *         gke_my_username_us-central1_k8s-us-central1  gke_my_username_us-central1_k8s-us-central1  gke_my_username_us-central1_k8s-us-central1
  2. Switch the Kubernetes context:
    kubectl config use-context context name
    

Describe the pods to check if creation was successful

Use this command to check if the Cassandra pods launched successfully:

kubectl describe pods apigee-cassandra-2 -n apigee

 Normal   Created                 31s                kubelet, gke-k8s-us-west1-default-pool-e9daaab3-tjmz  Created container
 Normal   Started                 31s                kubelet, gke-k8s-us-west1-default-pool-e9daaab3-tjmz  Started container

Check the Cassandra logs

Check the logs as soon as the Cassandra starts up. The log below shows you that the Cassandra client connections are encrypted.

kubectl logs apigee-cassandra-2 -n apigee -f

INFO  00:44:36 Starting listening for CQL clients on /10.0.2.12:9042 (encrypted)...
INFO  00:44:36 Binding thrift service to /10.0.2.12:9160
INFO  00:44:36 enabling encrypted thrift connections between client and server
INFO  00:44:36 Listening for thrift clients...

Check the Cassandra cluster status

The following command is useful to see if the cluster setup is successful in two data centers. The command checks the nodetool status for the two regions.

kubectl exec apigee-cassandra-0  -- nodetool status


Datacenter: us-central1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          0.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          0.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          0.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1