{"id":7695,"date":"2024-03-19T07:00:28","date_gmt":"2024-03-19T14:00:28","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cosmosdb\/?p=7695"},"modified":"2024-03-13T07:42:41","modified_gmt":"2024-03-13T14:42:41","slug":"how-to-use-self-signed-certificates-to-connect-to-azure-managed-instance-for-apache-cassandra","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cosmosdb\/how-to-use-self-signed-certificates-to-connect-to-azure-managed-instance-for-apache-cassandra\/","title":{"rendered":"How to use self-signed certificates to connect to Azure Managed Instance for Apache Cassandra"},"content":{"rendered":"

Azure Managed Instance for Apache Cassandra, a fully managed service, enables you to run Apache Cassandra workloads on Azure, freeing you from managing the infrastructure. In this blog post, I will show you how to use self-signed certificates to connect to your cluster and verify the identity of both the client and the server.<\/p>\n

What is a self-signed certificate?<\/h2>\n

By default, all connections made by Azure Managed Instance for Apache Cassandra are secured using SSL certificates signed by a Certificate Authority (CA). Certificate authority signed certificates provide an extra layer of trust and security to all connections that use them. They are used in Cassandra\u2019s inter-node communication and the default for client-side authorization of the server. With a self-signed certificate, you act as your own CA, creating the root (private) and leaf (public) certificates. This certificate is only to verify your own client\u2019s connection to the database, so there is no need for a third party.<\/p>\n

Why use self-signed certificates?<\/h2>\n

When you use this managed service, all communication is done through your own personal virtual network (VNet) into which resources are injected, so all traffic from client to node will be done on secure Microsoft channels<\/a>. This also allows fine tuning of the network security rules applied to the connection through network security groups (NSGs), except for certain rules needed for the operation of Cassandra.<\/p>\n

Self-signed certificates add an extra layer of security by enabling authentication of the client by the cluster. By default, the client verifies the cluster it is connecting to using Azure\u2019s default certificates<\/a>. Those certificates are signed by a trusted certificate authority. However, in this default setup, the cluster does not verify the client, instead trusting that anyone able to access the VNet can access the database. Adding the self-signed certificates ensures that only clients who have access to the key can communicate with the cluster.<\/p>\n

\"Is<\/p>\n

Figure 1: An example of the communication pattern for a mutual <\/a>TLS connection (one where the self-signed certificates are set up)<\/p>\n

How to use self-signed certificates?<\/h2>\n

Generating a client certificate is a straightforward process. First you need a configuration file, for example: gen_rootCa_cert.conf from the DataStax documentation<\/a>:<\/p>\n

# gen_rootCa_cert.conf<\/span>\r\n[ <\/span>req ]<\/span>\r\ndistinguished_name = req_distinguished_name<\/span>\r\nprompt\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= no<\/span>\r\noutput_password\u00a0 \u00a0 = myPass<\/span>\r\ndefault_bits\u00a0 \u00a0 \u00a0 \u00a0= 2048<\/span>\r\n\r\n[ req_distinguished_name ]<\/span>\r\nC                  = US<\/span>\r\nO\u00a0\u00a0\u00a0\u00a0              = YourCompany<\/span>\r\nOU\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 = TestCluster<\/span>\r\nCN\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 = YourComputerName<\/span><\/pre>\n
This file contains information included in your certificate, such as the common name, country, and organization. You can edit this file to suit your needs.<\/p>\n
Then, if you have openssl installed on your machine, you can use the command:<\/p>\n
openssl req \\<\/span>\r\n  -config gen_rootCa_cert.conf \\<\/span>\r\n  -new -x509 -nodes \\<\/span>\r\n  -subj \/CN=YourComputerName\/OU=TestCluster\/O=YourCompany\/C=US\/ \\<\/span>\r\n  -keyout rootCa.key \\<\/span>\r\n  -out rootCa.crt \\<\/span>\r\n  -days 365<\/span><\/pre>\n
To generate the key and the certificate in <\/a>PEM format. The client uses the key to verify the cert which the cluster provides.<\/p>\n
The rest of the steps described in the DataStax document are not necessary. Instead, simply run the following steps from the Quickstart Guide<\/a>:<\/p>\n
resourceGroupName='<Resource_Group_Name>'<\/span>\r\nclusterName='<Cluster Name>'<\/span>\r\naz managed-cassandra cluster update \\<\/span>\r\n  --resource-group $resourceGroupName \\<\/span>\r\n  --cluster-name $clusterName \\<\/span>\r\n  --client-certificates \/usr\/csuser\/clouddrive\/rootCert.pem<\/span><\/pre>\n
The reason that you do not have to follow all the steps laid out in the linked tutorial is because issuing the managed-cassandra update sets up the cassandra.yaml to use the client_encryption_options and adds the certificate you included in the command to the keystore of each node. The rolling restart applies those yaml changes to the Cassandra process.<\/p>\n
In the end, all nodes will expect a valid client certificate with every request.<\/p>\n
How to connect to your cluster using cqlsh?<\/h2>\n
To connect to the cluster with cqlsh after you set up your self-signed certificates, use the following settings.<\/p>\n
[authentication]<\/span>\r\nusername = <cluster-username><\/span>\r\npassword = <cluster-password><\/span>\r\n\r\n[connection]<\/span>\r\nhostname = <node-ip OR node.managedcassandra.cosmos.azure.com><\/span>\r\nport = 9042<\/span>\r\n\r\n[ssl]<\/span>\r\nuserkey = \/path\/to\/rootCa.key<\/span>\r\nusercert = \/path\/to\/rootCa.crt<\/span>\r\ncertfile = \/etc\/ssl\/certs\/digicertroot.crt<\/span>\r\nvalidate = <\/span>true ;; Optional, see below<\/span><\/pre>\n
In this file, you need to replace the following placeholders with the actual values:<\/p>\n