Installing Sisense without ClusterVisibility

Last updated: October 21, 2026

You can install Sisense without cluster visibility (namespace-scoped mode). Sisense is installed in a Kubernetes namespace, and the Sisense services get permissions only within that namespace: no ClusterRoles or ClusterRoleBindings are created for them. This is primarily used for security reasons, for example on a cluster that is shared with other workloads.

The recommended way to install Sisense in this mode is with Helm. See Installing with Helm. You can also use sisense.sh. See Installing with sisense.sh.

What Changes Without Cluster Visibility

When global.clusterVisibility is false (cluster_visibility: false in sisense.sh):

• The ClusterRoles and ClusterRoleBindings of the build, management, oxygen, and validator services are not created. These services run with cluster visibility turned off.

• Sisense cannot read or label the Kubernetes nodes. For example, it cannot get the node names (kubectl get nodes), and it cannot manage the Sisense node labels.

• The validator job cannot read nodes, PersistentVolumes, or Gateways.

• Internal monitoring is not supported. The Sisense services cannot access pods and ConfigMaps in other namespaces, and the ConfigMap with the Sisense Grafana dashboards is empty, so you cannot use Prometheus and Grafana to view pod usage.

• The Logging Helm chart cannot be used with namespace-only permissions: it creates a ClusterRole and a DaemonSet that reads log files from the nodes. See Installing/Updating Sisense Logging Helm Chart.

• The network policies for custom code and exporting are created as standard Kubernetes NetworkPolicies instead of Calico network policies.

Prerequisites

1. Ensure that you fulfill the general prerequisites listed in Checking the Prerequisites and Planning Your Configuration.

2. You must have a pre-installed Kubernetes cluster, and you must be connected to it (you can run kubectl commands such as kubectl get pod).
   For example: To install Kubernetes via the sisense.sh script, modify the installer/extra_values/installer/installer-values.yaml file, and make sure install_k8s_only: true, which will only install Kubernetes and will exit without Sisense installation.

3. The identity that runs the installation needs the following Kubernetes permissions:

   • Full administrative rights in the Sisense namespace (the chart creates Roles, RoleBindings, ServiceAccounts, workloads, Services, ConfigMaps, Secrets, and PVCs there).

   • list on nodes and get on namespaces. The chart reads these cluster-scoped objects while it renders, even in namespace-scoped mode. Without them, helm install fails with a forbidden error.

   • If a namespace named monitoring exists in the cluster, the chart also creates a Role and a RoleBinding in it, so the identity needs rights to create them there.

   For example, a cluster administrator can grant the read access with the following ClusterRole (bind it to the installing identity with a ClusterRoleBinding):

   Copy

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: sisense-install-read
   rules:
   - apiGroups: [""]
     resources: ["nodes"]
     verbs: ["list"]
   - apiGroups: [""]
     resources: ["namespaces"]
     verbs: ["get"]

   For more information, see Privileges and Permissions for Self-Deployment.

4. Create a namespace:

NAMESPACE=sisense #for example
kubectl create ns ${NAMESPACE}

5. Label your Kubernetes nodes with the Sisense label. Sisense does not label the nodes in this mode, so you or your cluster administrator must do it. Every node that should run Sisense pods needs the following label, where ${NAMESPACE} is your Sisense namespace:

The label key is case-sensitive (capital A), and the value is true. Pods do not schedule on nodes without this label. The role labels node-${NAMESPACE}-Build=true and node-${NAMESPACE}-Query=true, which sisense.sh applies in other modes, do not make a node eligible for Sisense pods; you can add them to keep the same labels as other installations.

Label the node pool or node group (in the AKS, EKS, or GKE node pool settings, or the equivalent in your platform) rather than individual nodes. A label that you add with kubectl label node is lost when the autoscaler replaces the node.

For example:

kubectl label node ${your_node_1} node-${NAMESPACE}-Application=true --overwrite=true
kubectl label node ${your_node_2} node-${NAMESPACE}-Application=true --overwrite=true
kubectl label node ${your_node_3} node-${NAMESPACE}-Application=true --overwrite=true

# Check which nodes carry the label:
kubectl get nodes -l node-${NAMESPACE}-Application=true

6. Make sure that your Storage Classes exist. Sisense does not install storage drivers in this mode. You need (or you can use the same Storage Class for both RWX and RWO):

• One for RWX (Read/Write many, for the shared Sisense storage)

• One for RWO (Read/Write once, for the stateful sets, such as MongoDB/ZooKeeper)

  For more information, see Storage Requirements for Self-Deployment.

  Storage Class installation example

  For this example, assume there is an NFS server with an NFS path, so we will install an NFS Storage Class, and we will use it for both RWX and RWO. Installing a storage driver requires cluster-wide permissions, so a cluster administrator performs these steps.

  Copy

  STORAGE_NAMESPACE=kube-system
  helm repo add csi-driver-nfs https://raw.githubusercontent.com/kubernetes-csi/csi-driver-nfs/master/charts
  helm install csi-driver-nfs -n ${STORAGE_NAMESPACE} csi-driver-nfs/csi-driver-nfs --version v4.4.0
  kubectl --namespace=${STORAGE_NAMESPACE} get pods --selector="app.kubernetes.io/instance=csi-driver-nfs" --watch
  # Wait until all pods are "Running" and then press CTRL+C

  Create the file storageclass-nfs.yaml to appear as follows:

  (Example for NFS server: 10.192.168.32)

  (Example for NFS path: /mnt/share)

  Copy

  ---
  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: nfs-csi
  provisioner: nfs.csi.k8s.io
  parameters:
    server: <Your NFS server address>
    share: <Your NFS server path>
    # csi.storage.k8s.io/provisioner-secret is only needed for providing mountOptions in DeleteVolume
    # csi.storage.k8s.io/provisioner-secret-name: "mount-options"
    # csi.storage.k8s.io/provisioner-secret-namespace: "default"
  reclaimPolicy: Delete
  volumeBindingMode: Immediate
  mountOptions:
    - nfsvers=4.1

  Use the following command to create the Storage Class nfs-csi:

  Copy

  kubectl apply -f storageclass-nfs.yaml
  
  # See that Storage Class is created:
  kubectl get sc
  NAME      PROVISIONER      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
  nfs-csi   nfs.csi.k8s.io   Delete          Immediate           false                  43s

Installing with Helm

Follow Installing Sisense with Helm on an Existing Cluster (Multinode/Cloud), and add the following values to your values file:

global:
  clusterVisibility: false
  monitoring:
    internal: false

grafana:
  rbac:
    namespaced: true     # or: enabled: false, to not deploy Grafana

# Metrics require the Prometheus Operator CRDs; keep them off
mongodb:
  metrics:
    enabled: false
rabbitmq:
  metrics:
    enabled: false
zookeeper:
  metrics:
    enabled: false

Use cluster mode (global.clusterMode.enabled: true) with your StorageClasses. In single-node mode, the chart creates hostPath PersistentVolumes, which are cluster-scoped objects.

Before you install, preview the installation with --dry-run=server and check that it contains no cluster-scoped RBAC objects:

helm install ${NAMESPACE} sisense-fusion/sisense --version ${SISENSE_SEMVER} \
  -n ${NAMESPACE} -f multinode-values.yaml --dry-run=server > sisense-render.yaml

grep -c '^kind: ClusterRole$' sisense-render.yaml          # expect 0
grep -c '^kind: ClusterRoleBinding$' sisense-render.yaml   # expect 0

Then install Sisense as described on that page.

Installing with sisense.sh

The sisense.sh route runs from a Linux install host. On the machine that runs sisense.sh, use a regular (non-root) Linux user that can run sudo without a password (NOPASSWD) for the duration of the installation. On an existing cloud cluster (EKS, AKS, GKE) or OpenShift, no privileges are required on the Kubernetes worker nodes: the installer does not connect to or run anything on them.

With cluster_visibility: false, sisense.sh:

• Does not label the nodes and does not remove node taints. Label the nodes before the installation (see Label your Kubernetes nodes with the Sisense label. Sisense does not label the nodes in this mode, so you or your cluster administrator must do it. Every node that should run Sisense pods needs the following label, where ${NAMESPACE} is your Sisense namespace:).

• Does not check the pod capacity of the nodes (at least 58 pods per node).

• Does not install storage drivers or StorageClasses. Use your existing StorageClasses.

• Does not install internal monitoring or logging, even if internal_monitoring is true.

• Sets grafana.rbac.namespaced: true in the Sisense Helm values.

1. Download and extract the installer, and open your configuration file:

   Copy

   export SISENSE_VERSION=<YOUR SISENSE VERSION>
   wget https://data.sisense.com/linux/sisense_installer-${SISENSE_VERSION}-DockerHub.tar.gz
   tar -xvf sisense_installer-${SISENSE_VERSION}-DockerHub.tar.gz
   cd sisense-${SISENSE_VERSION}
   vi cloud_config.yaml # or openshift_config.yaml / cluster_config.yaml, according to your cluster

   Use cloud_config.yaml for EKS, AKS, or GKE, openshift_config.yaml for OpenShift, and cluster_config.yaml for an on-premises cluster that already runs Kubernetes.

2. Edit the values as needed. See Installing Sisense on Linux, step 5 ("Deployment"), for information about the various parameters.
   Ensure that these parameters are configured as follows (add the parameters that are not in the file):

   • cluster_visibility: false

   • storage_type: "", rwx_sc_name: "<Your RWX Storage Class name>", and rwo_sc_name: "<Your RWO Storage Class name>". With an empty storage_type, both StorageClass names are required.

   • Only with cluster_config.yaml: update: true (even if it is your first time installing Sisense). This skips the Kubernetes installation on the existing cluster.

Example of the relevant parameters:

## Sisense will use Kubernetes ClusterRole in order to manage the tenant
cluster_visibility: false

## RWX and RWO Access Mode StorageClass names
storage_type: ""
rwx_sc_name: "nfs-csi"
rwo_sc_name: "nfs-csi"

## Name of Namespace
namespace_name: sisense

## Not installed when cluster_visibility is false
internal_monitoring: false

## Only with cluster_config.yaml on an existing cluster
update: true

3. Run the installation:

./sisense.sh <your config file>
# Example: ./sisense.sh cloud_config.yaml

# The installer shows your configuration. If it is correct, type "Y" or "y" and press Enter.

The installer writes its log to the file sisense-installer.log in the directory from which you run sisense.sh.

4. Once the installation is complete, you can activate and log in to your Sisense app.