Communications security
Published 08 December 2022
Communications between all Redgate clone components are secured through the use of Transport Layer Security (TLS). TLS gives us end-to-end security, including digital signing and encryption. This covers HTTPS and TCP.
For this we need a DNS and a TLS certificate. You may use self signed certificates if you don't have a signed one. This is recommended for a quick startup and not for use with production data. This page covers both configuring TLS and using self-signed certificates.
Contents
Setup DNS
To get TLS working you need to set up a custom DNS and specify it as part of Redgate Clone configuration.
You will need to create an FQDN (Fully Qualified Domain Name) and specify it as an Instance DNS.
Everybody, who will need to run/execute rgclone
commands will need to have access to that Instance DNS.
This will need to be a CNAME record that redirects to the host machine running the cluster (this is typically an IPv4 address). See official Google docs on how to add a CNAME record to your domain's DNS records.
If you are on an AKS cluster, there is an extra field for the Azure DNS Label. This should be the same as the DNS label configured in the Networking settings when you created your AKS instance, but if you have not already configured a DNS label it must be a unique value within the Azure location.
TLS Certificates
Admin page
Considering that the Configuration page in Admin Console may hold your sensitive business information (i.e. SMB file-share access details), you could choose to secure the Admin Console with the TLS certificate.
See Upload/Reset TLS Certificate (Admin Console) for more information.
Redgate Clone secure CLI communications
First Time Upload
You will need a TLS Certificate (i.e. my-certificate.crt
) and a TLS Key (i.e. my-certificate.key
) files to upload to the configuration page. You may use self signed certificates if you don't have a signed one. See the section below.
Select on provide a certificate from the configuration page.
TLS Certificate
The PEM file containing the TLS certificate. The PEM file should contain the certificate itself along with any required intermediate certificates, in the following order.
- Your signed SSL certificate (e.g., cert.pem)
- The intermediate certificate (e.g., intermediate.crt or intermediate.pem)
- The root certificate
The file should have this format:
-----BEGIN CERTIFICATE-----
certificate 1
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
certificate 2
-----END CERTIFICATE-----
...
TLS Key
The PEM file containing the TLS key. The file should have this format:
-----BEGIN PRIVATE KEY-----
private key
-----END PRIVATE KEY-----
Self signed certificates
You may use self signed certificates if you don't have a signed one. This is recommended for a quick startup and not for use with production data. The certificate is not trusted but still ensures encryption.
Select Generate a self-signed certificate in the configuration page, then Redgate clone generates the certificate for you after you save the changes on the page.
If your instance of Redgate Clone is using a self-signed certificate, any clients will need to be told to trust that certificate to allow communication between the rgclone CLI and Redgate Clone itself.
Step 1 - retrieve the certificate
Run a kubectl
command to retrieve the certificate from the cluster and save it to a file called rgclone.crt
Linux
kubectl get secrets/redgate-platform-ca -n redgate-clone-app -o jsonpath='{.data.tls\.crt}' | base64 --decode > rgclone.crt
Windows
$encoded_cert = kubectl get secrets/redgate-platform-ca -n redgate-clone-app -o jsonpath='{.data.tls\.crt}' [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($encoded_cert)) > rgclone.crt
Step 2 - copy the certificate file to the client machine
If you're running kubectl
from a machine that is not the client machine, you will need to copy the certificate file ( rgclone.crt
) to the client machine.
Step 3 - install the certificate on the client machine
Windows
Run this Powershell command from an elevated Powershell session (i.e. "Run as administrator")
Import-Certificate -FilePath rgclone.crt -CertStoreLocation Cert:\LocalMachine\AuthRoot
Ubuntu Linux
Place the certificate file in /usr/local/share/ca-certificates/
, then run:
sudo update-ca-certificates
Red Hat Enterprise Linux
Place the certificate file in /etc/pki/ca-trust/source/anchors/
, then run:
sudo update-ca-trust
Updating Expired / Changing TLS Certificate
While using the product you may be required to upload a new certificate. This may be due to:
- Certificates expiring; or
- Uploading a wrong/invalid certificates the first time.
Currently certificates are being cached within the product, thus, changing them requires a few more steps, which are listed below.
- Go to the Admin Console.
- Upload new certificates.
- Hit Save & deploy a new version.
Execute commands shown below (this will force remove the cache).
Warning
This will stop ALL communications with Redgate Clone whilst the services restart. We highly recommend to execute this only if no one is using the product.
kubectl delete -n ingress-nginx deployment/ingress-nginx-controller kubectl delete -n ingress-nginx deployment/ingress-nginx-defaultbackend kubectl delete -n ingress-nginx service/ingress-nginx-controller kubectl delete -n ingress-nginx service/ingress-nginx-defaultbackend