Skip to main content
A deployment with TLS only accepts encrypted connections. That covers clients, replication between nodes, Sentinel, and the bus that connects the shards of a sharded deployment. You turn TLS on in the Encryption step of the create wizard, and choose who issues the certificates there. TLS is set when a deployment is created. You cannot turn it on or off for an existing deployment.

​
Choose who issues the certificates

Every component of a deployment has to trust the others, so all of them share one CA. The issuers differ in what they need from you and in which deployments they work for.

​
Issued by FalkorDB Enterprise

The Admin Server creates a CA for the deployment and a certificate signed by it.
  • The CA is valid for 10 years. It is stored with its key in the Secret <name>-tls-ca, which never leaves the deployment’s namespace and is not mounted into any pod.
  • The certificate is valid for one year and is stored in the Secret <name>-tls. It is renewed 30 days before it expires, signed by the same CA, so clients keep working without changes.
  • The certificate names every pod of every component, the deployment’s Services, localhost, and its external domain when it has one. Clients that verify hostnames can connect by any of those names.
Both Secrets belong to the deployment and are deleted with it.

​
cert-manager

The Admin Server creates a cert-manager Certificate named <name>-tls in the deployment’s namespace. It asks for the same names as the FalkorDB Enterprise issuer, and is signed by the Issuer or ClusterIssuer you select. cert-manager writes the Secret <name>-tls and renews it. The option is unavailable when cert-manager is not installed in the Kubernetes cluster. The issuer you choose has to:
  • Sign names under svc.cluster.local. A CA or Vault issuer can; an ACME issuer such as Let’s Encrypt cannot.
  • Include its CA certificate in the Secret as ca.crt, so that every component trusts the others and the deployment page can show the CA to clients.

​
Your own Secret

Point the deployment at a Secret that holds a certificate, its private key and the CA that signed it. The default key names are ca.crt, tls.crt and tls.key; you can name others in the wizard. The certificate is used by every component, so it must:
  • Be signed by the CA in the Secret.
  • Allow both server and client authentication, because nodes also connect to each other.
  • Name the hostnames your clients connect to, if they verify them. Pod names follow *.<name>-<component>-headless.<namespace>.svc.cluster.local.
When you replace the certificate in the Secret, the deployment picks it up, usually within a few hours: one hourly check notices the change and a later one reloads it in the pods. See Renewal.

​
Issued by KubeBlocks

KubeBlocks generates a separate CA for each component, and its certificates only name the pods of that component. Components therefore cannot verify each other, so this option is only offered for standalone deployments and replication without Sentinel. It cannot be used with an external domain.

​
Renewal

Every hour, the Admin Server checks each deployment that uses TLS (except one issued by KubeBlocks) and takes it one step through the list below, so a change can take more than one check to reach the pods:
1

Renews the certificate when it has to

FalkorDB Enterprise renews its certificate when it is about to expire, or when it no longer names every component. cert-manager is asked for any new names and renews on its own schedule.
2

Copies it to the deployment's pods

The certificate reaches every component of the deployment, as files in each pod.
3

Reloads it on the FalkorDB nodes

Every FalkorDB node loads the new files in place, without a restart: a Custom operation, listed on the Operations tab, runs CONFIG SET for the certificate, key and CA files on each node. Open connections, replication and the cluster bus carry on; new connections get the new certificate. It waits until the deployment is Running.
4

Restarts Sentinel

Sentinel cannot reload its certificate, so a deployment with Sentinel then restarts its Sentinels (a Restart operation). The FalkorDB nodes keep running.
If the reload fails, the Admin Server restarts the whole deployment instead (a rolling Restart operation), and if that fails too, a later check starts over. Each renewal, reload and restart is recorded in the audit log.
A sharded deployment without persistent volumes is never restarted automatically: each shard would come back without its cluster state, and the shards could not form a cluster again. Its certificate is still reloaded in place; only when that fails does the audit log record that it has a new certificate to load. Restart it yourself once that is safe, or recreate it with persistence.
KubeBlocks names the shards of a sharded deployment when it creates them. When FalkorDB Enterprise or cert-manager issues its certificates, their names are therefore added once the deployment is running, and the shards reload the certificate. A certificate you provide is used as it is.
The reload runs through two OpsDefinitions the Admin Server creates and keeps current, falkordb-enterprise-tls-reload and falkordb-enterprise-cluster-tls-reload. KubeBlocks runs them in the FalkorDB containers with its own service account. The deployment page shows who issues the certificates and when the current one expires.

​
Connect with TLS

The deployment page shows the CA certificate under Connection Details. Save it to a file and give it to your client. For example, with redis-cli:
Clients connect to the same ports as without TLS: 6379 for FalkorDB nodes, and 26379 for Sentinel. Plain connections are refused. Nodes do not ask clients for a certificate. Open in Browser on the deployment page opens the FalkorDB Browser with TLS turned on.