Configuring authentication for Cassandra

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

How to configure authentication 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. SeeChanging the default passwords in the overrides file for the steps required to change the default passwords.

These users, including a default user, are described below:

  1. DML User: Used by the client to read and write data to Cassandra (KMS, KVM, Cache and Quota).
  2. DDL User: Used by MART for any of the data definition tasks like keyspace creation, update, and deletion.
  3. Admin User: Used for any administrative activities performed on cassandra cluster.
  4. Default Cassandra user: Cassandra creates a default user when Authentication is enabled and the username iscassandra
  5. JMX User: Used to authenticate and communicate with the Cassandra JMX interface.
  6. Jolokia User: Used to authenticate and communicate with the Cassandra JMX API.

About the default Cassandra user

When Apigee hybrid cluster is created and Cassandra authentication is enabled, the initial user account is the default Cassandra user, identified by the usernamecassandra. The defaultcassandra user functions as a superuser, responsible for tasks such as adding user roles and modifying the database schema.

The Apigee hybridapigee-cassandra-user-setup job utilizes the defaultcassandra user to establish new roles and update the password associated with this default user. The execution of theapigee-cassandra-user-setup job occurs during the initial installation of an Apigee hybrid instance, subsequent instance upgrades, and the provisioning of a new instance as part of region expansion.

When the Apigee hybridapigee-cassandra-user-setup job is executed, the job needs the ability to update and modify database level configurations either as part of a fresh install or an upgrade. The defaultcassandra user is the only user guaranteed to be present when theapigee-cassandra-user-setup job is setting up the new Cassandra pods. Without a known user with superuser access, the Apigee hybrid upgrades and region expansions would not function properly.

The defaultcassandra user password is changed after initial use as part of additional security measures. This means even if the defaultcassandra user is still enabled, the new password must be known to use the defaultcassandra user. The defaultcassandra user is not used by any other components exceptapigee-cassandra-user-setup job as part of the new install and region expansion.

Changing the default passwords in the overrides file

As a security best practice, we recommend changing the default passwords for Cassandra. You can do so in theoverrides.yaml file. Add the following configuration, change the default passwords as you wish, and apply the change to your cluster. Seecassandra. You can view the default passwords in yourvalues.yaml file.

Note: You can only change these defaults at the time of initial setup. Password rotation or change after hybrid setup is not possible. All the usernames must be in lowercase and no special characters are allowed.
cassandra:auth:default:##thepasswordforthenewdefaultuser(staticusername:cassandra)password:"NEW_PASSWORD"admin:##thepasswordfortheadminuser(staticusername:admin_user)password:"NEW_PASSWORD"ddl:##thepasswordfortheDDLUser(staticusername:ddl_user)password:"NEW_PASSWORD"dml:##thepasswordfortheDMLUser(staticusername:dml_user)password:"NEW_PASSWORD"jmx:username:"jmxuser"##theusernamefortheJMXUserpassword:"NEW_PASSWORD"##thepasswordfortheJMXUserjolokia:username:"jolokiauser"##theusernametoaccessjolokiainterfacepassword:"NEW_PASSWORD"##thepasswordforjolokiauser

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 YAML file and edit the required attributes, for examplemy-secret.yaml. Note that if you use this option, you must provide the usernames with each password.

apiVersion:v1kind:Secretmetadata:name:SECRET_NAMEnamespace:APIGEE_NAMESPACEtype:Opaquedata:default.password:DEFAULT_PASSWORD#base64-encodedstringadmin.user:ADMIN_USERNAME#base64-encodedstringadmin.password:ADMIN_PASSWORD#base64-encodedstringdml.user:DML_USERNAME#base64-encodedstringdml.password:DML_PASSWORD#base64-encodedstringddl.user:DDL_USERNAME#base64-encodedstringddl.password:DDL_PASSWORD#base64-encodedstringjmx.user:JMX_USERNAME#base64-encodedstringjmx.password:JMX_PASSWORD#base64-encodedstringjolokia.user:JOLOKIA_USERNAME#base64-encodedstringjolokia.password:JOLOKIA_PASSWORD#base64-encodedstring

WhereSECRET_NAME is the name you choose for the Secret,APIGEE_NAMESPACE is the namespace where the Apigee pods are deployed (default isapigee), and each_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 -fSECRET_FILE

Add the Secret to your overrides file:

cassandra:auth:secret:SECRET_NAME
Note: Seecassandra.auth.secret in the Configuration property reference.Note: If you arerotating Cassandra credentials, you do not need to apply the updated Cassandra override file to the cluster at this step. Skip applying the datastore chart and continue with the rotation process.

Apply the updated Cassandra override to the cluster:

helm upgrade datastore apigee-datastore/ \--namespaceAPIGEE_NAMESPACE \--atomic \-fOVERRIDES_FILE.yaml
Note: If you see an error sayingError: UPGRADE FAILED: "datastore" has no deployed releases, replaceupgrade withinstall and try the command again.

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 -nAPIGEE_NAMESPACE -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:9160INFO  00:44:36 enabling encrypted thrift connections between client and serverINFO  00:44:36 Listening for thrift clients...

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-02-19 UTC.