- Overview
- Requirements
- Installation
- Post-installation
- Migration and upgrade
- Upgrading Automation Suite on EKS/AKS
- Step 1: Moving the Identity organization data from standalone to Automation Suite
- Step 2: Restoring the standalone product database
- Step 3: Backing up the platform database in Automation Suite
- Step 4: Merging organizations in Automation Suite
- Step 5: Updating the migrated product connection strings
- Step 6: Migrating standalone Orchestrator
- Step 7: Migrating standalone Insights
- Step 8: Deleting the default tenant
- B) Single tenant migration
- Migrating from Automation Suite on Linux to Automation Suite on EKS/AKS
- Monitoring and alerting
- Cluster administration
- Product-specific configuration
- Troubleshooting
- The backup setup does not work due to a failure to connect to Azure Government
- Pods in the uipath namespace stuck when enabling custom node taints
- Unable to launch Automation Hub and Apps with proxy setup
- Pods cannot communicate with FQDN in a proxy environment
- Test Automation SQL connection string is ignored
Managing the cluster in ArgoCD
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.
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.
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.
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.
Accessing the ArgoCD admin account
To access the ArgoCD admin account using username and password, take the following steps:
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
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
After preparing the RBAC file, you can enable SSO for ArgoCD:
-
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" } } - Apply the configuration by
running the following command:
uipathctl manifest apply input.json --versions versions.json
uipathctl manifest apply input.json --versions versions.json