Configuring TLS for Cassandra

This topic explains how to configure authentication for communication between Cassandra nodes and between clients and Cassandra nodes.

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.

You can configure the authentication using username/password combinations either placed directly in the overrides file or added to a Kubernetes Secret, as explained in this topic.

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 require authentication. There are multiple client users 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, Cache 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
  • JMX User:Used to authenticate and communicate with the Cassandra JMX interface.
  • Jolokia User:Used to authenticate and communicate with the Cassandra JMX API.

Changing the default passwords in the overrides file

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.

 cassandra 
 : 
  
 auth 
 : 
  
 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" 
  
 jmx 
 : 
  
 username 
 : 
  
 "jmxuser" 
  
 ## 
  
 the 
  
 username 
  
 for 
  
 the 
  
 JMX 
  
 User 
  
 password 
 : 
  
 "iloveapis123" 
  
 ## 
  
 the 
  
 password 
  
 for 
  
 the 
  
 JMX 
  
 User 
  
 jolokia 
 : 
  
 username 
 : 
  
 "jolokiauser" 
  
 ## 
  
 the 
  
 username 
  
 to 
  
 access 
  
 jolokia 
  
 interface 
  
 password 
 : 
  
 "iloveapis123" 
  
 ## 
  
 the 
  
 password 
  
 for 
  
 jolokia 
  
 user 

Note the following:

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

Setting usernames and passwords in a Kubernetes Secret

This section explains how to configure Cassandra to use Kubernetes Secrets for authentication.

Create the Secret

Use the following template to configure the Kubernetes Secret. Save the template to a file and edit the required attributes. Note that if you use this option, you must provide the usernames with each password.

 apiVersion 
 : 
  
 v1 
 kind 
 : 
  
 Secret 
 metadata 
 : 
  
 name 
 : 
  
  $SECRET_NAME 
 
  
 namespace 
 : 
  
  $APIGEE_NAMESPACE 
 
 type 
 : 
  
 Opaque 
 data 
 : 
  
 default 
 . 
 password 
 : 
  
  $PASSWORD 
 
  
 # 
 base64 
 - 
 encoded 
  
 string 
  
 admin 
 . 
 user 
 : 
  
  $USERNAME 
 
  
 # 
 base64 
 - 
 encoded 
  
 string 
  
 admin 
 . 
 password 
 : 
  
  $PASSWORD 
 
  
 # 
 base64 
 - 
 encoded 
  
 string 
  
 dml 
 . 
 user 
 : 
  
  $USERNAME 
 
  
 # 
 base64 
 - 
 encoded 
  
 string 
  
 dml 
 . 
 password 
 : 
  
  $PASSWORD 
 
  
 # 
 base64 
 - 
 encoded 
  
 string 
  
 ddl 
 . 
 user 
 : 
  
  $USERNAME 
 
  
 # 
 base64 
 - 
 encoded 
  
 string 
  
 ddl 
 . 
 password 
 : 
  
  $PASSWORD 
 
  
 # 
 base64 
 - 
 encoded 
  
 string 
  
 jmx 
 . 
 user 
 : 
  
  $USERNAME 
 
  
 # 
 base64 
 - 
 encoded 
  
 string 
  
 jmx 
 . 
 password 
 : 
  
  $PASSWORD 
 
  
 # 
 base64 
 - 
 encoded 
  
 string 
  
 jolokia 
 . 
 user 
 : 
  
  $USERNAME 
 
  
 # 
 base64 
 - 
 encoded 
  
 string 
  
 jolokia 
 . 
 password 
 : 
  
  $PASSWORD 
 
  
 # 
 base64 
 - 
 encoded 
  
 string 
  

Where $SECRET_NAME is the name you choose for the Secret, $APIGEE_NAMESPACE is the namespace where the Apigee pods are deployed (default is apigee ), and $USERNAME and $PASSWORD are the usernames and passwords for each user. Note that the username and password must be Base64-encoded.

Apply the Secret to the cluster. For example:

kubectl apply -f $SECRET_FILE 

Add the Secret to your overrides file:

 cassandra 
 : 
  
 auth 
 : 
  
 secret 
 : 
  
  $SECRET_NAME 
 

Apply the updated Cassandra override to the cluster:

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --datastore

Check the Cassandra logs

Check the logs as soon as 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...
Design a Mobile Site
View Site in Mobile | Classic
Share by: