Visión general de los certificados

En esta página se describen todos los certificados necesarios para una instalación de Automation Suite, así como el principio del proceso de rotación de certificados.

Importante:

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

Comprender el funcionamiento de los certificados de confianza

La comunicación entre productos dentro de Automation Suite se realiza a través del FQDN del cluster. Los productos no pueden utilizar URL internas para comunicarse entre sí. Por ejemplo, Orchestrator puede conectarse a Identity Server para la autenticación de usuarios a través de https://automationsuite.mycompany.com/identity.

Aunque dos productos diferentes de Automation Suite deben utilizar el FQDN del clúster, también pueden contener varios microservicios. Estos microservicios pueden utilizar URL internas para comunicarse entre sí.

Entender cómo funciona la comunicación

El siguiente diagrama explica cómo el cliente se conecta a un servicio y cómo se realiza la autenticación a través del Identity Service.

1. El cliente establece una conexión con el servicio mediante URL, es decir, Orchestrator, Apps, Insights, etc., utilizando la siguiente URL: https://automationsuite.mycompany.com/myorg/mytenant/service_.

2. Istio intercepta la llamada, y basándose en la ruta de service_, reenvía la llamada al servicio específico.

3. El servicio llama a Identity Server para autenticar la solicitud entrante del robot a través de https://automationsuite.mycompany.com/myorg/mytenant/identity_.

4. Istio intercepta la llamada, y basándose en la ruta identity_, reenvía la petición a Identity Server.

5. Identity Server devuelve la respuesta con el resultado a Istio.

6. Istio devuelve la respuesta al servicio.Como la llamada se realiza mediante el protocolo HTTPS, Istio devuelve la respuesta con el certificado TLS para que la conexión sea segura. Si el servicio confía en el certificado del servidor devuelto por Istio, aprueba la respuesta. De lo contrario, el servicio rechaza la respuesta.

7. El servicio prepara la respuesta y la devuelve a Istio.

8. Istio reenvía la solicitud al cliente.Si la máquina del cliente confía en el certificado, la solicitud completa tiene éxito. De lo contrario, la solicitud fallará.

   

Comprender cómo se comunican los robots y Orchestrator

Esta sección describe un escenario en el que un robot intenta conectarse a Orchestrator en Automation Suite. El siguiente diagrama explica cómo el robot se conecta a Orchestrator y cómo se realiza la autenticación a través del Identity Server.

1. UiPath Robot realiza una conexión con Orchestrator utilizando la siguiente URL: https://automationsuite.mycompany.com/myorg/mytenant/orchestrator_

2. Istio intercepta la llamada, y, según la ruta orchestrator_, la reenvía al servicio Orchestrator

3. El servicio Orchestrator llama a Identity Server para autenticar la solicitud entrante del robot a través de https://automationsuite.mycompany.com/myorg/mytenant/identity_.

4. Istio intercepta la llamada, y basándose en la ruta identity_, reenvía la petición a Identity Server.

5. Identity Server devuelve la respuesta con el resultado a Istio.

6. Istio devuelve la respuesta a Orchestrator. Como la llamada se realiza mediante el protocolo HTTPS, Istio devuelve la respuesta con el certificado TLS para que la conexión sea segura. Si Orchestrator confía en el certificado del servidor devuelto por Istio, también aprueba la respuesta. De lo contrario, Orchestrator rechaza la respuesta.

7. Orchestrator prepara la respuesta y la devuelve a Istio.

8. Istio reenvía la solicitud al robot. Si la máquina del robot confía en el certificado, la solicitud completa tiene éxito. De lo contrario, la solicitud fallará.

   

Comprender la arquitectura de contenedores relacionada con los certificados

Nivel de contenedor

En este ejemplo, el contenedor tiene su propio sistema operativo (RHEL OS), y Service puede representar un Orchestrator que se ejecuta sobre RHEL OS.

Cada sistema operativo tiene su propio almacén de certificados. En el caso de RHEL OS, el almacén de confianza de certificados se encuentra en /etc/pki/ca-trust/ca/.

Esta ruta es donde RHEL OS almacena todos los certificados. Cada contenedor tendrá su propio almacén de confianza de certificados. Como parte de la configuración de Automation Suite, inyectamos el certificado de cadena completo que contiene el certificado raíz, todos los certificados intermedios, así como el certificado de hoja, y los almacenamos en esta ruta. Dado que los servicios confían en los certificados raíz e intermedio, confían automáticamente en cualquier otro certificado creado por los certificados raíz e intermedio.

Nivel de Pod

En Automation Suite se ejecutan cientos de contenedores.Añadir manualmente certificados para cada uno de estos contenedores para todos los servicios sería una tarea exigente. Sin embargo, Automation Suite incluye un volumen compartido y un contenedor Init cert-trustor para ayudar en esta tarea. Init es un contenedor especializado que se ejecuta antes de los contenedores de aplicaciones en un Pod, y su ciclo de vida termina tan pronto como completa su trabajo.

En el siguiente ejemplo, el servicio Orchestrator se ejecuta en un pod. Como recordatorio, un pod puede contener más de un contenedor. En este pod, inyectamos un contenedor Init más llamado Cert-trustor.Este contenedor contendrá el certificado raíz, los certificados intermedios y el certificado hoja.

El volumen compartido se adjunta tanto al contenedor cert-trustor como al contenedor de servicios de Orchestrator. Tiene la misma ruta que el almacén de confianza de certificados RHEL OS: /etc/pki/ca-trust/ca/source/anchors.

Antes de que Orchestrator pueda ejecutarse, Cert-trustor realiza un trabajo que añadirá los certificados en el volumen compartido en la ubicación /etc/pki/ca-trust/ca/source/anchors y finaliza.

Los certificados estarán disponibles para el servicio de Orchestrator a través del volumen compartido.

Inventario de todos los certificados en Automation Suite

Certificados generados durante la instalación

Como parte de la instalación de Automation Suite, se generan los siguientes certificados:

• 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 adicionales

• Si está activado, el protocolo de autenticación SAML2 puedes utilizar un certificado de servicio.
• 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 se añadirá a las Autoridades de Certificación Raíz de Confianza de Automation Suite.

Comprender cómo funciona la actualización/rotación de certificados

Los certificados se almacenan en dos lugares:

• istio-ingressgateway-certs en istio-system
• uipath espacio de nombres

Para actualizar el certificado dentro de los espacios de nombres istio-system y uipath, debe ejecutar el comando uipathctl config update-tls-certificates.

Los pods solo pueden acceder a los secretos en su espacio de nombres. Por ejemplo, los pods que se ejecutan en el espacio de nombres uipath no pueden acceder a los secretos almacenados en el espacio de nombres istio-system. Por lo tanto, los certificados se copian en ambos espacios de nombres.

Para el espacio de nombres uipath, montamos los certificados en los pods que los necesitan y reiniciamos los pods para que puedan utilizar los nuevos certificados.

Nota:

La actualización se realiza mediante el método de implementación continua. Si los microservicios tienen dos pods para fines de alta disponibilidad, la actualización eliminará uno de los pods y aparecerá una nueva versión. Una vez que el nuevo se inicie con éxito, se eliminará el antiguo. Habrá un breve período de inactividad mientras el pod anterior aún no se ha terminado.