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.

About Cassandra user 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. Default passwords are provided for these users, and you are not required to change them.

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

Changing the default passwords

Apigee hybrid provides default passwords for the Cassandra users. If you want to change the default user passwords, you can do so in the overrides.yaml file. Add the following configuration, change the default passwords ("iloveapis123") as you wish, and apply the change to your cluster.

All the usernames must be in lowercase.

     default:  ## the password for the new default user (static username: cassandra)
       password: "iloveapis123"
     admin: ## the password for the admin user (static username: admin_user)
       password: "iloveapis123"
     ddl: ## the password for the DDL User (static username: ddl_user)
       password: "iloveapis123"
     dml: ## the password for the DML User (static username: dml_user)
       password: "iloveapis123"

Note the following:

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

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 / (encrypted)...
INFO  00:44:36 Binding thrift service to /
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
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN   78.69 KiB  256          0.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN   78.68 KiB  256          0.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN   15.46 KiB  256          0.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1