Granting installation permissions without cluster roles

Grant the Automation Suite installer namespace-scoped permissions on OpenShift and compensate for missing cluster-scoped roles with pre-created resources.

Important:

This page applies only when your security policy prohibits granting any cluster-scoped permissions (ClusterRole or ClusterRoleBinding) to the Automation Suite installer service account (uipathadmin). If you can grant the cluster-scoped permissions, refer to Granting installation permissions with cluster roles instead.

If you install multiple Automation Suite instances on the same cluster, you must grant permissions for the other namespaces where you install Automation Suite.

This page describes how to grant the Automation Suite installer the permissions it needs without assigning any cluster-scoped permissions.

You keep the uipathadmin service account strictly namespace-scoped: you skip the two cluster-scoped ClusterRole resources and the ClusterRoleBinding used in the standard flow, and you compensate for the missing cluster-scoped reads with a set of pre-created resources and uipathctl flags.

Note:

You must execute the commands referenced in this section from a Linux, Windows, or macOS machine that has access to the OpenShift Kubernetes API server.

Commands that perform admin actions (creating the certificate Secret) must be run by a cluster administrator. Commands that perform uipathadmin actions use the kubeconfig you generate in Step 4.

To grant installation permissions without cluster roles, perform the following steps:

1. Creating a service account
2. Creating the required namespace-scoped roles
3. Binding the roles
4. Generating the kubeconfig file
5. Configuring input.json for restricted-mode operation
6. Pre-creating the TLS certificate Secret
7. Installing and configuring the service mesh and GitOps tool

Step 1: Creating a service account

To create a service account, take the following steps:

1. Create the <uipath> namespace and project:

   oc get namespace <uipath> || oc new-project <uipath>
   

2. Set the default namespace and project to <uipath>:

   oc project <uipath>
   

   All subsequent oc commands will operate within the <uipath> namespace.

3. Create a service account named uipathadmin:

   oc create serviceaccount uipathadmin
   

4. Use the existing admin cluster role to grant admin permissions to the uipathadmin service account in the <uipath> namespace:

   oc create rolebinding uipathadmin --clusterrole=admin --serviceaccount=<uipath>:uipathadmin
   

   Note:

   This is a namespace-scoped RoleBinding that references the built-in admin cluster role. It grants uipathadmin admin permissions only within the <uipath> namespace, not cluster-wide. No ClusterRoleBinding is created.

Step 2: Creating the required namespace-scoped roles

The uipathadmin service account requires certain permissions during the Automation Suite installation. In the no-cluster-roles flow, you provide these permissions through namespace-scoped roles only.

To create each role, save its configuration as a YAML file and run the following command, replacing the <file_name.yaml> placeholder with the actual name of the YAML file:

oc apply -f <file_name.yaml>

You can create the YAML file for each role by copying the configuration from the following sections.

The following namespace-scoped roles are the only roles uipathadmin needs in this flow. The prerequisite checks that would otherwise rely on cluster-scoped reads are excluded and validated out-of-band, as described in Running prerequisite checks without cluster roles.

Installation permissions in the <uipath> namespace

Most of the Automation Suite installation runs through ArgoCD, but some components are installed directly through Helm charts. The uipathctl tool runs an installation job that performs these Helm installations in the <uipath> namespace. To do this, uipathadmin needs a namespace-scoped role that can create and manage roles, role bindings, secrets, and config maps.

The following example shows the uipath-automationsuite-role configuration:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: uipath-automationsuite-role
  namespace: <uipath>
rules:
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["roles", "rolebindings"]
    verbs: ["get", "watch", "list", "patch", "update", "create", "delete"]
  - apiGroups: [""]
    resources: ["secrets", "configmaps"]
    verbs: ["get", "watch", "list", "patch", "update", "create", "delete"]
  - apiGroups: ["security.istio.io", "networking.istio.io"]
    resources: ["*"]
    verbs: ["get", "watch", "list", "patch", "update", "create", "delete"]

Certificate and validation permissions in the <istio-system> namespace

Note:

namespace may not exist in your cluster if you have not installed Istio yet. You can create the namespace and the role before installing Istio, or you can create the role after installing Istio.

The following operations are performed in the <istio-system> namespace:

1. The Automation Suite prerequisite check tool reads the pods and services in the <istio-system> namespace to validate that Istio is installed and configured properly.
2. The get secrets permission is required to copy the certificate file from the <istio-system> namespace to the <uipath> namespace.

Because uipathadmin does not configure Istio or install the WebAssembly (WASM) plugin in the no-cluster-roles flow, you use the read-only variant of this role. A cluster administrator performs those operations instead (refer to Step 7).

The following example shows the istio-system-automationsuite-role configuration:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: istio-system-automationsuite-role
  namespace: <istio-system>
rules:
  - apiGroups: [""]
    resources: ["services", "pods"]
    verbs: ["list"]
  - apiGroups: [""]
    resources: ["secrets"]
    resourceNames: ["istio-ingressgateway-certs"]
    verbs: ["get"]

Step 3: Binding the roles

Bind the namespace-scoped roles that you created in the previous step to the uipathadmin service account by running the following commands:

oc project <istio-system>
oc create rolebinding istio-system-automationsuite-rolebinding \
  --role=istio-system-automationsuite-role --serviceaccount=<uipath>:uipathadmin
oc project <uipath>
oc create rolebinding uipath-automationsuite-rolebinding \
  --role=uipath-automationsuite-role --serviceaccount=<uipath>:uipathadmin

Step 4: Generating the kubeconfig file

After you assign all the permissions to the service account, you must create a kubeconfig file to pass to the uipathctl tool for the installation.

Generating the kubeconfig file on Linux or Mac

To generate the kubeconfig file on Linux or Mac, run the following commands:

# For generating kubeconfig
# Creates the token for uipathadmin service account
token=$(oc -n <uipath> create token uipathadmin --duration=8760h)
# Getting api-server details
server=$(oc config view -o jsonpath="{.clusters[]..server}")
# Login logs on using the provided token and server and outputs kubeconfig at the provided path.
oc login --server=$server --token=$token --kubeconfig=uipathadminkubeconfig --insecure-skip-tls-verify=true

If the operation was successful, you should see a kubeconfig file named uipathadminkubeconfig.

Generating the kubeconfig file on Windows

Note:

You must perform this step using Windows Powershell.

To generate the kubeconfig file on Windows, run the following commands:

# For generating kubeconfig
# Creates the token for uipathadmin service account
$token = oc -n <uipath> create token uipathadmin --duration=8760h
# Getting api-server details
$server = oc config view -o jsonpath="{.clusters[]..server}"
# Login logs on using the provided token and server and outputs kubeconfig at the provided path.
oc login --server=$server --token=$token --kubeconfig=uipathadminkubeconfig --insecure-skip-tls-verify=true

If the operation was successful, you should see a kubeconfig file named uipathadminkubeconfig.

Step 5: Configuring input.json for restricted-mode operation

In the no-cluster-roles flow, you must add a few keys to your input.json so that uipathctl and the UiPath service charts avoid operations that require cluster-scoped reads or resources. The following sections explain each key.

5.1 Priority classes

Set ignore_priority_class to true:

{
  "ignore_priority_class": true
}

This setting does the following:

• It tells uipathctl to skip its own priorityclasses.scheduling.k8s.io lookup, which would otherwise require a cluster-scoped read.
• It propagates to all UiPath service charts, which then omit priorityClassName from their workloads.

As a result, no Automation Suite pod references a PriorityClass, so no PriorityClass needs to exist on the cluster and none has to be pre-created.

5.2 Certificates and ingress

Add the certificate and ingress keys. For details on the certificate-related keys, refer to Certificate requirements.

{
  "server_certificate": {
    "tls_cert_file": "<path-to-tls.crt>",
    "tls_key_file":  "<path-to-tls.key>",
    "ca_cert_file":  "<path-to-ca.crt>"
  },

  "ingress": {
    "namespace": "<istio-system>",
    "gateway_selector": { "istio": "ingressgateway" },
    "ingress_gateway_secret": "istio-ingressgateway-certs"
  },

  "additional_ca_certs": "<path-to-ca.crt>"
}

The additional_ca_certs key is required only when your TLS certificate is signed by a private or self-signed Certificate Authority. It propagates the CA bundle to the trust store of all Automation Suite pods.

5.3 AS Robots concurrency limit

Important:

This step is required only if you enable AS Robots (asrobots).

If you enable AS Robots, set an explicit concurrency_limit:

{
  "asrobots": {
    "enabled": true,
    "concurrency_limit": 2
  }
}

When concurrency_limit is not set, the AS Robots chart deploys a ClusterRole and ClusterRoleBinding to automatically read node capacity and compute robot concurrency. A namespaced ArgoCD instance cannot manage these cluster-scoped resources, so the asrobots application fails to synchronize:

ComparisonError: cluster level ClusterRoleBinding "<uipath>-asrobots-robot-resources-crb" can not be managed when in namespaced mode

With an explicit concurrency_limit, the chart deploys no cluster-scoped resources.

5.4 Bring your own components

Because uipathadmin has no cluster-scoped permissions in this flow, the installer cannot deploy the platform components that create cluster-scoped resources - such as Istio, OPA Gatekeeper, cert-manager, and network policies. You must provision these components yourself and list them in exclude_components so that the installer skips them.

List the components you provide yourself in exclude_components, and set telemetry_optout to true because telemetry cannot be enabled in this flow. For the component list and details, refer to Without cluster roles.

Step 6: Pre-creating the TLS certificate Secret

Because uipathadmin is namespace-scoped only, a cluster administrator must create the istio-ingressgateway-certs Secret in the <istio-system> namespace before installation. This does not grant uipathadmin any extra privilege; it substitutes for the work uipathadmin would have done if it had the cluster-scoped permissions. (No PriorityClass needs to be created - that dependency is removed by ignore_priority_class in Step 5.1.)

The istio-ingressgateway-certs Secret is created as part of configuring the service mesh. To create it, refer to Configuring Istio and installing the WASM plugin for routing.

Because uipathadmin holds only the read-only istio-system-automationsuite-role, it can read this Secret but cannot create it; a cluster administrator must create it.

Ensure the Secret contains all three keys - tls.crt, tls.key, and ca.crt - because the ca.crt key is required when your TLS certificate is signed by a private or self-signed Certificate Authority.

Step 7: Installing and configuring the service mesh and GitOps tool

Follow the standard procedures for the service mesh and GitOps tool. These procedures create additional namespace-scoped roles and bindings for uipathadmin in the <argocd> namespace; none of them require cluster-scoped permissions on uipathadmin.

• Installing and configuring the service mesh - install OpenShift Service Mesh. Because uipathadmin runs with the read-only <istio-system> role, it cannot configure Istio or install the WASM plugin itself; a cluster administrator must set up istio-configure before the Automation Suite installation.
• Installing and configuring the GitOps tool - provision the dedicated ArgoCD instance and complete all steps.

For the istio-configure setup steps, refer to Configuring Istio and installing the WASM plugin for routing.