Installing RKE with a Specified UID

Last updated: October 21, 2026

Tier	Deployment
Enterprise	On-Prem

When installing Sisense, the default installation user ID is 1000. Sometimes, due to security restrictions, it is not possible to use UID 1000. In this case, you need to specify a different UID and use it to install Sisense.

The UID and GID you specify (run_as_user, run_as_group, and fs_group in the sisense.sh configuration file, or securityContext in the Provisioner values) are used as:

The user and group that the Sisense pods run as (runAsUser, runAsGroup, and fsGroup).
The owner of /opt/sisense and its data directories, which the installer creates on the install machine and, for RKE2 deployments, on every server.

Note:

When using a non-default UID, monitoring is not natively supported.
The user must have a name other than sisense.

Preparing the User (RKE2 Only, on Each Server)

For single-node and cluster deployments on RKE2, prepare the user on the install machine and on each server in the cluster before you install Sisense. The installer logs in to each server over SSH as this user (linux_user) and uses sudo to prepare the server and install RKE2.

On an existing cloud cluster (EKS, AKS, GKE) or OpenShift, you need this user only on the machine that runs sisense.sh; the installer does not connect to the cluster nodes, so skip the SSH steps. For the Provisioner, no Linux user is needed (see below).

On each server:

Create the user that you want to use, and generate a password for it. Make sure that the user is on each node with the same UID.
sudo adduser CustomUsername
Add the user to the sudoers file: /etc/sudoers.d/custom-user-permission.
CustomUsername ALL=(ALL:ALL) NOPASSWD: ALL
Connect to the node as the user you created.
sudo su - CustomUsername
Configure the SSH key for the user on all the servers. For details, see https://www.cyberciti.biz/faq/how-to-set-up-ssh-keys-on-linux-unix/.
Run the following command on each of the instances:
ssh-copy-id CustomUsername@instance_node_IP

Setting the UID

For a Provisioner installation

The Provisioner runs the installation as a Kubernetes Job in the cluster. No Linux user, SSH key, or sudo is needed, and you do not need to prepare the servers as described above.

Set the following parameters in the Provisioner values:

securityContext:
- UID
- GID
- fsGroup (a Kubernetes setting) If you do not have something specific you want to use, you can use the user's GID.
monitoring (must be set to false)
- internal

Example:

securityContext:

	runAsUser: 5050

	runAsGroup: 5050

	fsGroup: 5050

monitoring:

	internal: false

Note:

When runAsUser is not 1000, the Provisioner Job mounts the /etc/passwd file of the node it runs on (a hostPath volume). Unless persistence.enabled is true, the Job also mounts /opt/sisense from the node as a hostPath volume. Make sure your cluster's Pod Security settings allow hostPath volumes for the Provisioner.