UiPath Documentation
automation-suite
2.2510
true
UiPath logo, featuring letters U and I in white

Automation Suite on EKS/AKS installation guide

Last updated Mar 9, 2026

Managing the cluster in ArgoCD

Overview​

ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes. It is designed as a Kubernetes controller that continuously monitors UiPath® running applications and checks the current state against the desired target state as specified in the docker registry. For more details, see ArgoCD documentation.

Administrators can have an overview of the cluster, configurations, applications status, and health, all via a simple UI or CLI. ArgoCD comes with its own open-source bundled Redis, which supports both HA and non-HA configurations.

Automation Suite uses ArgoCD in the following scenarios:

  • Installing and upgrading the Fabric components and core UiPath® services.
  • Automating the deployment of the desired application states in the specified target environments. ArgoCD follows the GitOps pattern of using Git/helm repositories as the source of truth for defining the desired application state.
  • Keeping track of the installation state. If the installation failed at a specific point and you resume it after a while, ArgoCD skips all the steps that are already synced and resumes from the point where it failed.
  • Self-healing the applications. If you mistakenly delete any of the objects, the manifests will automatically get synced.

ArgoCD read-only scenarios​

You can use the ArgoCD account in the following read only scenarios:

  • Visualizing all your apps, pods, and services in a simple interface
  • Monitoring the health of all your apps, pods, and services
  • Quickly identifying issues in your deployment
  • Resyncing your application in your cluster

ArgoCD advanced scenarios​

Important:

You must not modify any other settings or parameters except for the ones listed in this section.

You can use the ArgoCD admin account in the following advanced scenarios:

  • Changing parameters for debugging purposes only; for instance, disabling self-healing;
  • Deleting pods;
  • Troubleshooting;
  • Managing Orchestrator custom configuration; for instance, setting up encryption key per tenant;
  • Updating the database connection strings;
  • Syncing applications.
    Note:

    Make sure to refer to the proper UiPath® documentation before deleting or changing the advanced configuration on the UI.

Accessing ArgoCD​

ArgoCD supports two authentication methods:

  • username and password - default authentication method;
  • SSO - recommended authentication method. You can enable SSO authentication post-installation. For instructions, see Enabling SSO for ArgoCD.

Username and password authentication​

Accessing the ArgoCD admin account​

To access the ArgoCD admin account using username and password, take the following steps:

  1. Access the following URL: https://alm.${CONFIG_CLUSTER_FQDN}.

  2. Enter the following username: admin.

  3. Access the password:

    kubectl get secret -n argocd argocd-initial-admin-secret -o jsonpath='{.data.password}'  | base64 -d
kubectl get secret -n argocd argocd-initial-admin-secret -o jsonpath='{.data.password}'  | base64 -d

  4. Enter your password.

    Important:

    You must use the ArgoCD admin account only for advanced scenarios. It can cause disruptive action on the cluster if not used with caution.

SSO authentication​

To access ArgoCD using SSO, take the following steps:

  1. Select the SSO button on the ArgoCD login page.
  2. Enter your company domain credentials.

Enabling SSO for ArgoCD​

Overview​

To enable SSO authentication, you must use the uipathctl command-line tool.

Preparing the configuration files​

You must generate the RBAC file before enabling SSO for ArgoCD.

The RBAC file​

The RBAC file contains access rules.

For details on the built-in role definitions, see the ArgoCD documentation.

For details on the ArgoCD account types and their permissions, see Managing the cluster in ArgoCD.

We recommend using these roles when defining your groups, but you can create your own set of permissions.

Configuring the RBAC file​

  1. Create a file named policy.csv by running the following command:

    uipathctl config argocd generate-rbac
uipathctl config argocd generate-rbac

  2. Add the following content to the policy.csv file and save it:

    p, role:uipath-sync, applications, get, */*, allow
p, role:uipath-sync, applications, sync, */*, allow
g, argocdro, role:uipath-sync
p, role:uipath-sync, applications, get, */*, allow
p, role:uipath-sync, applications, sync, */*, allow
g, argocdro, role:uipath-sync

  3. Associate your RBAC groups with the built-in admin role and the UiPath® argocdro read-only role, by appending the following lines to the policy.csv RBAC file:

    g, <your_ldap_readonly_group_name>, role:uipath-sync
g, <your_ldap_admin_group_name>, role:admin
g, <your_ldap_readonly_group_name>, role:uipath-sync
g, <your_ldap_admin_group_name>, role:admin

  4. Save the updated policy.csv RBAC file.

  5. Create a new section named policy.default in the argo-cd-rbac-cm configuration map, after the policy.csv section, as shown in the following example:

    policy.csv: |
    p, role:org-admin, applications, *, /, allow
    p, role:org-admin, clusters, get, *, allow
    p, role:org-admin, repositories, get, *, allow
    p, role:org-admin, repositories, create, *, allow
    p, role:org-admin, repositories, update, *, allow
    p, role:org-admin, repositories, delete, *, allow
    g, "694afc07-6767-8998-bf84-ab80b53379df", role:org-admin # (azure group assigned to role)
  policy.default: role:readonly
policy.csv: |
    p, role:org-admin, applications, *, /, allow
    p, role:org-admin, clusters, get, *, allow
    p, role:org-admin, repositories, get, *, allow
    p, role:org-admin, repositories, create, *, allow
    p, role:org-admin, repositories, update, *, allow
    p, role:org-admin, repositories, delete, *, allow
    g, "694afc07-6767-8998-bf84-ab80b53379df", role:org-admin # (azure group assigned to role)
  policy.default: role:readonly

  6. Follow the instructions in the ArgoCD documentation for configuring SSO with OIDC.

Example:

If your LDAP group for ArgoCD administrators is Administrators and the LDAP group for ArgoCD read-only users is Readers, the RBAC file should be similar to the one in the following example:

p, role:uipath-sync, applications, get, */*, allow
p, role:uipath-sync, applications, sync, */*, allow
g, argocdro, role:uipath-sync
g, Readers, role:uipath-sync
g, Administrators, role:admin
p, role:uipath-sync, applications, get, */*, allow
p, role:uipath-sync, applications, sync, */*, allow
g, argocdro, role:uipath-sync
g, Readers, role:uipath-sync
g, Administrators, role:admin

For more advanced use cases, the following example shows the default RBAC file:

# Built-in policy which defines two roles: role:readonly and role:admin,
# and additionally assigns the admin user to the role:admin role.
# There are two policy formats:
# 1. Applications, logs, and exec (which belong to a project):
# p, <user/group>, <resource>, <action>, <project>/<object>
# 2. All other resources:
# p, <user/group>, <resource>, <action>, <object>

p, role:readonly, applications, get, */*, allow
p, role:readonly, certificates, get, *, allow
p, role:readonly, clusters, get, *, allow
p, role:readonly, repositories, get, *, allow
p, role:readonly, projects, get, *, allow
p, role:readonly, accounts, get, *, allow
p, role:readonly, gpgkeys, get, *, allow
p, role:readonly, logs, get, */*, allow

p, role:admin, applications, create, */*, allow
p, role:admin, applications, update, */*, allow
p, role:admin, applications, delete, */*, allow
p, role:admin, applications, sync, */*, allow
p, role:admin, applications, override, */*, allow
p, role:admin, applications, action/*, */*, allow
p, role:admin, applicationsets, get, */*, allow
p, role:admin, applicationsets, create, */*, allow
p, role:admin, applicationsets, update, */*, allow
p, role:admin, applicationsets, delete, */*, allow
p, role:admin, certificates, create, *, allow
p, role:admin, certificates, update, *, allow
p, role:admin, certificates, delete, *, allow
p, role:admin, clusters, create, *, allow
p, role:admin, clusters, update, *, allow
p, role:admin, clusters, delete, *, allow
p, role:admin, repositories, create, *, allow
p, role:admin, repositories, update, *, allow
p, role:admin, repositories, delete, *, allow
p, role:admin, projects, create, *, allow
p, role:admin, projects, update, *, allow
p, role:admin, projects, delete, *, allow
p, role:admin, accounts, update, *, allow
p, role:admin, gpgkeys, create, *, allow
p, role:admin, gpgkeys, delete, *, allow
p, role:admin, exec, create, */*, allow

g, role:admin, role:readonly
g, admin, role:admin
# Built-in policy which defines two roles: role:readonly and role:admin,
# and additionally assigns the admin user to the role:admin role.
# There are two policy formats:
# 1. Applications, logs, and exec (which belong to a project):
# p, <user/group>, <resource>, <action>, <project>/<object>
# 2. All other resources:
# p, <user/group>, <resource>, <action>, <object>

p, role:readonly, applications, get, */*, allow
p, role:readonly, certificates, get, *, allow
p, role:readonly, clusters, get, *, allow
p, role:readonly, repositories, get, *, allow
p, role:readonly, projects, get, *, allow
p, role:readonly, accounts, get, *, allow
p, role:readonly, gpgkeys, get, *, allow
p, role:readonly, logs, get, */*, allow

p, role:admin, applications, create, */*, allow
p, role:admin, applications, update, */*, allow
p, role:admin, applications, delete, */*, allow
p, role:admin, applications, sync, */*, allow
p, role:admin, applications, override, */*, allow
p, role:admin, applications, action/*, */*, allow
p, role:admin, applicationsets, get, */*, allow
p, role:admin, applicationsets, create, */*, allow
p, role:admin, applicationsets, update, */*, allow
p, role:admin, applicationsets, delete, */*, allow
p, role:admin, certificates, create, *, allow
p, role:admin, certificates, update, *, allow
p, role:admin, certificates, delete, *, allow
p, role:admin, clusters, create, *, allow
p, role:admin, clusters, update, *, allow
p, role:admin, clusters, delete, *, allow
p, role:admin, repositories, create, *, allow
p, role:admin, repositories, update, *, allow
p, role:admin, repositories, delete, *, allow
p, role:admin, projects, create, *, allow
p, role:admin, projects, update, *, allow
p, role:admin, projects, delete, *, allow
p, role:admin, accounts, update, *, allow
p, role:admin, gpgkeys, create, *, allow
p, role:admin, gpgkeys, delete, *, allow
p, role:admin, exec, create, */*, allow

g, role:admin, role:readonly
g, admin, role:admin

Enabling SSO for ArgoCD​

After preparing the RBAC file, you can enable SSO for ArgoCD:

  1. Add the following lines to the input.json file:

    {
"fabric": {
"argocd_rbac_config_file": "/path/to/policy.csv"
  }
}
{
"fabric": {
"argocd_rbac_config_file": "/path/to/policy.csv"
  }
}

  2. To allow the Automation Suite installer to generate the configuration, run the following command.

    uipathctl prereq create input.json --versions versions.json
uipathctl prereq create input.json --versions versions.json

    For more details, refer to Generating configurations automatically.

  3. To check the prerequisites based on the inputs you configured in the input.json, run the following command.

    uipathctl prereq run input.json --versions versions.json
uipathctl prereq run input.json --versions versions.json

    For more details, refer to Checking the prerequisites.

  4. Apply the configuration by running the following command:

    uipathctl manifest apply input.json --versions versions.json
uipathctl manifest apply input.json --versions versions.json

Was this page helpful?

Connect

Need help? Support

Want to learn? UiPath Academy

Have questions? UiPath Forum

Stay updated