The Cassandra endpoints may be configured to require authentication and SSL encryption of incoming CQL connections.
|
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. |
Authentication
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-usernamefield. -
Set the password by specifying a secret ID referring to the password in the
cassandra-password-idfield. See Secrets in the SDF for more information on configuring secrets in the SDF.
|
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.
SSL
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.
|
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 365You can optionally have your signing certificate signed by a Certificate Authority (CA).
