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 Apigee hybrid Beta 2, 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 CassandraTo configure TLS for your Cassandra database, do the following:
- Open the
- Add the following configuration to provide to path to your server cert, key, and
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
overrides.yaml file, add the following configuration and apply the
All the usernames must be in lowercase.
cassandra: auth: ## Note: Usernames must not contain hyphens 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.
- 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
- 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