Visão geral dos certificados

Esta página descreve todos os certificados exigidos por uma instalação do Automation Suite, bem como o princípio do processo de rotação de certificados.

Importante: para obter detalhes sobre os certificados que você deve fornecer ao substituir os certificados autoassinados, consulte Requisitos de certificado.

Entendendo como os certificados de confiança funcionam

A comunicação entre serviços entre produtos dentro do Automation Suite é feita por meio do FQDN do cluster. Os produtos não podem usar URLs internos para se comunicarem. Por exemplo, o Orchestrator pode se conectar ao Identity Server para autenticação de usuário via https://automationsuite.mycompany.com/identity.

Embora dois produtos diferentes do Automation Suite devam usar o FQDN do cluster, eles também podem conter vários microsserviços. Esses microsserviços podem usar URLs internos para se comunicarem.

Entenda como a comunicação funciona

O diagrama e o fluxo a seguir explicam como o cliente se conecta a um serviço e como a autenticação é feita por meio do Serviço de Identidade.

1. O cliente faz uma conexão com o serviço usando o URL, ou seja, Orchestrator, Apps, Insights, etc. usando o seguinte URL: https://automationsuite.mycompany.com/myorg/mytenant/service_.
2. O Istio intercepta a solicitação e, com base no caminho do service_, encaminha a solicitação para o serviço específico.
3. O serviço aciona o Serviço de Identidade para autenticar a solicitação recebida do robô via https://automationsuite.mycompany.com/myorg/mytenant/identity_.
4. O Istio intercepta a solicitação e, com base no caminho identity_, encaminha a solicitação para o Serviço de Identidade.
5. O Serviço de Identidade retorna a resposta com o resultado para o Istio.
6. O Istio retorna a resposta ao serviço. Como a solicitação é feita usando o protocolo HTTPS, o Istio retorna a resposta com o certificado TLS para que a conexão seja segura. Se o serviço confiar no certificado do servidor retornado pelo Istio, ele aprova a resposta. Caso contrário, o serviço rejeita a resposta.
7. O serviço prepara a resposta e a envia de volta ao Istio.

8. O Istio encaminha a solicitação de volta ao cliente. Se a máquina cliente confiar no certificado, toda a solicitação será bem-sucedida. Caso contrário, a solicitação falha.

   
   

   

   
   

Entendendo como os robôs e o Orchestrator se comunicam

Esta seção descreve um cenário em que um robô tenta se conectar ao Orchestrator no Automation Suite. O diagrama e o fluxo a seguir explicam como o robô se conecta ao Orchestrator e como a autenticação é feita por meio do Identity Server.

1. O robô faz uma conexão com o Orchestrator usando o seguinte URL: https://automationsuite.mycompany.com/myorg/mytenant/orchestrator_
2. O Istio intercepta a solicitação e, com base no caminho orchestrator_, encaminha para o serviço do Orchestrator.
3. O serviço do Orchestrator aciona o Identity Server para autenticar a solicitação recebida do robô via https://automationsuite.mycompany.com/myorg/mytenant/identity_.
4. O Istio intercepta a solicitação e, com base no caminho identity_, encaminha a solicitação para o Identity Server.
5. O Identity Server retorna a resposta com os resultados para o Istio.
6. O Istio retorna a resposta ao Orchestrator. Como a solicitação é feita usando o protocolo HTTPS, o Istio retorna a resposta com o certificado TLS, para que a conexão seja segura. Se o Orchestrator confiar no certificado do servidor retornado pelo Istio, ele também aprova a resposta. Caso contrário, o Orchestrator rejeita a resposta.
7. O Orchestrator prepara a resposta e a envia de volta ao Istio.

8. O Istio encaminha a solicitação de volta para o robot. Se a máquina do robô confiar no certificado, toda a solicitação será bem-sucedida. Caso contrário, a solicitação falha.

   
   

   

   
   

Entendendo a arquitetura de contêiner relacionada a certificados

Nível do contêiner

Neste exemplo, o contêiner tem seu próprio sistema operacional (RHEL OS) e o Serviço pode representar um Orchestrator em execução no RHEL OS.

Cada sistema operacional tem seu próprio armazenamento de certificados. No caso do REHL OS, o Armazenamento de certificados confiáveis está localizado em /etc/pki/ca-trust/ca/.

Este caminho é onde o RHEL OS armazena todos os certificados. Cada contêiner terá seu próprio Armazenamento de certificados confiáveis. Como parte da configuração do Automation Suite, injetamos todo o certificado da cadeia que contém o certificado raiz, todos os certificados intermediários, bem como o certificado leaf, e os armazenamos nesse caminho. Como os serviços confiam nos certificados raiz e intermediários, eles confiam automaticamente em quaisquer outros certificados criados pelos certificados raiz e intermediários.

Nível de Pod

Existem centenas de contêineres em execução no Automation Suite. A adição manual de certificados para cada um desses contêineres para todos os serviços seria uma tarefa exigente. No entanto, o Automation Suite inclui um volume compartilhado e um contêiner Init cert-trustor para ajudar nessa tarefa. O Init é um contêiner especializado que é executado antes dos contêineres de aplicativo em um pod e seu ciclo de vida termina assim que ele conclui seu trabalho.

No exemplo a seguir, o serviço Orchestrator está sendo executado em um pod. Como lembrete, um pod pode conter mais de um contêiner. Neste pod, injetamos mais um contêiner Init chamado Cert-trustor. Esse contêiner conterá o certificado raiz, os certificados intermediários e o certificado leaf.

O volume compartilhado é anexado ao contêiner Cert-trustor e ao contêiner de serviço do Orchestrator. Ele tem o mesmo caminho que o Armazenamento de certificados confiáveis do REHL OS: /etc/pki/ca-trust/ca/source/anchors.

Antes que o Orchestrator possa ser executado, o Cert-trustor executa um trabalho que adicionará os certificados no volume compartilhado no local /etc/pki/ca-trust/ca/source/anchors e encerrará.

Os certificados estarão disponíveis para o serviço do Orchestrator por meio do volume compartilhado.

Inventário de todos os certificados no Automation Suite

Certificados gerados durante a instalação

Como parte da instalação do Automation Suite, os seguintes certificados são gerados:

• Certificado autoassinado gerado no momento da instalação. É recomendável substituir o certificado autoassinado por um certificado de domínio pós-instalação. Consulte Gerenciamento de certificados.

• Certificado do Identity Server para assinar tokens JWT usados na autenticação. Se o certificado para assinar o token JWT não for fornecido, o Automation Suite usará o certificado TLS atualmente configurado (autoassinado ou fornecido pelo cliente). Se você deseja ter seu próprio certificado para assinar tokens de identidade, consulte Gerenciamento de certificados.

Certificados adicionais

• Se ativado, o protocolo de autenticação SAML2 pode usar um certificado de serviço.
• Se você configurar o Active Directory usando um nome de usuário e senha, o LDAPS (LDAP sobre SSL) é opcional. Se você optar pelo LDAPS, deverá fornecer um certificado. Este certificado será adicionado às Autoridades de Certificação Raiz Confiáveis do Automation Suite. Para obter mais detalhes, consulte a documentação da Microsoft.

Este certificado será adicionado às Autoridades de Certificação Raiz Confiáveis do Automation Suite.

Entendendo como funciona a atualização/rotação do certificado

Os certificados são armazenados em dois lugares:

• istio-ingressgateway-certs em istio-system
• Namespace uipath

Para atualizar o certificado em istio-system e namespaces uipath, você deve executar o comando uipathctl config update-tls-certificates.

Os pods só podem acessar segredos que estão em seu namespace. Por exemplo, os pods em execução no namespace uipath não podem acessar as senhas armazenadas no namespace istio-system. Portanto, os certificados são copiados em ambos os namespaces.

Para o namespace uipath, montamos os certificados nos pods que precisam de certificados e reiniciamos os pods para que eles possam usar os novos certificados.

Observação:

A atualização ocorre usando o método de implantação contínua. Se os microsserviços tiverem dois pods para fins de alta disponibilidade, a atualização excluirá um dos pods e uma nova versão do pod aparecerá. Assim que o novo for iniciado com sucesso, o antigo será removido. Haverá um breve período de inatividade enquanto o pod antigo ainda não for encerrado.