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:

For details on the certificates you must provide when replacing the self-signed certificates, see Certificate requirements.

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 RHEL 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 RHEL 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:

• Self-signed certificate generated at the time of installation. You are recommended to replace the self-signed certificate with a domain certificate post-installation. See Managing certificates.
• Identity Server certificate for signing JWT tokens used in authentication. If the certificate for signing the JWT token is not provided, Automation Suite uses the currently configured TLS certificate (self-signed or customer-provided). If you want to have your own certificate for signing identity tokens, see Managing certificates.

Certificados adicionais

• Se ativado, o protocolo de autenticação SAML2 pode usar um certificado de serviço.
• If you configure Active Directory using a username and password, LDAPS (LDAP Over SSL) is optional. If you opt for LDAPS, you must provide a certificate. This certificate will be added into Automation Suite’s Trusted Root Certification Authorities. For details, see Microsoft documentation.

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.