Présentation des certificats

Certificats utilisés dans Automation Suite, mécanismes de confiance, architecture de conteneur et processus de rotation sur EKS/AKS.

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 :

Pour plus de détails sur les certificats que vous devez fournir lors du remplacement des certificats auto-signés, consultez les Exigences du certificat.

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

Le diagramme suivant présente l'architecture de certificat 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ù le système d'exploitation RHEL 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 l'ensemble du certificat de chaîne qui contient le certificat racine, tous les certificats intermédiaires, ainsi que le certificat de la feuille, et nous les stockons dans ce chemin.

Étant donné que les services approuvent les certificats racine et intermédiaires, ils approuvent automatiquement tous les autres certificats créés par les certificats racine et intermédiaires.

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.

Comment le conteneur Cert-trustor partage les certificats

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, l'autorité de certification Cert effectue une tâche qui ajoutera 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é.

Le diagramme suivant montre l'architecture de certificat au niveau du pod.

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 :

• Certificat auto-signé généré au moment de l'installation. Nous vous recommandons de remplacer le certificat auto-signé par un certificat de domaine après l'installation. Reportez-vous à la section Gestion des certificats.
  Remarque :

  Le certificat ne peut être généré au moment de l'installation que si vous accordez au programme d'installation d'Automation Suite les privilèges d'administrateur lors de l'installation. Si vous ne pouvez pas accorder les privilèges d'administrateur du programme d'installation, vous devez créer et gérer le certificat vous-même.

• Certificat de serveur d'identité pour la signature des jetons JWT utilisés dans l'authentification. Si le certificat de signature du jeton JWT n'est pas fourni, Automation Suite utilise le certificat TLS actuellement configuré (auto-signé ou fourni par le client). Si vous souhaitez disposer de votre propre certificat pour la signature des jetons d'identité, consultez la section Gérer les certificats.

Certificats supplémentaires

• S'il est activé, le protocole d'authentification SAML2 peut utiliser un certificat de service.
• Si vous configurez Active Directory à l’aide d’un nom d’utilisateur et d’un mot de passe, LDAPS (LDAP sur SSL) est facultatif. Si vous optez pour LDAPS, vous devez fournir un certificat. Ce certificat sera ajouté aux Autorités de certification racine approuvées d’Automation Suite. Pour de plus amples informations, consultez la documentation Microsoft.

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

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

Les pods ne peuvent accéder qu'aux clés secrètes 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 clés secrètes stockées 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 :

La mise à jour se produit à l'aide de la méthode de déploiement. 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 sera proposée. 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é.