Integração de repositórios de credenciais

Integração com CyberArk® CCP

O Provedor Central de Credenciais (CCP) é o método AAM sem agente usado para se integrar ao CyberArk permitindo que o UiPath® recupere com segurança credenciais de um cofre sem implantar um agente no servidor. Um certificado de cliente é necessário para garantir a recuperação segura da credencial.

Antes de poder começar a usar os armazenamentos de credenciais do CyberArk® CCP no Orchestrator, primeiramente você deve configurar o aplicativo correspondente e as configurações seguras na interface do PVWA (Password Vault Web Access) do CyberArk®.

Pré-requisitos

• Uma rede que permite a interconectividade entre o serviço do Orchestrator e o servidor do CyberArk.
• O Central Credential Provider do CyberArk® deve ser instalado em uma máquina que permite conexões HTTP.
• CyberArk® Enterprise Password Vault

Para obter mais informações sobre a instalação e configuração de aplicativos do CyberArk®, visite sua página oficial.

Criação de um aplicativo do Orchestrator

1. No PVWA da CyberArk®, faça logon com um usuário com permissões para gerenciar aplicativos (requer Gerenciar autorização de usuários).
2. Na guia Aplicativos, clique em Adicionar aplicativo. A janela Adicionar aplicativo será exibida.
   
   

   

   
   
3. Na janela Adicionar aplicativo, especifique as seguintes informações:
   • Campo Name - Um nome personalizado para o aplicativo, como Orchestrator.
   • Descrição – Uma descrição curta para ajudar a especificar o propósito do novo aplicativo.

   • Local - o caminho do aplicativo dentro da hierarquia do Vault. Se um Local não for especificado, o aplicativo será adicionado no mesmo local do usuário que está criando esse aplicativo.

     
     

     

     
     
4. Clique em Adicionar. O aplicativo é adicionado, e seus detalhes são exibidos na página Detalhes do aplicativo.
5. Marque a caixa de seleção Permitir restrições de autenticação estendida.

   Método de autenticação compatível:

   • Certificados de cliente: o certificado de cliente usado para a autenticação CyberArk deve ter pelo menos 2048 bits
6. Configure o método de autenticação. Por exemplo, na guia Autenticação, clique em Adicionar > Número de série do certificado e adicione o identificador exclusivo do certificado do cliente, usado para autenticar o aplicativo solicitante em relação ao CCP.
   
   

   

   
   

Criação de um cofre do Orchestrator

Os seguros são necessários para ajudar você a gerenciar melhor suas contas. Além disso, você pode adicionar membros seguros para garantir a autorização adequada. O CyberArk® recomenda adicionar um provedor de credenciais (um usuário com direitos totais sobre as credenciais pode adicioná-las e gerenciá-las) e o aplicativo criado anteriormente como membros seguros. Este último permite que o Orchestrator encontre e recupere as senhas armazenadas no seguro.

1. Na guia Políticas, a seção Controle de acesso (seguros), clique em Adicionar seguro. A página Adicionar seguro será exibida.
   
   

   

   
   
2. Preencha os campos Nome do cofre e Descrição.
3. Clique em Salvar. A janela Detalhes do cofre é exibida.
   
   

   

   
   
4. Na seção Membros, clique em Adicionar membros. A janela Adicionar membros do cofre é exibida.
   
   

   

   
   
5. Procure o aplicativo criado anteriormente (etapas 2-6) e selecione as seguintes permissões para ele:
   • Exibir membros do cofre
   • Recuperar contas
   • Listar contas

   • Acesso seguro sem confirmação - Apenas se você estiver usando um ambiente de controle duplo e um PIM-PSM v7.2 ou inferior.

     Se você instalar vários provedores de credenciais para essa integração, é recomendável criar um grupo para eles e adicionar o grupo ao Safe uma vez com a autorização acima.

     
     

     

     
     
6. Clique em Adicionar. Sua integração está concluída e você pode começar a provisionar armazenamentos de credenciais do CyberArk® no Orchestrator. Para obter detalhes sobre como armazenar credenciais de Robots, consulte aqui.

CyberArk® Conjur Cloud (somente leitura)

O CyberArk® Conjur Cloud é uma solução baseada em SaaS e agnóstica de nuvem para gerenciamento de segredos. Permite que as organizações protejam o acesso não humano aos segredos e eliminem o problema do segredo zero. Para usar os armazenamentos de credenciais do CyberArk® Conjur Cloud no Orchestrator, você deve definir as configurações de segurança correspondentes na interface do CyberArk® Privilege Cloud.

Pré-requisitos

• Uma rede que permite a interconectividade entre as máquinas do Orchestrator e o servidor CyberArk® Cloud.

• Um usuário do CyberArk® Privilege Cloud com acesso para criar usuários e cofres.

• Um usuário do CyberArk® Privilege Cloud com permissões para os cofres necessários e a capacidade de criar cargas de trabalho.

Para obter mais informações sobre a configuração de aplicativos do CyberArk® Cloud, acesse sua documentação oficial.

Criar um cofre do Orchestrator para armazenar credenciais

1. No CyberArk® Privilege Cloud, faça login com uma conta com permissões para gerenciar aplicativos (requer autorização para Gerenciar usuários).
2. Ao lado do Portal do Usuário, selecione Início.
3. Em Privilege Cloud, selecione Políticas, depois Cofres e, em seguida, Criar cofre e adicione as seguintes informações:
   1. Na etapa Definir propriedades do cofre, adicione um nome personalizado para o cofre e selecione Avançar.
   2. Na etapa Selecionar membros do cofre, selecione Usuários de componentes do sistema para Origem, pesquise Sincronização do Conjur, selecione o usuário do Conjur Cloud e, em seguida, selecione Avançar.
   3. Na etapa Definir permissões do cofre, selecione Completo para Predefinições de permissões e, em seguida, selecione Criar cofre.
4. O novo cofre agora é visível em Políticas, após selecionar Cofres.

Criar uma conta e carga de trabalho para acessar as credenciais

Para acessar os cofres que você criou no CyberArk®, você também precisa de uma conta no Privilege Cloud e uma carga de trabalho no Conjur Cloud.

1. Em Privilege Cloud, selecione Contas, depois Adicionar conta e, em seguida:
   1. Na etapa Selecionar tipo de sistema, selecione Windows, depois Conta de domínio do Windows e, em seguida, selecione um cofre existente.
   2. Na etapa Definir propriedades da conta, preencha os campos Endereço, Nome de usuário e Senha.
   3. Habilite a opção Personalizar nome da conta, se você quiser adicionar um nome personalizado para a conta.
   Observação: quando um ativo ou UiPath Robot é criado no Orchestrator, ele é vinculado a um segredo existente usando o Nome externo. Certifique-se de que, no Orchestrator, o nome da conta gerada ou personalizada seja definido no campo Nome externo, para ser mapeado com os detalhes da conta do CyberArk®.

   Por exemplo, o formato data/vault/OrchestratorQA/companyname-john.doe/username representa um nome de conta personalizado, enquanto o formato data/vault/OrchestratorQA/Operating System-WinDomain-adress-test (1)/address representa um nome de conta gerado.
2. Depois de criar um cofre e uma conta, acesse o serviço Conjur Cloud, selecione Recursos, depois Criar e, em seguida, Carga de trabalho.
   1. Na etapa Tipo de carga de trabalho, selecione Outras.
   2. Na etapa Detalhes da carga de trabalho, insira um nome personalizado para a carga de trabalho no campo Nome e selecione dados para o campo Local.
   3. Em Autenticação, selecione Chave de API.
   4. Na etapa Acesso aos cofres, selecione o cofre criado anteriormente.

   5. Verifique o resumo de sua configuração e, em seguida, selecione Concluído.

   6. Você pode copiar a chave de API e, em seguida, selecione Concluído.
   Para obter instruções sobre como provisionar os segredos, consulte a seguinte página:

   • Storing Robot credentials in CyberArk

Integração do Azure Key Vault

O Azure Key Vault é um plug-in que pode ser usado como um repositório de credenciais com o Orchestrator.

Há dois plug-ins incluídos:

• Azure Key Vault — um plug-in de leitura/gravação (os segredos são criados por meio do Orchestrator)
• Azure Key Vault (somente leitura) — um plug-in somente leitura (é necessário provisionar os segredos no Vault diretamente)

Pré-requisitos

• Os armazenamentos de credenciais do Azure Key Vault usam autenticação RBAC. O Azure Key Vault requer a função Key Vault Secrets Officer, e o Azure Key Vault (somente leitura) requer a função de usuário Key Vault Secrets.

Configuração

No painel Registros de aplicativos do Portal do Azure, siga estas etapas:

1. Crie um novo registro do aplicativo.
2. Copie o ID do aplicativo (cliente) para uso posterior.
3. Acesse Gerenciar > Certificados e segredos > Novo segredo do cliente, e adicione um novo segredo do cliente. Anote a data de expiração escolhida e crie um novo segredo antes disso.
4. Copie o Valor do segredo para uso posterior.

No Azure Key Vault, siga estas etapas:

1. Acesse a página Visão geral do Key Vault, e copie o URI do Vault e o ID do diretório para uso posterior.
2. Selecione Configurações > Políticas de acesso no menu à esquerda.
3. Clique em Adicionar política de acesso.
   As permissões de política de acesso necessárias são Secret Get e Secret Set.
4. No menu suspenso Configurar a partir do modelo (opcional), selecione Gerenciamento de segredo.
5. Clique em Nenhum selecionado na seção Aplicativo autorizado para habilitar o campo Selecionar principal.
6. Insira o nome do registro do aplicativo, confirm se o ID do aplicativo está correto e selecione esse principal.
7. Clique em Adicionar.
8. Clique em Salvar.

Agora você está pronto para usar o URI do Vault, ID do diretório, ID do aplicativo (cliente) e o Valor do segredo para configurar um novo repositório de credenciais.

Usando Azure Key Vault (somente leitura)

Ao usar o plug-in do Azure Key Vault (somente leitura), o administrador do Vault é responsável por provisionar corretamente os segredos que o Orchestrator usará. O formato no qual esses segredos devem ser provisionados difere entre os tipos de segredo (ativo versus senha de robô) e entre mecanismos de segredo.

Para obter instruções sobre como provisionar os segredos, consulte o seguinte:

• Armazenar credenciais de robô não assistido no Azure Key Vault (somente leitura)
• Armazenando ativos no Azure Key Vault (somente leitura)

Integração com o HashiCorp Vault

O HashiCorp Vault é um plug-in que você pode usar como um repositório de credenciais com o Orchestrator.

Há dois plug-ins incluídos:

• HashiCorp Vault — um plug-in de leitura-gravação (os segredos são criados através do Orchestrator)
• HashiCorp Vault (somente leitura) — um plug-in somente leitura (você deve provisionar os segredos no cofre diretamente)

Pré-requisitos

• Uma rede que permite a interconectividade entre o serviço do Orchestrator e o servidor do HashiCorp Vault:

  • A porta API usada pelo HashiCorp cofre para solicitações de API deve ser aberta por qualquer firewall e acessível pela Internet. A porta é 8200 em uma instalação típica.
  • Se o firewall do cliente não permitir De conectividade a partir de qualquer IP da Internet, os endereços IP do Orchestrator devem ser inseridos na lista de permissão. Você pode encontrar uma lista atualizada de IPs na página Endereços IP de saída do Orchestrator.

• Você deve configurar um dos métodos de autenticação compatíveis:

  • AppRole (recomendado)
  • UsernamePassword
  • LDAP
  • Token

    Consulte como configurar a autenticação.

• Você deve configurar um dos mecanismos de segredos compatíveis:

  • KeyValueV1 - Disponível para HashiCorp Vault e HashiCorp Vault (somente leitura)
  • KeyValueV2 - Disponível para HashiCorp Vault e HashiCorp Vault (somente leitura)
  • ActiveDirectory - Disponível apenas para HashiCorp Vault (somente leitura)

  • OpenLDAP - Disponível apenas para HashiCorp Vault (somente leitura)

• O método de autenticação escolhido deve ter uma política que permita os seguintes recursos no caminho em que você planeja armazenar seus segredos:

  • Para o plug-in HashiCorp Vault (somente leitura): read
  • Para o plug-in HashiCorp Vault: create, read, update, delete e, opcionalmente, delete no caminho de metadados, caso esteja usando o mecanismo de segredos KeyValueV2.

Configuração da integração

A seguir, está um exemplo de como configurar uma versão de desenvolvimento do HashiCorp Vault, em execução num contêiner docker, a ser usado como um repositório de credenciais com o Orchestrator. Os exemplos devem ser adaptados para o seu próprio ambiente. Consulte a documentação oficial do HashiCorp Vault para obter mais detalhes.

Configuração da autenticação

Para começar a configurar e ler segredos, primeiro é necessário configurar o método de autenticação seguindo as seguintes etapas:

1. Abra um shell dentro do contêiner:

   docker exec -it dev-vault sh

2. Faça logon como raiz. Certifique-se de ter o token raiz exibido nos logs para definir uma variável de ambiente com ele, executando o seguinte comando:

   export VAULT_TOKEN=s.hA7RJ5lBqSnKUPd8nrQBaK1f

3. Consulte o status do cofre executando o seguinte comando:

   vault status

4. Adicione um segredo fictício para o Orchestrator no repositório KV:

   vault kv put secret/applications/orchestrator/testSecret supersecretpassword=123456

5. Dê ao Orchestrator acesso ao caminho secret/applications/orchestrator recém-criado. Para isso, primeiro, é necessário criar uma política de leitura e gravação para esse caminho e todos os seus subcaminhos, executando o seguinte comando:

   cat <<EOF | vault policy write orchestrator-policy -
   path "secret/data/applications/orchestrator/*" {
     capabilities = ["create", "read", "update", "delete"]
   }
   path "secret/metadata/applications/orchestrator/*" {
     capabilities = ["delete"]
   }
   EOF

   Observação:

   Ao usar um mecanismo de segredos KeyValueV2, os segredos são gravados e extraídos no caminho <mount>/data/<secret-path>, em vez de <mount>/<secret-path> como no KeyValueV1. Ele não altera nenhum dos comandos de CLI (ou seja, você não especifica os dados no seu caminho).

   No entanto, ele altera as políticas, pois os recursos são aplicados no caminho real. No exemplo anterior, o caminho é secret/data/applications/orchestrator/*, pois estamos trabalhando com um mecanismo de segredos KeyValueV2. Se um KeyValueV1 estivesse sendo usado, o caminho seria secret/applications/orchestrator/*.

   A capacidade de excluir no caminho de metadados é necessária apenas se você quiser garantir que o Orchestrator não deixe para trás chaves de teste ao verificar a conectividade. Se essa capacidade não for concedida, uma chave será criada e deixada para trás ao criar o repositório de credenciais no Orchestrator.

6. Habilite a autenticação usando o método de autenticação userpass e, em seguida, crie um usuário para o Orchestrator e atribua a política criada anteriormente:

   vault auth enable userpass
   vault write auth/userpass/users/orchestrator password=123456 policies=orchestrator-policy

   Observação: o Orchestrator é compatível com vários modos de autenticação. Consulte a documentação do HashiCorp Vault para saber como configurá-los.
7. Confira se você configurou tudo corretamente fazendo logon e tentando ler o segredo criado anteriormente:

   vault login -method=userpass username=orchestrator password=123456

   Saída deste comando:

   WARNING! The VAULT_TOKEN environment variable is set! This takes precedence
   over the value set by this command. To use the value set by this command,
   unset the VAULT_TOKEN environment variable or set it to the token displayed
   below.
   Success! You are now authenticated. The token information displayed below
   is already stored in the token helper. You do NOT need to run "vault login"
   again. Future Vault requests will automatically use this token.
   Key                    Value
   ---                    -----
   token                  s.nwombWQH3gGPDhJumRzxKqgI
   token_accessor         aGJL6Pzc6fRRuP8d8tTjS2Kj
   token_duration         768h
   token_renewable        true
   token_policies         ["default" "orchestrator-policy"]
   identity_policies      []
   policies               ["default" "orchestrator-policy"]
   token_meta_username    orchestratorWARNING! The VAULT_TOKEN environment variable is set! This takes precedence
   over the value set by this command. To use the value set by this command,
   unset the VAULT_TOKEN environment variable or set it to the token displayed
   below.
   Success! You are now authenticated. The token information displayed below
   is already stored in the token helper. You do NOT need to run "vault login"
   again. Future Vault requests will automatically use this token.
   Key                    Value
   ---                    -----
   token                  s.nwombWQH3gGPDhJumRzxKqgI
   token_accessor         aGJL6Pzc6fRRuP8d8tTjS2Kj
   token_duration         768h
   token_renewable        true
   token_policies         ["default" "orchestrator-policy"]
   identity_policies      []
   policies               ["default" "orchestrator-policy"]
   token_meta_username    orchestrator

8. Pegue esse token e use-o em vez do token raiz e, em seguida, tente ler o segredo do teste:

   export VAULT_TOKEN=s.nwombWQH3gGPDhJumRzxKqgI
   vault kv get secret/applications/orchestrator/testSecret

Saída deste comando:

====== 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

Observação:

Você também pode habilitar o appRole do Orchestrator executando o seguinte comando:

/ # 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

Agora, você terá um ID da função e ID do segredo para configurar no Orchestrator.

Configuração do mecanismo de segredos do Active Directory

Para configurar o mecanismo de segredos do Active Directory, siga as seguintes etapas:

1. Habilite o mecanismo de segredos Active Directory executando o seguinte comando:

   vault secrets enable ad

2. Configure as credenciais usadas pelo HashiCorp Vault para se comunicar com o Active Directory para gerar senhas:

   vault write ad/config \
       binddn=$USERNAME \
       bindpass=$PASSWORD \
       url=ldaps://138.91.247.105 \
       userdn='dc=example,dc=com'

3. Configure uma função que mapeie um nome no HashiCorp Vault para uma conta no Active Directory. Quando os aplicativos solicitarem senhas, as configurações de rotação de senha serão gerenciadas por essa função.

   vault write ad/roles/orchestrator service_account_name="[e-mail]"

4. Conceda a orchestrator acesso às suas credenciais em ad/creds/orchestrator usando um método de autenticação, como o AppRole.

   cat <<EOF | vault policy write orchestrator-policy -
   path "ad/creds/orchestrator" {
     capabilities = ["read"]
   }
   EOF

Uso do HashiCorp Vault (somente leitura)

Ao usar o plug-in HashiCorp Vault (somente leitura), o administrador do cofre é responsável por provisionar corretamente os segredos que o Orchestrator usará. O formato no qual esses segredos devem ser provisionados difere entre os tipos de segredo (ativo versus senha de robô) e entre mecanismos de segredo.

Para obter instruções sobre como provisionar os segredos, consulte o seguinte:

Armazenamento de credenciais de robôs não assistidos no HashiCorp Vault (somente leitura)

Armazenamento de ativos no HashiCorp Vault (somente leitura)

Integração com o BeyondTrust

A integração do BeyondTrust é somente leitura e vem na forma de dois plug-ins para escolher: BeyondTrust Password Safe - Managed Accounts e BeyondTrust Password Safe - Team Passwords.

Embora o BeyondTrust Password Safe - Managed Accounts atenda às necessidades de organizações com contas locais e do Active Directory, o BeyondTrust Password Safe - Team Passwords é adequado para os cenários em que as credenciais de grupos pequenos devam ser armazenadas em um ambiente isolado.

A configuração dos dois plug-ins é praticamente idêntica, mas há algumas pequenas diferenças entre elas. Esta página aborda ambos os plug-ins.

Pré-requisitos

• Uma instância do BeyondTrust Server Cloud ou uma instalação local similar
• Credenciais do Beyond Insight

Configuração da integração

1. Faça login na instância do BeyondTrust Server Cloud ou uma instalação local similar usando suas credenciais do Beyond Insights.
2. Crie um Registro de API para o grupo ou contas de serviço da UiPath.
   
   

   

   
   
3. Crie uma Regra de autenticação para permitir conexões de API de entrada da UiPath.
   
   

   

   
   
4. Crie um novo grupo UiPath para as suas contas de serviço da UiPath e adicione as seguintes funcionalidades:
   • Conta protegida por senha

   • Função protegida por senha

     
     

     

     
     
5. Também é necessário atribuir Regras inteligentes:
   • Managed Accounts/Read-Only/Requester são suficientes para solicitações de usuário regulares

   • Para o acesso ISA, a função Assets/ISA é necessária.

     
     

     

     
     
6. Adicione o Registro de API ao grupo.
   
   

   

   
   
7. Crie um Usuário e o atribua ao grupo da UiPath.
   
   

   

   
   
8. As etapas a seguir variam conforme você esteja usando o BeyondTrust Password Safe - Managed Accounts ou BeyondTrust Password Safe - Team Passwords.

BeyondTrust Password Safe - Managed Accounts

Se estiver usando o BeyondTrust Password Safe - Managed Accounts, continue com as seguintes etapas:

1. Adicione suas contas gerenciadas em Sistemas gerenciados.
   

   

   
   

2. Certifique-se de usar Habilitado para API para suas contas gerenciadas.

BeyondTrust Password Safe - Team Passwords

Se estiver usando o BeyondTrust Password Safe - Team Passwords, continue com as seguintes etapas:

1. Acesse a página Team Passwords.
   

   

   
   

2. Opcionalmente, crie uma nova Pasta.

3. Selecione uma Pasta.
4. Use a opção Criar nova credencial.

Integração do Thycotic Secret Server

Observação: a marca Thycotic foi renomeada para Delinea como resultado de uma fusão. Tenha isso em mente ao configurar integrações de armazenamento de credenciais.

Pré-requisitos

• Uma instância em nuvem do Thycotic Secret Server ou instalação local.

Configuração da integração

Importante:

Certifique-se de ler a documentação do Delinea para obter informações atualizadas.

1. Faça login em sua conta do Secret Server.
2. Acesse Admin > Gerenciamento de usuário e clique em Criar usuário. Marque a caixa de seleção Conta do aplicativo para gerar uma conta do aplicativo.
3. Navegue até Administrador > Ver todos > Ferramentas e integrações > Gerenciamento do cliente SDK e configure uma nova regra de integração em Integração do cliente. Anote o nome da regra de integração e a chave.
4. Edite a regra de integração e atribua a Conta de aplicativo criada na Etapa 2.
5. Certifique-se de que a Conta de aplicativo vinculada à regra de integração tenha permissões para os segredos acessados pelo Orchestrator. Você pode atribuir a Conta de aplicativo a um grupo e conceder a esse grupo acesso às pastas necessárias, ou conceder acesso explícito aos segredos.

Integração do AWS Secrets Manager

Sobre o AWS Secrets Manager

O AWS Secrets Manager é uma ferramenta que pode ser usada como um armazenamento de credenciais no Orchestrator.

Ele possui dois plug-ins:

• AWS Secrets Manager
• AWS Secrets Manager (somente leitura)

O plug-in que você pode usar, ou seja, somente leitura ou escrita-leitura, é determinado pelas permissões de política do AWS Identity and Access Management (IAM).

Se você optar por usar o plug-in somente leitura, você deverá vincular um ativo para um conjunto de credenciais que já está disponível no AWS Secrets Manager.

Pré-requisitos

Para usar esse serviço:

• Você precisa ter uma assinatura do AWS.
• Você precisa criar uma política do IAM específica para o Secrets Manager, que você atribuirá à função ou usuário do IAM da conta.

Configuração

Para integrar o AWS Secrets Manager ao Orchestrator, você precisa da chave de acesso e da chave secreta que são geradas após você criar uma Conta do AWS IAM.

• O ID da chave de acesso pode ser encontrado na guia Credenciais de segurança de sua conta do AWS IAM.

• O ID da chave secreta só é fornecido após você criar a conta. Portanto, é importante copiá-lo para uso futuro.

  Se você extraviar ou se esquecer do seu ID da chave secreta, você poderá criar outra chave de acesso e, depois, substituir as informações necessárias no Orchestrator.

Além disso, você precisa verificar a região definida em sua conta da AWS, pois é ela que você inserirá no campo Região ao configurar o novo armazenamento de credenciais.

Como usar o AWS Secrets Manager (somente leitura)

Ao usar o plug-in AWS Secrets Manager (somente leitura), o administrador é responsável por provisionar corretamente os segredos que o Orchestrator usará. O formato no qual esses segredos devem ser provisionados difere entre os tipos de segredo (ativo versus senha de robô) e entre mecanismos de segredo.

Para obter instruções sobre como provisionar os segredos, consulte o seguinte:

• Armazenando credenciais de Unattended Robots no AWS Secrets Manager (somente leitura)
• Armazenando ativos no AWS Secrets Manager (somente leitura)

Google Secret Manager

Google Secret Manager is a plugin you can use as a credential store with Orchestrator.

Há dois plug-ins incluídos:

• Google Secret Manager - a read-write plugin that allows you to create and manage secrets directly from Orchestrator.
• Google Secret Manager (read-only) - a read-only plugin that only allows you to consume existing secrets. Secrets must be provisioned directly in Google Secret Manager.

Pré-requisitos

You need a Google Cloud project with a Secret Manager component to connect Orchestrator to Google Secret Manager.

Configure the integration

To connect Orchestrator to Google Secret Manager, proceed with the following steps:

1. Enable the Secret Manager API.

2. Create a service account and generate a service account key.

3. Add a Google Secret Manager credential store in Orchestrator.

Step 1: Enable Secret Manager API

1. Select Select a project to get to the projects list and choose the desired project.
2. In the search bar, search for Secret Manager and open Secret Manger from the results list.
3. Select Enable under Secret Manager API.

Step 2: Create a service account and generate a service account key

1. In the search bar, search for Service Accounts and open Service Accounts from the results list.
2. Select Create service account.
   1. Type a name for the new service account and select Create and continue.
   2. In the Permissions (optional) step, assign the Secret Manager Admin role to the new service account.
   3. Select Continue and then Done.
3. From the service accounts list, select the new account.
4. Navigate to the Keys tab.
5. Select Add key and choose Create new key.
   1. Choose JSON.
   2. Selecione Criar.
   At the end of this step, a JSON file is downloaded. Save this file as you will need it when configuring the Credential Store.

Step 3: Add Google Secret Manager to Orchestrator

1. Navigate to the Tenant page in Orchestrator.
2. Select Credentials and go to the Stores tab.
3. Select Add credentials store.
4. Choose Google Secret Manager from the Type drop-down menu.
5. Type in a name for your Credentials Store.
6. In the Google Cloud Project ID field, type in the Project ID of your Google Cloud project.
7. In the Service Account Key json field, upload the JSON downloaded at the previous step.
8. Selecione Criar.

Importante:

• When retrieving an asset from a Google Secret Manager credential store (read-write or read-only), the latest secret version will always be retrieved. Ensure that the latest version is the correct one.
• If the latest secret version is disabled, retrieval will fail. Ensure that the latest secret version is enabled.

Using Google Secret Manager

When creating assets in a read-write credential store, asset names must only contain English characters (A-Z, a-z), numbers (0-9), dashes (-), and underscores (_).

Invalid characters are automatically replaced with _.

Using Google Secret Manager (read-only)

Storing assets in a read-only credential store

When storing an asset of type Credential in a Google Secret Manager (read only) credential store, you must create the secret in Secret Manager with:

• The name of the secret must match the External Name configured for the value (if using values per robot) or the asset name otherwise.

• Google Secret Manager can only contain letters (A-Z, a-z), numbers (0-9), dashes (-), and underscores (_).
• The secret value must be saved as a Secret Version with the following JSON structure:

  {"Username": "user", "Password": "pass"}

Storing unattended robot passwords

When storing an unattended robot password in a Google Secret Manager (read only) credential store, you must create the secret in Secret Manager with:

• The secret name must match the External Name for that robot.

• If no External Name is configured, the Username field is used instead, with invalid characters replaced by _.

• The secret value must contain only the password for the robot.