- Vue d'ensemble (Overview)
- Prérequis
- Installation
- Post-installation
- Migration et mise à niveau
- Mise à niveau d'Automation Suite sur EKS/AKS
- Étape 1 : Déplacement des données d'organisation Identity d'installation autonome vers Automation Suite
- Étape 2 : Restauration de la base de données du produit autonome
- Étape 3 : Sauvegarder la base de données de la plate-forme dans Automation Suite
- Étape 4 : Fusion des organisations dans Automation Suite
- Étape 5 : Mise à jour des chaînes de connexion du produit migré
- Étape 6 : migration de la version autonome d'Orchestrator
- Étape 7 : Migration d’Insights en version autonome
- Étape 8 : suppression du locataire par défaut
- B) Migration à locataire unique
- Migration d'Automation Suite sur Linux vers Automation Suite sur EKS/AKS
- Surveillance et alerte
- Administration du cluster
- Configuration spécifique au produit
- Configuration des paramètres d'Orchestrator
- Paramètres de l'application Orchestrator
- Configuration des paramètres d'application
- Configuration de la taille maximale de la requête
- Remplacement de la configuration du stockage au niveau du cluster
- Configuration des magasins d'informations d'identification
- Configuration de la clé de chiffrement par locataire
- Nettoyer la base de données Orchestrator
- Rotation des informations d’identification de stockage d’objets blob
- Désactivation de l'utilisation d'URL pré-signées lors du téléchargement de données vers le stockage Amazon S3
- Configuration de la sécurité de l'application de processus
- Configurer une authentification Kerberos avec l’authentification MSSQL de base pour Process Mining
- Résolution des problèmes
- La configuration de sauvegarde ne fonctionne pas en raison d’un échec de connexion à Azure Government
- Pods dans l'espace de noms uipath bloqués lors de l'activation des rejets de nœuds personnalisés
- Impossible de lancer Automation Hub et Apps avec la configuration proxy
- Les pods ne peuvent pas communiquer avec le nom de domaine complet dans un environnement proxy
- La chaîne de connexion SQL de l’automatisation de test est ignorée
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.
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.
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é.
- 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_
. - Istio intercepte l'appel et, en fonction du chemin d'accès de
service_
, transfère l'appel au service spécifique. - Le service appelle Identity Service pour authentifier la demande entrante du robot via
https://automationsuite.mycompany.com/myorg/mytenant/identity_
. - Istio intercepte l'appel et, en fonction du chemin d'accès
identity_
, transfère la demande au service d'identité. - Identity Service renvoie la réponse avec le résultat à Istio.
- 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.
- Le service prépare la réponse et la renvoie à Istio.
-
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.
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é.
- Le Robot établit une connexion avec Orchestrator à l'aide de l'URL suivante :
https://automationsuite.mycompany.com/myorg/mytenant/orchestrator_
- Istio intercepte l'appel et, en fonction du chemin d'accès
orchestrator_
, le transmet au service Orchestrator. - Le service Orchestrator appelle Identity Server pour authentifier la demande entrante du robot via
https://automationsuite.mycompany.com/myorg/mytenant/identity_
. - Istio intercepte l'appel et, en fonction du chemin d'accès
identity_
, transmet la demande au serveur d'identité. - Identity Server renvoie la réponse avec les résultats à Istio.
- 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.
- Orchestrator prépare la réponse et la renvoie à Istio.
-
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.
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.
/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.
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.
/etc/pki/ca-trust/ca/source/anchors
.
/etc/pki/ca-trust/ca/source/anchors
et se termine.
Les certificats seront disponibles pour le service Orchestrator via le volume partagé.
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. Il est recommandé de remplacer le certificat auto-signé par un certificat de domaine après l'installation. Voir Gestion des certificats.
- 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 Gestion des certificats.
- 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 Over SSL) est facultatif. Si vous optez pour LDAPS, vous devez fournir un certificat. Ce certificat sera ajouté aux autorités de certification racines de confiance d'Automation Suite. Pour plus de détails, consultez la documentation Microsoft.
Ce certificat sera ajouté aux autorités de certification racines de confiance d'Automation Suite.
Les certificats sont stockés à deux endroits :
istio-ingressgateway-certs
dansistio-system
uipath
espace de noms
istio-system
et uipath
, vous devez exécuter la commande uipathctl config update-tls-certificates
.
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.
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.
La mise à jour se produit à l'aide de la méthode de déploiement glissant. 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é.
- Comprendre le fonctionnement des certificats de confiance
- Comprendre le fonctionnement de la communication
- Comprendre la façon dont les robots et Orchestrator communiquent
- Comprendre l'architecture de conteneur liée aux certificats
- Au niveau du conteneur
- Au niveau du pod
- Inventaire de tous les certificats dans Automation Suite
- Certificats générés lors de l'installation
- Certificats supplémentaires
- Comprendre le fonctionnement de la mise à jour/de la rotation des certificats