Installing Sisense on OpenShift

Last updated: October 21, 2026

Tier	Deployment
Enterprise	On-Prem

You install Sisense on an existing OpenShift cluster by running sisense.sh from a Linux machine that is logged in to the cluster. The installer works only through the Kubernetes API: it does not connect to, or run anything on, your OpenShift nodes.

Tip: Already have a Kubernetes cluster? You can install Sisense with Helm directly, without sisense.sh, a Linux install host, an SSH key, or sudo. See Installing Sisense with Helm on an Existing Cluster (Multinode/Cloud) and Choosing an Installation Method.

Prerequisites

General prerequisites: Checking the Prerequisites and Planning Your Configuration.
Linux OS supported by Sisense. See Minimum Requirements for Sisense in Linux Environments for more information.
Pre-installed OpenShift. You must also be connected to your Kubernetes cluster (i.e., you can do oc commands, such as oc get pod, and others). For more information, see Preparing an OpenShift Environment.
A licensed Red Hat Pull Secret.
Access to your cloud CLI and credentials.
On the machine that runs sisense.sh, a regular (non-root) Linux user that can run sudo without a password (NOPASSWD) for the duration of the installation. You can remove the NOPASSWD rule after the installation. This is needed only on that machine; your OpenShift nodes are not touched. The same user must be logged in to the cluster (oc login) with cluster-admin rights. Sisense itself runs as an ordinary user (UID 1000 by default). For details, see Privileges and Permissions for Self-Deployment.
Each node listed in k8s_nodes must report a pod capacity of at least 58. The installer checks this and stops if a node has a lower capacity (oc get node <node-name> -o jsonpath='{.status.capacity.pods}').

Note:

On OpenShift, the installer does not label nodes and does not install the Sisense internal monitoring and logging stack (Prometheus, Grafana, and the logging components). You label the nodes yourself, as described below.

Create your Sisense project (namespace).

Copy

NAMESPACE_NAME=sisense #for example
oc new-project ${NAMESPACE_NAME} --display-name ${NAMESPACE_NAME}

Create the Role. It will be assigned to the serviceAccount used by the installation. Make sure to name the role sisense and assign it to the relevant namespace.

Note:

This Role grants every action on every resource in the Sisense project. It is not a least-privilege role. The Sisense Helm chart creates its own Roles (and, when cluster_visibility is true, ClusterRoles) for the Sisense service accounts. If your security policy does not allow a wildcard Role, consult Sisense Support before you remove or reduce it.

Create the file role.yaml with the following content:

Copy

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: sisense
  namespace: <NAMESPACE_NAME>
rules:
  - verbs:
      - get
      - list
      - watch
      - create
      - update
      - patch
      - delete
      - use
      - deletecollection
    apiGroups:
      - '*'
    resources:
      - '*'

Save it, and run the command oc apply -f role.yaml.
Create new SecurityContextConstraints (scc) named sisense to allow sisense pods to get the necessary permissions.

The Sisense pods request fixed security settings: they run as UID 1000 with GID and fsGroup 1000 (or the values of run_as_user, run_as_group, and fs_group), and the Sisense Helm chart sets the SELinux level s0:c123,c456 on the pods. The default restricted SCC assigns each project its own UID range and SELinux categories, and rejects pods that request other values. The sisense SCC therefore uses RunAsAny for runAsUser, fsGroup, supplementalGroups, and seLinuxContext. It does not allow privileged containers, privilege escalation, host networking, host ports, or host paths.

Create the file scc.yaml with the following content:

Copy

allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: false
allowPrivilegedContainer: false
allowedCapabilities: null
apiVersion: security.openshift.io/v1
defaultAddCapabilities: null
fsGroup:
  type: RunAsAny
groups: []
kind: SecurityContextConstraints
metadata:
  annotations:
  name: sisense
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities:
- KILL
- MKNOD
- SYS_CHROOT
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
supplementalGroups:
  type: RunAsAny
volumes:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- projected
- secret

Save it, and run the following commands:

Copy

# Create the scc
oc apply -f scc.yaml
securitycontextconstraints.security.openshift.io/sisense created

# Attach sisense scc to all service accounts on your namespace 
oc adm policy add-scc-to-group sisense system:serviceaccounts:${NAMESPACE_NAME}

Manually label your Kubernetes nodes. The installer does not label nodes on OpenShift. The Sisense Helm chart schedules its pods only on nodes that carry the label node-${NAMESPACE}-Application=true, so every node that should run the Sisense platform pods must have this label. The label key includes the namespace and is case-sensitive, and the value is the string true. Also add the role labels that match the roles you assign to each node in k8s_nodes:

node-${NAMESPACE}-Application=true
node-${NAMESPACE}-Query=true
node-${NAMESPACE}-Build=true

And remove node taint node-role.kubernetes.io/master:NoSchedule from all nodes.

For example:

Copy

oc label node ${your_node_1} node-${NAMESPACE}-Application=true --overwrite=true
oc label node ${your_node_1} node-${NAMESPACE}-Query=true --overwrite=true
oc label node ${your_node_2} node-${NAMESPACE}-Application=true --overwrite=true
oc label node ${your_node_2} node-${NAMESPACE}-Query=true --overwrite=true
oc label node ${your_node_3} node-${NAMESPACE}-Build=true --overwrite=true

oc taint nodes --all node-role.kubernetes.io/master:NoSchedule-

Note:

If you are using a cloud managed OpenShift, you may not be able to use the oc label node command, and you will have to modify the node labels via the Cloud/OpenShift provider’s UI or CLI command.
Labels applied with oc label node are lost when a node is replaced. If your cluster replaces or adds nodes automatically, apply the labels in the machine set or node pool definition.
If you have more than three nodes not including master, you do not need to remove the last taint (i.e., there is no need to run the last command above).

Ensure the maximum number of open file descriptors (ulimit -n) is set to a minimum of 65535 (both soft and hard limits) across all Sisense nodes:

Copy

for node in $(oc get node --no-headers | awk '{print $1}'); do
    echo "--------------------------------"
    echo "Validating node ${node}"
    oc debug node/${node} -- chroot /host /bin/bash -c "ulimit -n"
done

# Output example
--------------------------------
Validating node node1
Temporary namespace openshift-debug-lvn8s is created for debugging node...
Starting pod/node1-debug-lhtj7 ...
To use host binaries, run `chroot /host`. Instead, if you need to access host namespaces, run `nsenter -a -t 1`.
65535

Removing debug pod ...
Temporary namespace openshift-debug-lvn8s was removed.
--------------------------------
Validating node node2
Temporary namespace openshift-debug-hxf8n is created for debugging node...
Starting pod/node2-debug-dmvtl ...
To use host binaries, run `chroot /host`. Instead, if you need to access host namespaces, run `nsenter -a -t 1`.
65535

Removing debug pod ...
Temporary namespace openshift-debug-hxf8n was removed.
--------------------------------
Validating node node3
Temporary namespace openshift-debug-lgf5d is created for debugging node...
Starting pod/node3-debug-s8gbm ...
To use host binaries, run `chroot /host`. Instead, if you need to access host namespaces, run `nsenter -a -t 1`.
65535

Install your own Storage Classes (or you can use the same Storage Class for both RWX and RWO):

One for RWX (Read/Write many, for the Sisense apps themselves)

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

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.

Copy

# Create the serviceAccount that will be used by the nfs-client-provisioner
oc create sa -n ${NAMESPACE_NAME} nfs-client-provisioner

# Grant the permission which allows host mounts and any UID by a pod
oc adm policy add-scc-to-user hostmount-anyuid system:serviceaccount:${NAMESPACE_NAME}:nfs-client-provisioner
oc adm policy add-scc-to-user hostmount-anyuid system:serviceaccount:${NAMESPACE_NAME}:nfs-subdir-external-provisioner

# Attach sisense scc to all service accounts on your namespace 
oc adm policy add-scc-to-group sisense system:serviceaccounts:${NAMESPACE_NAME}

Create the file nfs-values.yaml with the following content:

(Example for NFS server: 10.192.168.32)

(Example for NFS path: /mnt/share)

Copy

nfs:
  server: <Your NFS server address>
  path: <Your NFS server path>
serviceAccount:
  name: nfs-client-provisioner
  create: false

Run the installation command:

Copy

helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner --values nfs-values.yaml

# After a minute or 2 (maybe less) you'll see the new Storage Class (nfs-client) installed:
oc get sc
NAME            PROVISIONER                                     RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
gp2             kubernetes.io/aws-ebs                           Delete          WaitForFirstConsumer   true                   27h
gp2-csi         ebs.csi.aws.com                                 Delete          WaitForFirstConsumer   true                   27h
gp3 (default)   ebs.csi.aws.com                                 Delete          WaitForFirstConsumer   true                   27h
gp3-csi         ebs.csi.aws.com                                 Delete          WaitForFirstConsumer   true                   27h
nfs-client      cluster.local/nfs-subdir-external-provisioner   Delete          Immediate              true                   21h