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: para obtener más información sobre los certificados que debes proporcionar al sustituir los certificados autofirmados, consulta Requisitos del certificado.

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 SO 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 servicio Orchestrator. Tiene la misma ruta que el almacén de confianza de certificados del SO REHL: /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:

• Certificado autofirmado generado en el momento de la instalación, que es válido por 3 meses. Debe reemplazar el certificado autofirmado por un certificado de dominio después de la instalación. Consulta Gestionar certificados.
• Certificado de Identity Server para firmar los tokens JWT utilizados en la autenticación. Si no se proporciona el certificado para firmar el token JWT, Automation Suite utiliza el certificado TLS configurado actualmente (puede ser el autofirmado o el proporcionado por el cliente), que caduca en 90 días. Si quieres tener tu propio certificado para firmar el token de identidad, puedes configurarlo siguiendo las instrucciones de Gestión de certificados.
• Certificado interno para MongoDB generado a través del administrador de certificados. Automation Suite proporciona un certificado interno para MongoDB que es válido por 3 años. El certificado rotará automáticamente y no se requerirá intervención manual. Para obtener más información, consulta Renovación del certificado de MongoDB.
• Los certificados RKE2 generados caducan de forma predeterminada tras 12 meses. Si los certificados ya han caducado o caducan en menos de 90 días, se rotan al reiniciar RKE2.

Certificados adicionales

• Si está activado, el protocolo de autenticación SAML2 puedes utilizar un certificado de servicio.
• Si configuras Active Directory utilizando un nombre de usuario y una contraseña, LDAPS (LDAP sobre SSL) es opcional. Si opta por LDAPS, debes proporcionar un certificado. Este certificado se añadirá a las Autoridades de Certificación Raíz de Confianza de Automation Suite. Para más detalles, consulta Documentación de Microsoft.

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

Instalación en línea

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 sudo ./configureUiPathAS.sh tls-cert update.

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:

Para las instalaciones de evaluación de un solo nodo, la actualización reducirá los pods. Todos los pods se apagarán y reiniciarán. Esta operación causará tiempo de inactividad.

En el caso de las instalaciones de producción multinodo preparados para HA, 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 del pod. Una vez que el nuevo se inicie con éxito, se eliminará el antiguo. Habrá un breve período de inactividad mientras el antiguo pod no haya sido eliminado.

Instalación sin conexión

Además de los certificados específicos de una instalación en línea, un despliegue fuera de línea tienes dos lugares adicionales donde se utilizan rootCA.crt y tls.crt. Los certificados se utilizan en ArgoCD y Docker Registry, y se almacenan en los espacios de nombres de Docker y ArgoCD.

Puedes verificar los secretos utilizando el siguiente comando :

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