Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
minLevel1
maxLevel7

Using GV-Essentials chart

...

Introduction

Summary

Installing a TLS certificate helps verify the identity of the server running the GetVisibility product and eliminates warnings in the web browser about “unknown certificate authority.”

How it works

Network traffic between the machine used to connect to the server (aka client, e.g., a user viewing analytics from their browser or an endpoint agent requesting configuration/classification suggestions) and the server running the GetVisibility product is encrypted at all times (hence the https:// in the URL); however, encrypted does not necessarily mean secure.

The encryption is based on the certificate the server sends when the connection is initiated, so the data sent can only be read by the server it’s intended for. The certificate is signed by a Certificate Authority (CA), which attests that it belongs to the server with the provided domain name.

Should the server appear to send a certificate signed by a CA unknown to the client, a warning is displayed to the user. This happens in a default configuration with the GetVisibility product, as the Traefik CA (built-in to the reverse proxy/load-balancer we use) is not trusted by most machines.

What to do

Instead of adding the Traefik CA certificate on the client machine(s) to the trust store (which would open the possibility of generating a certificate to eavesdrop on the client-server communications), it’s advisable to generate a certificate the client machines will accept (ie. a certificate signed by a CA trusted by machines on the network).

Generally, the CA signing the certificate is either going to be a public CA (e.g. Let’s Encrypt E6 or Sectigo RSA Organization Validation Secure Server CA) or a private CA local to the installation environment (e.g. My Company CA).

(In the latter case, the CA certificate of the private CA will need to be trusted on clients on the network - this is, on most internal networks, already completed.)

CSR

In either case, a Certificate Signing Request (CSR) must be generated along with a private key. The *.CSR file is then sent to the CA to generate a certificate file.

For details on generating a CSR and private key, please see Creating a CSR (Certificate Signing Request) and private key with OpenSSL.


The certificate file along with the private key can now be uploaded to the GetVisibility server.

Preliminary

  • At this point, the certificate file and the private key should be at hand. If not, please see the CSR section above.

The certificate

  • The provided certificate must be an X.509 v3 certificate in the ASCII PEM format (Base64-encoded). The file extension is usually or .pem. Its content looks like this:

    Code Block
    -----BEGIN CERTIFICATE-----
    MIIGBTCCA+2gAwIBAgIUaIGnTiJx27iBiIF+4jIkb7o5miswDQYJKoZIhvcNAQEL
    yroaOk6SX8cOKr4fnykmLc8QUinu4PFIWUkCAwEAAQJAKt1nlkztl8Tyeipa1wvg
    ...
    -----END CERTIFICATE-----

The private key

  • The private key must be a PKCS1 or PKCS8 standard key in the ASCII PEM format (Base64-encoded). The file extension is usually .pem. Its content looks like this:

    Code Block
    -----BEGIN RSA PRIVATE KEY-----
    MIIBOgIBAAJBAJg6oXhHvwgb4wWy/qjyemoJLuuD1tRe6ctjpn2RWulg7+2SePVi
    OHd5hMvM9GP9hU38FaOWa9x2w1mNZNo1uR8C/67wYUGKtUSycAeoJhkLRMGv3wx/
    ...
    -----END RSA PRIVATE KEY-----

    Or like this:

    Code Block
    -----BEGIN PRIVATE KEY-----
    MIIBOgIBAAJBAJg6oXhHvwgb4wWy/qjyemoJLuuD1tRe6ctjpn2RWulg7+2SePVi
    OHd5hMvM9GP9hU38FaOWa9x2w1mNZNo1uR8C/67wYUGKtUSycAeoJhkLRMGv3wx/
    ...
    -----END PRIVATE KEY-----
Info

Keys generated per our guide (see above) will work. Encrypted keys, however, will not.

Copying to the server

  • On Linux/Mac, scp; on Windows, WinSCP could be used to upload the certificate to the server.

    Copying the contents of the certificate file as text into a text editor (e.g. nano or vim) in the SSH window is also acceptable.

  • A custom TLS certificate can be added during the installation of the GetVisibility Essentials (gv-essentials) chart.

Good to know

  • If not done during the initial install, the chart can be re-installed or upgraded with the desired certificate included at any time without affecting data on the cluster.

  • It is possible to fall back to a default self-signed certificate at any time by leaving Use Custom TLS Certificate unchecked (disabled (tls_certificate.enabled=true) - a certificate signed by our reverse-proxy’s Traefik CA will then be generated automatically.

The process

Follow the steps specific to the deployment’s kind. The CLI method works on all deployments, while the Rancher version is easier.

Rancher

Info

This method requires assistance from the Support Team and can not yet be automated.

Go to TLS Certificate tab, click on check the Use Custom TLS Certificate checkbox and paste in into it the content of the certificate and private key in PEM format:

...

Use Self-signed Certificate

...

:

...

CLI

Tip

This method works on all installations and is easier to automate.

  1. Set the KUBECONFIG environment variable, so that helm can interact with the k3s cluster:

Code Block
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

...

Info

Steps 2 and 3 are only needed for Rancher-based installations and only when installing a custom certificate for the first time.

  1. Install helm3:

Code Block
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh
  1. Add the getvisibility helm chart repository:

Code Block
helm repo add gv_stable https://charts.master.k3s.getvisibility.com/stable --username gvcharts --password <password>
Info

The credentials for the GetVisibility charts repository are provided by the Support Team.

...

  1. Ensure the helm repositories are up to date:

Code Block
helm repo update

  1. Convert the certificate and the key file from Windows/DOS newline format to Linux/Unix newline format (by trimming carriage return characters):

Code Block
tr -d '\r' <server.cer >server-unix.cer
tr -d '\r' <private.key >private-unix.key

  1. Upgrade or reinstall the gv-essentials helm-chart, reusing older values and appending the certificate values from files.

Tip

Helm will automatically update if there is a new version available - otherwise, it’ll just reinstall the existing version.

Code Block
helm upgrade --install gv-essentials gv_stable/gv-essentials \
--wait --timeout=10m0s --debug --reuse-values \
--set tls_certificate.enabled=true \
--set-file tls_certificate.tls_crt=server-unix.cer \
--set-file tls_certificate.tls_key=private-unix.key

  1. (Optional): Confirm that the chart has been installed with the appropriate values, and that your certificate ended up in the appropriate ConfigMaps:

Code Block
helm get values -a gv-essentials | grep "tls_"

kubectl get secret -n kube-system custom-default-cert -o go-template='{{index .data "tls.key" | base64decode}}'

Sources

...