Redgate Clone

Communications security

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.

  1. Your signed SSL certificate (e.g., cert.pem)
  2. The intermediate certificate (e.g., intermediate.crt or intermediate.pem)
  3. 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.

  1. Go to the Admin Console.
  2. Upload new certificates.
  3. Hit Save & deploy a new version.
  4. 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

Didn't find what you were looking for?