Production checklist

Even though the Helm Chart makes installing Horizon a breeze, you’ll still have to set up a few things to make Horizon resilient enough to operate in a production environment.

Operating the database

All persistant data used by Horizon is stored in the underlying MongoDB database. Therefore, the database should be operated securely and backed up regularly.

When installing the chart, you face multiple options regarding your database :

By default, a local MongoDB standalone instance will be spawned in your cluster, using the bitnami/mongodb chart. No additional configuration is required but it is not production ready out of the box. You can configure the chart as you would normally below the mongodb key:
```
mongodb:
  architecture: replicaset
  # Any other YAML value from the chart docs
```
If you want to use an existing MongoDB instance, provide the externalDatabase.uri value. The URI should be treated as a secret as it must include credentials:
```
externalDatabase:
  uri:
    valueFrom:
      secretKeyRef:
        name: <secret name>
        key: <secret key>
```

The chart doesn’t manage the database. You are still in charge of making sure that the database is correctly backed up. You could either back up manually using mongodump or use a managed service such as MongoDB Atlas, which will take care of the backups for you.

Managing secrets

Storing secrets is a crucial part of your Horizon installation. On cloud-native installations like on Kubernetes, we recommend using SSV (Secure Software Vault) to encrypt sensitive data: a master passphrase will be used to encrypt and decrypt data before they enter the database. Alongside with other application secrets like your MongoDB URI (containing your credentials or certificate). We recommend that you create Kubernetes secrets beforehand or inject them directly into the pod.

Values that should be treated as secrets in this chart are:

Name Description Impact on loss

Name	Description	Impact on loss
`vaults.*.master_password`	SSV password used to encrypt sensitive data in database.	Highest impact: database would be unusable
`events.secret`	Secret used to sign and chain events.	Moderate impact: events integrity would be unverifiable
`externalDatabase.uri`	External database URI, containing a username and password.	Low impact: reset the MongoDB password
`appSecret`	Application secret use to encrypt session data.	Low impact: sessions would be reset
`mailer.password`	SMTP server password	Low impact: reset the SMTP password

vaults.*.master_password

SSV password used to encrypt sensitive data in database.

Highest impact: database would be unusable

events.secret

Secret used to sign and chain events.

Moderate impact: events integrity would be unverifiable

externalDatabase.uri

External database URI, containing a username and password.

Low impact: reset the MongoDB password

appSecret

Application secret use to encrypt session data.

Low impact: sessions would be reset

mailer.password

SMTP server password

Low impact: reset the SMTP password

For each of these values, either :

leave the field empty, so that a secret will be automatically generated.

derive the secret value from an existing Kubernetes secret :

appSecret:
  valueFrom:
    secretKeyRef:
      name: <secret name>
      key: <secret key>

Always store auto-generated secrets in a safe place after they’re generated. If you ever uninstall your Helm chart, the deletion of the SSV secret will lead to the impossibility of recovering most of your data.

High availability

By default, the chart will configure a single-pod deployment. This deployment method is fine for testing but not ready for production as a single failure could take down the entire application. Instead, we recommend that you set up a Horizon cluster using at least 3 pods.

In order to do that, configure an horizontalAutoscaler in your override-values.yaml file:

horizontalAutoscaler:
  enabled: true
  minReplicas: 3
  maxReplicas: 3

Use nodeAffinity to spread your Horizon cluster Pods among multiple nodes in different availability zones to reduce the risk of Single Point of Failure.

Configuring ingresses

To create an ingress upon installation, simply set the following keys in your override-values.yaml file:

ingress:
  enabled: true
  hostname: horizon.lab
  tls: true

We support autoconfiguration for major ingress controllers: Kubernetes Ingress NGINX and Traefik. Autoconfiguration is the recommended way of configuring your ingress as it will handle configuration quirks for you. To enable autoconfiguration, set the type key to your ingress controller in the ingress definition. Accepted values are nginx and traefik.

ingress:
  enabled: true
  type: "" # nginx or traefik
  clientCertificateAuth: true
  hostname: horizon.lab
  tls: true

clientCertificateAuth can be used to control whether to ask for a client certificates when users access Horizon.

If you wish to manually configure your ingress or use another ingress controller, head to the Manual ingress configuration section.

Manual ingress configuration

If you do not wish or cannot use autoconfiguration, you should ensure your ingress controller is correctly configured to enable all Horizon features.

When requiring client certificates for authentication, the web server should not perform checks to validate that the certificate is signed by a trusted CA. Instead, the certificate should be sent to Horizon through a request header, base64-encoded. The header name used can be controlled using the clientCertificateHeader.
Some endpoints should not be server over HTTPS, in particular those used for SCEP enrollment. You may want to create an HTTP-only ingress for serving paths prefixed by /scep and /certsrv, and prevent those from redirecting to HTTPS.