Présentation des certificats

Cette page décrit tous les certificats requis par une installation d'Automation Suite ainsi que le principe du processus de rotation des certificats.

Important :

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

Comprendre le fonctionnement des certificats de confiance

La communication interservices entre les produits au sein d'Automation Suite s'effectue via le nom de domaine complet du cluster. Les produits ne peuvent pas utiliser d'URL internes pour communiquer entre eux. Par exemple, Orchestrator peut se connecter à Identity Server pour l'authentification de l'utilisateur via https://automationsuite.mycompany.com/identity .

Bien que deux produits Automation Suite différents doivent utiliser le nom de domaine complet du cluster, ils peuvent également contenir plusieurs microservices. Ces microservices peuvent utiliser des URL internes pour communiquer entre eux.

Comprendre le fonctionnement de la communication

Le diagramme et le flux suivants expliquent comment le client se connecte à un service et comment l'authentification est effectuée via le service d'identité.

1. Le client établit une connexion avec le service à l'aide de l'URL, c'est-à-dire Orchestrator, Apps, Insights, etc. à l'aide de l'URL suivante : https://automationsuite.mycompany.com/myorg/mytenant/service_ .

2. Istio intercepte l'appel et, en fonction du chemin d'accès de service_ , transfère l'appel au service spécifique.

3. Le service appelle Identity Service pour authentifier la demande entrante du client via https://automationsuite.mycompany.com/myorg/mytenant/identity_.

4. Istio intercepte l'appel et, en fonction du chemin d'accès identity_ , transfère la demande au service d'identité.

5. Identity Service renvoie la réponse avec le résultat à Istio.

6. Istio renvoie la réponse au service. Étant donné que l'appel est effectué à l'aide du protocole HTTPS, Istio renvoie la réponse avec le certificat TLS afin que la connexion soit sécurisée. Si le service approuve le certificat de serveur renvoyé par Istio, il approuve la réponse. Sinon, le service rejette la réponse.

7. Le service prépare la réponse et la renvoie à Istio.

8. Istio renvoie la demande au client. Si la machine cliente fait confiance au certificat, la totalité de la demande aboutit. Sinon, la requête échoue.

   

Comprendre la façon dont les robots et Orchestrator communiquent

Cette section décrit un scénario dans lequel un robot essaie de se connecter à Orchestrator dans Automation Suite. Le diagramme et le flux suivants expliquent comment le Robot se connecte à Orchestrator et comment l'authentification est effectuée via le serveur d'identité.

1. Le Robot établit une connexion avec Orchestrator à l'aide de l'URL suivante : https://automationsuite.mycompany.com/myorg/mytenant/orchestrator_

2. Istio intercepte l'appel et, en fonction du chemin d'accès orchestrator_ , le transmet au service Orchestrator.

3. Le service Orchestrator appelle Identity Server pour authentifier la demande entrante du robot via https://automationsuite.mycompany.com/myorg/mytenant/identity_ .

4. Istio intercepte l'appel et, en fonction du chemin d'accès identity_ , transmet la demande au serveur d'identité.

5. Identity Server renvoie la réponse avec les résultats à Istio.

6. Istio renvoie la réponse à Orchestrator. Étant donné que l'appel est effectué à l'aide du protocole HTTPS, Istio renvoie la réponse avec le certificat TLS, afin que la connexion soit sécurisée. Si Orchestrator approuve le certificat de serveur renvoyé par Istio, il approuve également la réponse. Sinon, Orchestrator rejette la réponse.

7. Orchestrator prépare la réponse et la renvoie à Istio.

8. Istio renvoie la demande au robot. Si la machine robot fait confiance au certificat, la totalité de la requête aboutit. Sinon, la requête échoue.

   

Comprendre l'architecture de conteneur liée aux certificats

Au niveau du conteneur

Dans cet exemple, le conteneur possède son propre système d'exploitation (RHEL OS), et le service peut représenter un Orchestrator s'exécutant sur RHEL OS.

Chaque système d'exploitation possède son propre magasin de certificats. Dans le cas du système d'exploitation RHEL, le magasin approuvé de certificats se trouve dans /etc/pki/ca-trust/ca/.

Ce chemin est l'endroit où RHEL OS stocke tous les certificats. Chaque conteneur aura son propre magasin de confiance de certificats. Dans le cadre de la configuration d'Automation Suite, nous injectons le certificat de chaîne complet qui contient le certificat racine, tous les certificats intermédiaires ainsi que le certificat feuille, et nous les stockons dans ce chemin. Étant donné que les services approuvent les certificats racine et intermédiaire, ils approuvent automatiquement tous les autres certificats créés par les certificats racine et intermédiaire.

Au niveau du pod

Des centaines de conteneurs sont exécutés dans Automation Suite. L'ajout manuel de certificats pour chacun de ces conteneurs pour tous les services serait une tâche exigeante. Cependant, Automation Suite inclut un volume partagé et un cert-trustor de conteneur Init pour vous aider dans cette tâche. Init est un conteneur spécialisé qui s'exécute avant les conteneurs d'applications dans un pod, et son cycle de vie se termine dès qu'il a terminé son travail.

Dans l'exemple suivant, le service Orchestrator s'exécute dans un pod. Pour rappel, un pod peut contenir plusieurs conteneurs. Dans ce pod, nous injectons un autre conteneur Init appelé Cert-trustor . Ce conteneur contiendra le certificat racine, les certificats intermédiaires et le certificat feuille.

Le volume partagé est attaché à la fois au conteneur Cert-Trustor et au conteneur de service Orchestrator. Il a le même chemin que le magasin d'approbation de certificat de système d'exploitation RHEL : /etc/pki/ca-trust/ca/source/anchors.

Avant qu'Orchestrator puisse s'exécuter, Cert-trustor exécute une tâche qui ajoute les certificats dans le volume partagé à l'emplacement /etc/pki/ca-trust/ca/source/anchors et se termine.

Les certificats seront disponibles pour le service Orchestrator via le volume partagé.

Inventaire de tous les certificats dans Automation Suite

Certificats générés lors de l'installation

Dans le cadre de l'installation d'Automation Suite, les certificats suivants sont générés :

• Self-signed certificate generated at the time of installation, which is valid for 3 months. You must 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), which expires in 90 days. If you want to have your own certificate for signing identity tokens, see Managing certificates.
• Les certificats RKE2 sont générés et expirent par défaut dans 12 mois. Si les certificats ont déjà expiré ou s'ils expirent dans moins de 90 jours, ils sont alternés lorsque RKE2 est redémarré.

Certificats supplémentaires

• S'il est activé, le protocole d'authentification SAML2 peut utiliser un certificat de service.
• 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.

Comprendre le fonctionnement de la mise à jour/de la rotation des certificats

Installation en ligne

Les certificats sont stockés à deux endroits :

• istio-ingressgateway-certs dans istio-system
• uipath espace de noms

Pour mettre à jour le certificat dans les espaces de noms istio-system et uipath , vous devez exécuter la commande sudo ./configureUiPathAS.sh tls-cert update .

Les pods ne peuvent accéder qu'aux secrets qui se trouvent dans leur espace de noms. Par exemple, les pods s'exécutant dans l'espace de noms uipath ne peuvent pas accéder aux secrets stockés dans l'espace de noms istio-system . Par conséquent, les certificats sont copiés dans les deux espaces de noms.

Pour l'espace de noms uipath , nous montons les certificats sur les pods qui en ont besoin et redémarrons les pods afin qu'ils puissent utiliser les nouveaux certificats.

Remarque :

Pour les installations d'évaluation à nœud unique, la mise à jour réduira les pods. Tous les pods seront arrêtés et redémarrés. Cette opération entraînera un temps d'arrêt.

Pour les installations de production multi-nœuds compatibles haute disponibilité, la mise à jour s'effectue à l'aide de la méthode de déploiement progressif. Si les microservices ont deux pods à des fins de haute disponibilité, la mise à jour supprimera l'un des pods et une nouvelle version du pod apparaîtra. Une fois le nouveau démarré avec succès, l’ancien sera supprimé. Il y aura une brève période d'arrêt pendant que l'ancien pod n'est pas encore terminé.

Installation hors ligne

En plus des certificats spécifiques à une installation en ligne, un déploiement hors ligne comporte deux emplacements supplémentaires où rootCA.crt et tls.crt sont utilisés. Les certificats sont utilisés dans ArgoCD et le registre Docker, puis ils sont stockés dans les espaces de noms Docker et ArgoCD.

Vous pouvez vérifier les secrets à l'aide de la commande suivante :

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