Privileges and Permissions for Self-Deployment

Last updated: October 21, 2026

Tier Deployment
Enterprise On-Prem

This page describes which privileges each Sisense self-deployment method needs, and on which machine. It covers Linux privileges on the machine that runs the installation and on the Kubernetes nodes, the Kubernetes RBAC that the installing identity needs, the RBAC objects that the Sisense Helm chart creates, and how Sisense works with Pod Security Standards.

To compare the installation methods, see Choosing an Installation Method.

Host Privileges by Installation Method

The install machine is the computer where you run the installation command. The Kubernetes nodes are the servers that run the Sisense pods.

Installation Method Install Machine Kubernetes Nodes SSH to Nodes Kubernetes Identity
Helm Any computer with kubectl and helm. No Linux user, SSH key, or sudo. No privileges No cluster-admin, or the namespace-scoped permissions described below
Provisioner Any computer with kubectl and helm. No Linux user, SSH key, or sudo. No privileges. The installer runs in a pod. No cluster-admin. The installation Job's ServiceAccount is bound to cluster-admin.
sisense.sh on EKS, AKS, or GKE (cloud_config.yaml) or OpenShift (openshift_config.yaml) Linux. A regular (non-root) user that can run sudo without a password (NOPASSWD) for the duration of the installation. You can remove the NOPASSWD rule afterwards. No privileges. The installer does not connect to or run anything on the nodes. No cluster-admin through the user's kubeconfig (or oc login on OpenShift)
sisense.sh on multiple Linux servers (cluster_config.yaml) Linux. A regular (non-root) user with passwordless sudo. The same user with passwordless sudo on every server. The installer prepares the operating system and installs RKE2 on each server. Yes, as the configured Linux user Created by the installer
sisense.sh on a single Linux server (single_config.yaml) Linux. A regular (non-root) user with passwordless sudo. The install machine is also the Kubernetes node. Same machine Yes, to the same machine Created by the installer

In summary:

  • On a cloud-managed cluster (EKS, AKS, GKE) or OpenShift, no installation method needs privileges on the Kubernetes nodes.

  • The Helm and Provisioner methods need no Linux user or sudo anywhere. They need a Kubernetes identity, not a Linux one.

  • The only sudo that sisense.sh needs on a cloud-managed cluster or OpenShift is on the install machine.

Why sisense.sh Needs sudo on the Install Machine

With every configuration file, sisense.sh runs these steps on the install machine as the configured Linux user:

  • Installs the operating-system packages the installer uses, such as python3, jq, pssh, and sshpass.

  • Creates the /opt/sisense directory and sets its owner.

  • Copies kubectl, helm, and helmfile to /usr/local/bin.

At startup, the installer checks sudo with a short timeout, so sudo must not prompt for a password. If the check fails, the installer stops with this message:

Copy 
User <linux_user> has insufficient sudo permissions
sudo configuration should include NOPASSWD for the installation and can be removed at the end of the installation.

To fix it, add a NOPASSWD rule for the installation user (for example, with sudo visudo), run the installation, and remove the rule when the installation is complete.

Example: 

<linux_user> ALL=(ALL) NOPASSWD: ALL

Kubernetes RBAC for the Installing Identity

The installing identity is the Kubernetes user or ServiceAccount whose credentials run helm or sisense.sh.

Method Permissions at Installation and Upgrade Why
Helm (default, global.clusterVisibility: true) cluster-admin The chart creates ClusterRoles and ClusterRoleBindings (see What the Sisense Helm Chart Creates) and reads cluster-scoped objects while it renders.
Helm, namespace-scoped (global.clusterVisibility: false)

  • Full administrative rights in the target namespace.

  • list on nodes (cluster-wide).

  • get on namespaces (cluster-wide).

  • If a namespace named monitoring exists: rights to create a Role and a RoleBinding in it.

The chart creates Roles and RoleBindings in the namespace. Kubernetes lets an identity grant only permissions it already holds.

While rendering, the chart lists the cluster's nodes and checks whether a monitoring namespace exists. If it exists, the chart creates a Role and RoleBinding there for the validator Job.
Provisioner cluster-admin The Provisioner chart binds the installation Job's ServiceAccount to the cluster-admin ClusterRole.
sisense.sh on EKS, AKS, GKE, or OpenShift cluster-admin The installer labels nodes, creates namespaces and StorageClasses, installs storage drivers and other Helm releases, and installs the Sisense chart.
sisense.sh on your own Linux servers None in advance The installer creates the RKE2 cluster and uses its administrator kubeconfig.

Tip: To check whether an identity has enough permissions before you install, run the installation command with --dry-run=server (Helm 3.13 or later). A dry run needs the same permissions as a real installation and creates nothing. If permissions are missing, it fails with a forbidden error.

What the Sisense Helm Chart Creates

Every installation method installs the Sisense Helm chart, so these objects exist with every method unless you change the values described below.

ClusterRoles Controlled by global.clusterVisibility

When global.clusterVisibility is true (the default), the chart creates these ClusterRoles, each with a ClusterRoleBinding to the service's own ServiceAccount. When it is false, none of them is created.

ClusterRole Used By Resources and Verbs
<release>-build-visibility-clusterrole build nodes: get, list, watch, patch
<release>-bsm-executors-visibility-clusterrole bsm-executors (disabled by default) nodes: get, list, watch, patch
<release>-management-visibility-clusterrole management nodes, jobs, cronjobs: get, list, watch, patch, create, update, delete, deletecollection
<release>-oxygen-monitoring-clusterrole oxygen configmaps: get, list, watch, patch; pods: list, delete, deletecollection; secrets named fluentd-kinesis and kinesis-credentials only: get, watch, list, patch
validator-<namespace> validator Job nodes: get, list; services, pods: get, list, delete; persistentvolumes: get, list, watch, patch, delete; Gateway API gateways: get, list

Cluster-Scoped Objects Not Controlled by global.clusterVisibility

  • Grafana: Grafana is deployed by default. Unless grafana.rbac.namespaced is true (the default is false), the Grafana subchart creates the ClusterRole <release>-grafana-clusterrole and a ClusterRoleBinding, which let its dashboard and data source sidecars read configmaps and secrets in all namespaces (get, watch, list). With grafana.rbac.namespaced: true, Grafana uses a Role in the release namespace instead. To skip Grafana entirely, set grafana.enabled: false.

  • PersistentVolumes: In single-node mode (global.clusterMode.enabled: false), the chart creates hostPath PersistentVolumes. With global.storageType: fsx, the chart creates a PersistentVolume for the FSx file system. PersistentVolumes are cluster-scoped.

Namespaced Roles

Each Sisense service has its own ServiceAccount, Role, and RoleBinding in the release namespace. Several services (for example, ae, build, management, and query) can manage pods, jobs, deployments, statefulsets, services, secrets, and PersistentVolumeClaims in that namespace. Sisense ServiceAccounts do not request permissions on StorageClasses or CustomResourceDefinitions.

Namespace-Scoped Installation

When you install with Helm and cannot grant Sisense cluster-wide RBAC, add these values:

Copy 
global:
  clusterVisibility: false   # no ClusterRoles for build, bsm-executors, management, oxygen, validator
grafana:
  rbac:
    namespaced: true         # Grafana uses a Role instead of a ClusterRole (or set grafana.enabled: false)

Also keep these settings at their defaults:

  • mongodb.metrics.enabled, rabbitmq.metrics.enabled, and zookeeper.metrics.enabled: false. When enabled, they create ServiceMonitors, which require the Prometheus Operator CRDs.

  • global.monitoring.internal: false.

With global.clusterVisibility: false, the management, build, bsm-executors, and validator services also receive CLUSTER_VISIBILITY=false and do not access cluster nodes. For what this changes in Sisense, see Installing Sisense without ClusterVisibility.

The installing identity still needs the cluster-wide read access described in Kubernetes RBAC for the Installing Identity.

With sisense.sh, set cluster_visibility: false in the configuration file. The installer then sets grafana.rbac.namespaced: true, and it does not label nodes, install storage drivers, check node pod capacity, or install the monitoring and logging stacks.

Pod Security Standards

This section helps you choose a Pod Security Admission level for the Sisense namespace.

  • Cluster mode (global.clusterMode.enabled: true): Sisense workloads do not use privileged containers, host namespaces (hostNetwork, hostPID, hostIPC), host ports, or hostPath volumes. Use the baseline level.

  • Single-node mode (global.clusterMode.enabled: false): Sisense stores its data in hostPath volumes under /opt/sisense on the node. The baseline level does not allow hostPath volumes, so the namespace needs the privileged level.

Differences from the Restricted Level

With default values, the Sisense chart does not meet the restricted level, for these reasons:

Difference Workloads When
No container-level securityContext is set by default, so the settings that restricted requires (allowPrivilegeEscalation: false, capabilities.drop: [ALL], runAsNonRoot: true, seccompProfile.type: RuntimeDefault) are missing. Sisense service containers and their init containers By default. See global.containerSecurityContext below.
The init-chown-data init container runs as root (UID 0) to set the owner of the data directory. Dgraph (single node), and Dgraph alpha and zero (cluster mode) When initChownData.enabled is true (the default)
The init-chown-data init container runs as root and adds the CHOWN, DAC_OVERRIDE, and FOWNER capabilities. Grafana When Grafana persistence is enabled (the Sisense default) and grafana.initChownData.enabled is true (the default)
The volume-permissions init container runs as root. MongoDB When mongodb.volumePermissions.enabled is true (the Sisense default)

All Sisense pods also set an SELinux level (s0:c123,c456) in global.securityContext. Both baseline and restricted allow this setting.

global.containerSecurityContext is not set by default. When you set it, the chart applies it as the container-level securityContext of most Sisense service containers and their init containers. It does not change the root init containers listed in the table above.

Components Added by the Installer and the Provisioner

  • NGINX Gateway Fabric on your own Linux servers: sisense.sh runs the NGINX data plane as a privileged DaemonSet that binds host ports (80 or 443, and 9113). On EKS, AKS, and GKE it runs as a Deployment behind a LoadBalancer Service.

  • Provisioner Job: Mounts the hostPath /opt/sisense when persistence.enabled is false, and mounts the hostPath /etc/passwd when securityContext.runAsUser is not 1000.

  • Storage drivers: Drivers that the installer installs for you (for example, the AWS EBS, FSx, and NFS CSI drivers, and Rook-Ceph) are third-party components with their own security requirements. They run in their own namespaces.

Recommended Namespace Labels

Mode Labels
Cluster mode (Helm with global.clusterMode.enabled: true, Provisioner with persistence.enabled: true, sisense.sh with a storage_type or rwx_sc_name)

pod-security.kubernetes.io/enforce=baseline

Optionally, add pod-security.kubernetes.io/warn=restricted and pod-security.kubernetes.io/audit=restricted to see the differences listed above without blocking pods.
Single-node mode (hostPath) pod-security.kubernetes.io/enforce=privileged

For example, to label the namespace for cluster mode:

Copy 
kubectl label namespace <namespace> \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted --overwrite

If you use a policy engine (for example, Gatekeeper, Kyverno, or Azure Policy), allow runAsUser: 0 for the init containers listed above. In cluster mode, the Sisense chart does not need hostPath volumes.