The Cassandra endpoints may be configured to require authentication and SSL encryption of incoming CQL connections.

Warning The Cassandra security settings are not reconfigurable, even on upgrade. Reconfiguring any of the below settings will require you to recreate the Rhino VoLTE TAS deployment.


You can configure Cassandra endpoints to require username and password authentication for incoming CQL connections.

To enable authentication, configure the username and password in the product-options section for each Rhino VoLTE TAS VNFC in the SDF, as follows.

  • Set the username in the cassandra-username field.

  • Set the password by specifying a secret ID referring to the password in the cassandra-password-id field. See Secrets in the SDF for more information on configuring secrets in the SDF.

Note All VNFCs within a site must be configured with the same Cassandra username and password.

Setting the Cassandra username and password in the SDF according to the above will create a role with the specified username and password in the Cassandra endpoints running on the TSN VNFs. All VNFs in the Rhino VoLTE TAS deployment will then create CQL connections to these databases using the configured username and password.


You can configure the Cassandra endpoints to require incoming CQL sessions to connect over encrypted SSL connections.

VNFs can be configured to connect to the Cassandra endpoints over SSL connections by setting the boolean field use-client-to-node-cassandra-encryption in the product-options section for each VNFC in the SDF.

TSN VNFs can be configured to accept incoming SSL connections by settings in the product-options section for each TSN VNFC in the SDF. If the field is set to mandatory, incoming CQL sessions must connect over SSL connections, and attempts to connect over plaintext connections will fail.

Important Setting the encryption mode to mandatory is strongly encouraged, as this provides authentication of the TSN nodes to clients as well as encryption to prevent sensitive data being leaked in transit to or from the TSN nodes.

If the field is set to optional, the Cassandra endpoints will accept incoming CQL sessions over both SSL and plaintext connections. If it is set to disabled, the Cassandra endpoints will only accept incoming CQL sessions over plaintext connections, and attempts to connect using SSL will fail.

TSN VNFs will use the certificate-chain and private-key part of the certificate secret to generate signed SSL certificates for the CDS and ramdisk Cassandra endpoints. If the private key for the signing certificate has a password, you must supply the password by provisioning it against the cassandra-encryption-signing-key-password-id field in the product-options section for each TSN VNFC in the SDF.

SSL signing certificate configuration

Clients will authenticate the Cassandra endpoints by checking the endpoint’s SSL certificate against a signing certificate. The signing certificate is provisioned through the certificate secret cassandra-encryption-signing-certificate-id in the SDF. VNFs will use the certificate-chain part of this secret to authenticate the Cassandra endpoints when they instantiate CQL connections over SSL.

You can create a configuration file for your self-signed signing certificate by copying the example gen_rootCa_cert.conf configuration file and respectively replacing <country-code>, <organization>, <organizational-unit>, and <common-name> with your 2-letter country-code (e.g. NZ), the name of your organization, the name of your organizational unit, and a name for your signing certificate. You can optionally protect your signing certificate with a password by adding an output_password parameter to the [ req ] section of the configuration file with the value of your password.

[ req ]
distinguished_name    = req_distinguished_name
prompt                = no
default_bits          = 4096

[ req_distinguished_name ]
C                     = <country-code>
O                     = <organization>
OU                    = <organizational-unit>
CN                    = <common-name>

Once you have created the configuration file, run the following command to create your signing certificate. Provide the desired filename for your signing certificate and its corresponding private key.

openssl req
    -config gen_rootCa_cert.conf
    -new -x509 -nodes
    -out <signing-certificate-filename>
    -keyout <signing-certificate-private-key-filename>
    -days 365

You can optionally have your signing certificate signed by a Certificate Authority (CA).

Previous page Next page
Rhino VoLTE TAS VMs Version 4.1