- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- Audit
- Integrating credential stores
- Managing credential stores
- Cloud robots
- Folders Context
- Automations
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Resource Catalog Service
- Authentication
- Integrations
- Classic Robots
- Troubleshooting
Integrating credential stores
The Central Credential Provider (CCP) is the agentless AAM method used to integrate with CyberArk allowing UiPath® to securely retrieve credentials from a vault without deploying an agent on the server. A client certificate is necessary to ensure secure retrieval of the credential.
Before you can begin to use CyberArk® CCP credential stores in Orchestrator, you must first set up the corresponding application and safe settings in the CyberArk® PVWA (Password Vault Web Access) interface.
- A network that allows for interconnectivity between the Orchestrator service and the CyberArk server.
- CyberArk® Central Credential Provider must be installed on a machine that allows HTTP connections.
- CyberArk® Enterprise Password Vault
For more information about installing and configuring CyberArk® applications, please visit their official page.
Safes are required to help you better manage your accounts. Also, you can add safe members to ensure proper authorization. CyberArk® recommends adding a credential provider (a user with full rights over the credentials can add and manage them) and the previously created application as safe members. The latter enables Orchestrator to find and retrieve the passwords stored in the safe.
CyberArk® Conjur Cloud is a SaaS-based, cloud-agnostic solution for secrets management. It allows organizations to secure non-human access to secrets and eliminate the secret-zero problem. To use the CyberArk® Conjur Cloud credential stores in Orchestrator, you must set up the corresponding safe settings in the CyberArk® Privilege Cloud interface.
-
A network that allows for interconnectivity between the Orchestrator machines and the CyberArk® Cloud server.
-
A CyberArk® Privilege Cloud user with access to create users and safes.
-
A CyberArk® Privilege Cloud user with permissions to the required safes, and the ability to create workloads.
For more information about configuring CyberArk® Cloud applications, visit their official documentation.
Azure Key Vault is a plugin you can use as a credential store with Orchestrator.
There are two plugins included:
- Azure Key Vault – a read-write plugin (secrets are created through Orchestrator)
- Azure Key Vault (read-only) – a read-only plugin (you must provision the secrets in the vault directly)
- Azure Key Vault credential stores use RBAC authentication. Azure Key Vault requires the Key Vault Secrets Officer role, and Azure Key Vault (read-only) requires Key Vault Secrets User role.
In the App Registrations pane of the Azure Portal, follow these steps:
- Create a new app registration.
- Copy the Application (Client) ID for later use.
- Go to Manage > Certificates & Secrets > New client secret, and add a new client secret. Make a note of the expiration you chose and create a new secret before that.
- Copy the Value of the secret for later use.
In the Azure Key Vault, follow these steps:
- Access the Key Vault's Overview page, and copy the Vault URI and Directory ID for later use.
- Select Settings > Access Policies from the menu on the left.
- Click Add access policy.
The required access policy permissions are
Secret Get
andSecret Set
. - From the Configure from template (optional) drop-down menu, select Secret Management.
- Click None selected in the Authorized application section to enable the Select principal field.
- Enter the app registration name, confirm that the Application ID is correct, and select this principal.
- Click Add.
- Click Save.
You are now ready to use Vault URI,Directory ID,Application (Client) ID and the secret's Value to configure a new credential store.
Using Azure Key Vault (read-only)
When using Azure Key Vault (read-only) plugin, the Vault admin is responsible for correctly provisioning the secrets that Orchestrator will use. The format in which these secrets must be provisioned differs between secret types (asset versus robot password) and between secret engines.
For instructions on how to provision the secrets, see the following:
HashiCorp Vault is a plugin you can use as a credential store with Orchestrator.
There are two plugins included:
- HashiCorp Vault – a read-write plugin (secrets are created through Orchestrator)
- HashiCorp Vault (read-only) – a read-only plugin (you must provision the secrets in the vault directly)
-
A network that allows for interconnectivity between the Orchestrator service and the HashiCorp Vault server:
- The API port used by HashiCorp Vault for API requests must be open through any firewall and reachable from the internet. That
port is
8200
in a typical install. - If the customer's firewall does not allow connectivity from any internet IP, Orchestrator's IP addresses must be whitelisted. You can find an up-to-date list of IPs on the Orchestrator outbound IP addresses page.
- The API port used by HashiCorp Vault for API requests must be open through any firewall and reachable from the internet. That
port is
-
You must configure one of the supported authentication methods:
- AppRole (recommended)
- UsernamePassword
- LDAP
- Token
See how to configure authentication.
-
You must configure one of the supported secrets engines:
- KeyValueV1 - available for both HashiCorp Vault and HashiCorp Vault (read-only)
- KeyValueV2 - available for both HashiCorp Vault and HashiCorp Vault (read-only)
- ActiveDirectory - available only for HashiCorp Vault (read-only)
-
OpenLDAP - available only for HashiCorp Vault (read-only)
-
The chosen authentication method must have a policy that allows the following capabilities on the path where you plan to store your secrets:
- For HashiCorp Vault (read-only) plugin:
read
- For HashiCorp Vault plugin:
create
,read
,update
,delete
, and optionallydelete
on the metadata path, if using theKeyValueV2
secrets engine.
- For HashiCorp Vault (read-only) plugin:
The following is an example of how to configure a development version of HashiCorp Vault, running in a docker container, to be used as a credential store with Orchestrator. The examples should be adapted to your own environment. Please consult the official documentation of HashiCorp Vault for details.
Configuring authentication
To start creating and reading secrets, you first need to configure the authentication method by taking the following steps:
Output of this command:
====== Metadata ======
Key Value
--- -----
created_time 2020-10-12T06:24:41.7827631Z
deletion_time n/a
destroyed false
version 1
=========== Data ===========
Key Value
--- -----
supersecretpassword 123456====== Metadata ======
Key Value
--- -----
created_time 2020-10-12T06:24:41.7827631Z
deletion_time n/a
destroyed false
version 1
=========== Data ===========
Key Value
--- -----
supersecretpassword 123456
====== Metadata ======
Key Value
--- -----
created_time 2020-10-12T06:24:41.7827631Z
deletion_time n/a
destroyed false
version 1
=========== Data ===========
Key Value
--- -----
supersecretpassword 123456====== Metadata ======
Key Value
--- -----
created_time 2020-10-12T06:24:41.7827631Z
deletion_time n/a
destroyed false
version 1
=========== Data ===========
Key Value
--- -----
supersecretpassword 123456
You can also enable appRole Orchestrator by running the following command:
/ # vault auth enable approle
/ # vault write auth/approle/role/orchestrator policies=orchestrator-policy
/ # vault read auth/approle/role/orchestrator/role-id
/ # vault write -f auth/approle/role/orchestrator/secret-id
/ # vault auth enable approle
/ # vault write auth/approle/role/orchestrator policies=orchestrator-policy
/ # vault read auth/approle/role/orchestrator/role-id
/ # vault write -f auth/approle/role/orchestrator/secret-id
You will now have a role-id and secret-id for configuring in Orchestrator.
Configuring the Active Directory Secrets Engine
To configure the Active Directory secrets engine, take the following steps:
Using HashiCorp Vault (read-only)
When using HashiCorp Vault (read-only) plugin, the Vault admin is responsible for correctly provisioning the secrets that Orchestrator will use. The format in which these secrets must be provisioned differs between secret types (asset versus robot password) and between secret engines.
For instructions on how to provision the secrets, see the following:
The BeyondTrust integration is read-only and comes in the form of two plugins you can choose from: BeyondTrust Password Safe - Managed Accounts and BeyondTrust Password Safe - Team Passwords.
While BeyondTrust Password Safe - Managed Accounts addresses the needs of organizations with either local or Active Directory accounts, BeyondTrust Password Safe - Team Passwords is suitable in scenarios where the credentials of small groups must be stored in an isolated environment.
The configuration of the two plugins is mostly identical, but there are some slight differences as well. This page covers both plugins.
- A BeyondTrust Server Cloud instance or a similar on-premises installation
- Beyond Insight credentials
BeyondTrust Password Safe - Managed Accounts
If you are using BeyondTrust Password Safe - Managed Accounts, continue with the following steps:
-
Add your Managed Accounts under Managed Systems.
-
Make sure to use API Enabled for your Managed Accounts.
BeyondTrust Password Safe - Team Passwords
If you are using BeyondTrust Password Safe - Team Passwords, continue with the following steps:
-
Go to the Team Passwords page.
-
Optionally create a new Folder.
- Select a Folder.
- Use the Create New Credential option.
Make sure to read through the Delinea documentation for up-to-date information.
- Log in to your Secret Server account.
- Go to Admin > User Management and click Create User. Select the Application Account checkbox to generate an application account.
- Navigate to Admin > See All > Tools and Integrations > SDK Client Management and set up a new onboarding rule in Client Onboarding. Note the onboarding rule name and key.
- Edit the onboarding rule and assign the application account created at step 2.
- Ensure the application account linked to the onboarding rule has permissions to the secrets accessed by Orchestrator. You can assign the application account to a group and grant that group access to the required folders, or grant it explicit access to the secrets.
AWS Secrets Manager is a tool that can be used as a credential store in Orchestrator.
It features two plugins:
- AWS Secrets Manager
- AWS Secrets Manager (read only)
The plugin you can use, namely read-only or read-write, is dictated by your AWS Identity and Access Management (IAM) policy permissions.
If you choose to use the read-only plugin, you must link an asset to a set of credentials that is already available in the AWS Secrets Manager.
To use this service:
- You need to have an AWS subscription.
- You need to create an IAM policy specific to the Secrets Manager, which you assign to the account's IAM role or user.
To integrate AWS Secrets Manager with Orchestrator, you need the access key and the secret key that are generated once you create an AWS IAM account.
- The Access key ID can be found on the Security credentials tab of your AWS IAM account.
-
The Secret key ID is only provided after you create the account. It is therefore important to copy it for future use.
If you misplace of forget your secret key ID, you need to create another access key, then replace the necessary information in Orchestrator.
In addition to that, you need to check the region you set in your AWS account, as this is what you will enter in the Region field while configuring the new credential store.
When using the AWS Secrets Manager (read only) plugin, the administrator is responsible for correctly provisioning the secrets that Orchestrator will use. The format in which these secrets must be provisioned differs between secret types (asset versus robot password) and between secret engines.
For instructions on how to provision the secrets, see the following:
- CyberArk® CCP integration
- Prerequisites
- Creating an Orchestrator application
- Creating an Orchestrator safe
- CyberArk® Conjur Cloud (read-only)
- Prerequisites
- Create an Orchestrator safe for storing credentials
- Create an account and workload to access the credentials
- Azure Key Vault integration
- Prerequisites
- Configuration
- HashiCorp Vault integration
- Prerequisites
- Configuring the integration
- BeyondTrust integration
- Prerequisites
- Configuring the integration
- Thycotic Secret Server integration
- Prerequisites
- Configuring the integration
- AWS Secrets Manager integration
- About AWS Secrets Manager
- Prerequisites
- Configuration
- Using AWS Secrets Manager (read only)