6.5.32 Sisense

Run the agent on the Sisense node and point it at the installer's certificate files

The Sisense template installs the HTTPS certificate of a self-hosted Sisense deployment on Linux. It writes the certificate and key to the files the Sisense installer reads, replaces the Kubernetes TLS secret that Sisense serves HTTPS from, and checks that port 443 presents the new certificate. The template is in beta.

Sisense serves HTTPS from its ingress controller. Older releases use ingress-nginx. Newer releases use NGINX Gateway Fabric. The template handles both.

Requirements

  • Sisense on Linux with SSL already turned on (is_ssl: true in the installer config).
  • The CertKit Agent installed on the Sisense node. The agent runs as root.
  • kubectl on the agent’s PATH. The Sisense installer sets this up on the node it runs from.
  • A kubeconfig at /root/.kube/config or in the Sisense Linux user’s home, usually /home/sisense/.kube/config. The script uses root’s file first, then the Sisense user’s. The installer creates the Sisense user’s file.
  • openssl on the node for the port 443 check. Without it, the script still replaces the secret but skips the check.

Set the certificate and key destinations

Set Certificate Destination and Private Key Destination to the ssl_cer_path and ssl_key_path values in your installer config, for example /opt/sisense-setup/certs/sisense.example.com.pem and /opt/sisense-setup/certs/sisense.example.com.key.

Every installer run, whether an upgrade, a reconfigure, or a restore, deletes the TLS secret and rebuilds it from those two files. If CertKit writes anywhere else, the next upgrade puts the old certificate back.

The certificate file includes the intermediate chain. Both files are owned by the sisense user and group with 0600 permissions by default. You can change the owner and permissions in Advanced view.

Template variables

Both variables default to auto and are hidden in the simple view. Change them in Advanced view only if automatic discovery picks the wrong secret.

Variable Default What it does
Kubernetes TLS secret name auto The TLS secret Sisense serves HTTPS from. With auto, the script finds the secret named by a Sisense Ingress or Gateway, then falls back to a secret named sisense-tls.
Kubernetes namespace of the secret auto The secret’s namespace. Only used when you set a secret name. With auto, the script finds the namespace that holds a secret of that name. If you set both, the script creates the secret when it doesn’t exist.

Automatic discovery only looks at an Ingress or Gateway whose name or namespace contains “sisense”, so secrets for other apps in the cluster are left alone.

What the script does on each run

  1. Connects to the cluster. Finds kubectl and a kubeconfig, then confirms it can reach the Kubernetes API server.
  2. Finds the secret. Uses the names you set, or discovers the secret as described above.
  3. Updates the secret. Reads the current secret and stops if it isn’t of type kubernetes.io/tls. If the secret already holds this certificate, it skips the change. Otherwise it replaces the secret with kubectl create secret tls --dry-run=client -o yaml | kubectl apply -f -.
  4. Checks port 443. Connects to 127.0.0.1:443, or to the Sisense host name on port 443 if nothing answers locally, and compares the served certificate’s SHA-1 fingerprint to the new one. It waits up to 30 seconds for the controller to load the new secret.
  5. Checks the installer config. Looks under the Sisense user’s home for the installer config file that sets ssl_cer_path, and warns if is_ssl is not true or if either path differs from the CertKit destinations.

The host name for the check comes from the Sisense Ingress or Gateway, then the installer’s application_dns_name, then the certificate’s common name.

Restarts and disruption

Replacing the secret doesn’t interrupt Sisense. In most cases the controller loads the new certificate within seconds and nothing restarts.

If port 443 still presents the old certificate after 30 seconds, the script deletes the ingress-nginx controller pods with a 15-second grace period. Kubernetes starts new pods, which load the new certificate. Expect a short gap in HTTPS service while the new pods start. The script then waits up to 90 seconds for the new certificate before it fails.

The script only restarts ingress-nginx. It never restarts NGINX Gateway Fabric.

Common problems

  • “kubectl not found on the agent’s PATH”: the agent is not on the Sisense node, or kubectl is installed somewhere the root account can’t find. Install the agent on the node where the Sisense installer ran.
  • “No kubeconfig found in /root/.kube/config or /home/sisense/.kube/config”: copy a working kubeconfig to /root/.kube/config. The error also suggests adding export KUBECONFIG=/path/to/kubeconfig to the top of the script, which needs a custom template.
  • “kubectl cannot reach the cluster using …”: the kubeconfig exists but the API server didn’t answer. The lines above the error show kubectl’s own message. Run kubectl get nodes as root to reproduce it.
  • “Found N Sisense TLS secrets (above)” or “Found N secrets named …”: more than one secret matches. Set Kubernetes TLS secret name and Kubernetes namespace of the secret to the one listed above the error that Sisense uses.
  • “No Sisense TLS secret found”: no Sisense Ingress or Gateway references a secret and no secret named sisense-tls exists. Confirm is_ssl: true and that the installer has run with SSL on, or set both variables.
  • “No secret named … found in any namespace”: the secret name you set doesn’t exist. Check the spelling, or set the namespace too so the script creates it there.
  • “Secret … is of type ‘…’, not kubernetes.io/tls”: the named secret is not a TLS secret. The script won’t replace it. Set the name of the secret the ingress controller uses.
  • “kubectl could not read secret …” or “kubectl could not update secret …”: usually the kubeconfig’s identity can’t get or update secrets in that namespace. The lines above the error show the reason.
  • “The secret is updated, but the old certificate is still served and no ingress-nginx controller pods were found to restart”: the secret changed but the controller didn’t load it. This is most likely on a newer release, where NGINX Gateway Fabric serves HTTPS. Check that the Gateway references the secret the script updated.
  • “… still presents … after restarting ingress-nginx”: the controller restarted and still serves another certificate. The script probably updated a different secret than the one the controller serves. Set both variables to the secret the controller uses.
  • “Skipped (nothing answered TLS for …)”: neither 127.0.0.1:443 nor the host name answered from the node. The secret was still replaced. Check the served certificate from a browser.
  • “WARNING: is_ssl is not true” or “WARNING: ssl_cer_path … not …”: the installer config doesn’t match the CertKit destinations. Fix the config or the destinations before the next upgrade, or that upgrade installs the wrong certificate or turns HTTPS off.
  • “No installer config found under …”: the script only searches the Sisense user’s home. If your installer lives elsewhere, check by hand that ssl_cer_path and ssl_key_path match the CertKit destinations.

For a product overview, see certificate automation for Sisense.