- Visão geral
- Requisitos
- Pré-instalação
- Preparação da instalação
- Baixando os pacotes de instalação
- Configuração do registro compatível com OCI
- Concessão de permissões de instalação com funções de cluster
- Concessão de permissões de instalação sem funções de cluster
- Instalação e configuração do service mesh
- Instalando e configurando a ferramenta GitOps
- Instalando o operador de segredos externos
- Implantação do Redis pelo OperatorHub
- Aplicação de configurações diversas
- Executando o uipathctl
- Instalação
- Pós-instalação
- Migração e atualização
- Monitoramento e alertas
- Administração de cluster
- Configuração específica do produto
- Configuração avançada do Orchestrator
- Configuração de parâmetros do Orchestrator
- Configuração do AppSettings
- Configuração do tamanho máximo da solicitação
- Substituição da configuração de armazenamento no nível do cluster
- Configuração do NLog
- Salvando logs do robô no Elasticsearch
- Configuração dos repositórios de credenciais
- Configuração da chave de criptografia por tenant
- Limpeza do banco de dados do Orchestrator
- Ignorar a instalação da biblioteca do host
- AI Trust Layer
- Solução de problemas
- Como desinstalar o Automation Suite
- Como resolver a falha de verificação de conectividade pré-requisito no OpenShift 4.16–4.18
- Como implantar o Insights em um cluster habilitado para FIPS
- Como desabilitar a habilitação automática do CDI no operador de GPU Nvidia
- Como codificar para URL uma senha da string de conexão do PostgreSQL
- 500 erros e limitação de taxa em solicitações do S3 no ODF
- Solução de problemas de segredos externos
- Configurando tolerâncias de driver CSI para ODF 4.20
- Solução de problemas de Temporal como um serviço
- Os pods do AI Center e do Document Understanding falham ao iniciar com a verificação do certificado TLS habilitada
- O Studio Desktop não pode carregar conectores e atividades do Integration Service
- Erros de validação de certificado TLS
- Migreção manual do ArgoCD NetworkPolicy (GHSA-47m3-95c7-g2g8)
- Configuração de solicitações e limites de recursos para cargas de trabalho criadas pelo uipathctl
Requisitos de certificado
Requisitos de certificado TLS e certificado de assinatura de token de identidade para a instalação do Automation Suite no OpenShift.
For details on how to manage certificates post-installation, refer to Managing certificates.
O Automation Suite requer dois certificados no momento da instalação.
-
Certificado TLS - necessário para comunicação TLS entre o cliente e o cluster;
-
Certificado de assinatura do token de identidade — necessário para assinar o token de autenticação.
Importante:O processo de instalação gera certificados autoassinados em seu nome. Recomendamos que você os substitua por certificados assinados por uma Autoridade de Certificação (CA) confiável. Observe que os certificados podem ser gerados no momento da instalação apenas se você conceder ao instalador do Automation Suite privilégios de administrador durante a instalação. Se você não puder conceder os privilégios de administrador do instalador, então você deve criar e gerenciar os certificados por conta própria.
Além dos certificados anteriores, você pode precisar fornecer certificados CA confiáveis adicionais se quiser que o cluster confie em software externo. Exemplo: certificado de CA do SQL Server, certificado de CA do servidor SMTP, certificado de CA de objectstore externo compatível com S3, etc.
No momento da instalação, você deve fornecer certificados de CA para qualquer software externo que requer uma comunicação TLS segura. No entanto, se você não habilitou a comunicação TLS, você pode configurá-la pós-instalação.
For instructions, refer to Managing certificates.
Requisitos de certificado TLS
- O formato do arquivo deve ser
.pem, ou seja, o certificado DER codificado em Base64; - O comprimento da chave privada deve ser de pelo menos 2048;
- Uso estendido de chave: autenticação TLS de servidor da web; necessário para acessar o Automation Suite em dispositivos iOS;
- A chave do certificado deve estar descriptografada. Se a chave estiver criptografada, execute o seguinte comando para descriptografá-la:
# replace /path/to/encrypted/cert/key to absolute file path of key # replace /path/to/decrypt/cert/key to store decrypt key # Once prompted, please entry the passphrase or password to decrypt the key openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key# replace /path/to/encrypted/cert/key to absolute file path of key # replace /path/to/decrypt/cert/key to store decrypt key # Once prompted, please entry the passphrase or password to decrypt the key openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key - Deve ter um nome alternativo de assunto para todas as entradas de DNS necessárias para a instalação do Automation Suite. Se o FQDN para o cluster for
automationsuite.mycompany.com, o certificado SAN deve ter o seguinte DNS:automationsuite.mycompany.com*.automationsuite.mycompany.comObservação:Como alternativa, se o
*curinga for muito genérico, certifique-se de ter entradas SAN para o seguinte DNS:automationsuite.mycompany.cominsights.automationsuite.mycompany.comapps.automationsuite.mycompany.com
Arquivo de certificado TLS
O Automation Suite requer três arquivos no momento de instalação, conforme a seguir:
- Arquivo de certificado TLS - o arquivo de certificado público do servidor. Esse arquivo deve conter a cadeia de certificados do servidor público completa no formato PEM: o certificado do servidor de folha, seguido pelo(s) certificado(s) de CA intermediários e a CA raiz que formam o caminho de assinatura para esse certificado de folha. Inclua apenas certificados que fazem parte da cadeia de assinatura real do certificado de folha - não inclua certificados de CA irmãos, não relacionados, duplicados ou alternativos.
- Arquivo de chave TLS - arquivo de chave privada para o certificado do servidor.
- Pacote de autoridades de certificados - esse é o Certificado público de CA que é usado para assinar ou emitir o certificado TLS. Esse arquivo deve conter a cadeia de certificados completa, incluindo a CA raiz e todos os certificados intermediários. Inclui apenas os certificados usados para assinar o certificado do servidor TLS. Incluir qualquer outra coisa levará à falha.
Starting with Automation Suite 2.2510.2, ca.crt must contain the complete certificate chain used to sign the TLS server certificate, including all intermediate certificates and the root CA. Partial chains are not accepted, and including certificates outside the leaf certificate's actual signing chain - such as sibling, unrelated, duplicate, or alternate CA certificates - will also cause TLS validation to fail. For troubleshooting TLS certificate validation errors, refer to TLS certificate validation errors.
Para verificar o certificado da CA e do TLS, execute o comando a seguir na máquina Linux:
# Please replace /path/to/ca-certificate-bundle and /path/to/server-certificate with actual file path.
openssl verify -CAfile /path/to/ca-certificate-bundle /path/to/server-certificate
# Please replace /path/to/ca-certificate-bundle and /path/to/server-certificate with actual file path.
openssl verify -CAfile /path/to/ca-certificate-bundle /path/to/server-certificate
Se você optar por trazer seu próprio Gerenciador de certificados e seu certificado TLS for emitido por uma CA privada ou não pública, você deve incluir manualmente o certificado de folha e os certificados de CA intermediários no arquivo do certificado TLS. No caso de CAs públicas, elas são automaticamente confiáveis pelos sistemas do cliente, e nenhuma ação adicional é necessária de sua parte.
Certificado de assinatura do token de identidade
O Automation Suite tem os seguintes requisitos em termos de certificados de assinatura do token no momento da instalação:
- O formato do arquivo deve ser
pkcs12para assinar o token de autenticação; - A senha para assinar o certificado é necessária.
Se um certificado de assinatura do token de identidade não for fornecido, o Automation Suite usa os certificados do servidor para gerar um no momento da instalação.