Visão geral dos certificados

Saiba como gerenciar os certificados exigidos pelo Automation Suite e entenda o processo de rotação de 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, como 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 cliente 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

O diagrama a seguir mostra a arquitetura do certificado no 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.

Como o contêiner Cert-trustor compartilha certificados

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.

O diagrama a seguir mostra a arquitetura do certificado de nível de pod.

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, com validade de 3 meses. Você deve 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), que expira em 90 dias. Se você quiser ter seu próprio certificado para assinar tokens de identidade, consulte Gerenciamento de certificados.
• Os certificados RKE2 são gerados e, por padrão, expiram em 12 meses. Se os certificados já tiverem expirado ou expirarem em menos de 90 dias, eles serão rotacionados quando o RKE2 for reiniciado.

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 pelo 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 detalhes, consulte a documentação da Microsoft.

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

Instalação online

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 tls-certificates update.

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:

Para instalações de avaliação de nó único, a atualização reduzirá os pods. Todos os pods serão desligados e reiniciados. Esta operação causará tempo de inatividade.

Para instalações de produção prontas para HA de vários nós, 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.

Instalação offline

Além dos certificados específicos de uma instalação online, uma implantação offline tem dois locais adicionais onde rootCA.crt e tls.crt são usados. Os certificados são usados no ArgoCD e no Docker Registry e são armazenados nos namespaces do Docker e do ArgoCD.

Você pode verificar os segredos usando o seguinte comando:

# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd cert list --cert-type https