The Validio application is distributed as a Helm chart. The Helm chart is installable on managed Kubernetes clusters.

Validio is available for the following cloud providers:

• Google Cloud Platform (GCP): GKE.
• Amazon Web Services (AWS): EKS.
• Microsoft Azure: AKS.

Prerequisites

1. Access to docker images using a JSON file provided by Validio. For more information, contact us.

2. Configure a Kubernetes cluster on GCP, AWS or Azure. Considering the following:

1. All nodes must be in the same AWS availability zone, GCP zone or Azure zone.
2. Persistent volume provisioning enabled, to create Kubernetes PVC resources.
3. We also recommend a configured load balancer or ingress controller, such as:
   1. GCP Ingress Controller
   2. AWS Load Balancer Controller
   3. AKS Application routing add-on

3. Install the following:

• kubectl CLI tool and set the kubectl context to the destination cluster.
• Helm version 3.8.0 or later with Helm OCI support.

Installation

Complete the following steps to install your VPC deployment. Also, you can refer to VPC Deployment Examples.

1. Create namespace

Create the namespace you want to use for your configuration. In our examples, we use validio.

kubectl create namespace validio

2. Add the docker-registry secret

Create a Kubernetes Secret to pull the docker images required by the helm chart. This requires the JSON file provided by Validio.

First, set the VALIDIO_SECRET environment variable to point to your JSON file:

export VALIDIO_SECRET=/home/user/Downloads/validio-secret.json

Then, add the Kubernetes Secret:

kubectl -n validio create secret docker-registry artifact-registry --docker-server=https://europe-docker.pkg.dev --docker-username=_json_key --docker-password="$(cat ${VALIDIO_SECRET})" 

3. Install the helm chart

helm install validio oci://europe-docker.pkg.dev/validio-platform-prod/charts/validio --version [your-validio-version] --namespace validio --values validio-values.yaml

4. Configure the validio-values.yaml file

The Helm chart supports the following keys in the validio-values.yaml file:

If the default value is false or true, the value type is bool. For all others, the value type is String.

All <service>.resources.* keys supports both CPU and Memory resources, specified only as <service>.resource.*.

Available keys for each service:

<service>:
  resources:
    limits:
      cpu: <value>
      memory: <value>
    requests:
      cpu: <value>
      memory: <value>

If you have special requirements for Kubernetes pod placements, like using affinity, tolerations or nodeSelector that is possible on all our services. Here is an example of how it would be done:

<service>:
  nodeSelector:
    <label>: "<value>"
  tolerations:
    - key: <key>
      operator: Equal
      value: "<value>"
      effect: NoSchedule

Most services also supports controlling the Kubernetes Liveness and Readiness probes. They are specified above in the table as <service>.probes.*. Available keys are listed below, note that they are enabled by default and the commented values are the default values, so no need to make any changes if you are happy with the default values.

<service>:
  probes:
    liveness:
      enabled: true
      # failureThreshold: 3
      # initialDelaySeconds: 0
      # periodSeconds: 10
      # successThreshold: 1
      # terminationGracePeriodSeconds: 30
      # timeoutSeconds: 1
    readiness:
      enabled: true
      # failureThreshold: 3
      # initialDelaySeconds: 0
      # periodSeconds: 10
      # successThreshold: 1
      # terminationGracePeriodSeconds: 30
      # timeoutSeconds: 1

Manage the Diver encryption key

The Diver service encrypts the credentials and integration secrets that Validio stores. By default, the Helm chart generates a single encryption key that can't be changed. From Validio 11.1, you can supply your own encryption keys and rotate them with the ve.diver.encryptionKeys keys.

Validio never has access to your encryption keys and can't recover data encrypted with a key that you lose. Include the key Secret in your backups. For more information, refer to Backing up VPC Deployments.

Create the key Secret

You create and manage the key Secret yourself, for example by syncing it from your secret manager. The Helm chart never generates it. The Secret holds one entry per key. To generate a key:

openssl rand -base64 32 | tr -d '\n'

For example, to create a Secret named diver-encryption-keys with one key entry named v1:

kubectl -n validio create secret generic diver-encryption-keys --from-literal=v1="$(openssl rand -base64 32 | tr -d '\n')"

Enable rotatable keys

1. Create the key Secret in the release namespace.

2. Add the following to your validio-values.yaml file:

   YAML

   ve:
     diver:
       encryptionKeys:
         enabled: true
         existingSecret: diver-encryption-keys
         key: v1

3. Upgrade the Helm release.

On the first start after the upgrade, Diver re-encrypts everything stored under the original key with the key that ve.diver.encryptionKeys.key names. Leave your existing encryption key configuration unchanged, and keep the original key for as long as you have backups taken before this change. Restoring one of those backups needs the original key.

Rotate the key

1. Add a new entry to the key Secret, for example v2. Keep the existing entries.
2. Set ve.diver.encryptionKeys.key to the name of the new entry.
3. Upgrade the Helm release. Diver restarts and re-encrypts all stored secrets with the new key.

If you change ve.diver.encryptionKeys.key before the updated Secret has reached the Diver pod, Diver restarts until the new entry is available. This usually takes less than a minute.

Verify the key in use

After you enable rotatable keys or change the key, check the Diver logs for one of the following messages:

• Re-encrypted stored secrets with the configured encryption key: Diver re-encrypted your data with the new key.
• Stored secrets already use the configured encryption key: Diver found your data already encrypted with the configured key. Diver logs this on every later start.

Keep old keys

Don't delete a key entry while backups taken under that key still exist. To restore such a backup, the key Secret must contain the entry that was in use when the backup was taken.

This also applies to the original encryption key that Diver used before you enabled rotatable keys. Keep it for as long as you have backups taken before that point, even after you have rotated to a new key.

Sign in to the Validio platform

The first time you sign in to the Validio platform, you must use the admin credentials created in the Kubernetes Secret.

kubectl -n validio get secrets validio-postgres -o=jsonpath='{.data.validio_app_auth_password}' | base64 -d ; echo

Access your Validio platform:

In your browser, navigate to the hostname specified in the surface.ingress.host key. For example, https://validio.example.com/

If you did not configure an ingress, use port-forward to forward the Validio platform to your localhost:

kubectl -n validio port-forward svc/validio-surface 8889

Then, you can find it on http://localhost:8889/