- Vue d'ensemble (Overview)
- Prérequis
- Installation
- Questions et réponses : modèles de déploiement
- Téléchargement des packages d’installation
- install-uipath.sh parameters
- Activation du module complémentaire Redis High Availability Add-on pour le cluster
- Fichier de configuration de Document Understanding
- Ajout d'un nœud d'agent dédié avec prise en charge GPU
- Connexion de l'application Task Mining
- Ajout d'un nœud d'agent dédié pour Task Mining
- Post-installation
- Administration du cluster
- Surveillance et alerte
- Migration et mise à niveau
- Mode d'évaluation à nœud unique en ligne
- Mode d'évaluation à nœud unique hors ligne
- Mode de production en ligne multi-nœuds compatible haute disponibilité
- Mode de production hors ligne multi-nœuds compatible haute disponibilité
- Migration d'un disque physique Longhorn vers LVM
- Rétrogradation de Ceph de la version 16.2.6 à la version 15.2.9
- Options de migration :
- B) Migration à locataire unique
- Configuration spécifique au produit
- Bonnes pratiques et maintenance
- Résolution des problèmes
- Comment résoudre les problèmes des services lors de l'installation
- Comment désinstaller le cluster
- Comment nettoyer les artefacts hors ligne pour améliorer l'espace disque
- Comment désactiver TLS 1.0 et 1.1
- Comment activer la journalisation Istio
- Comment nettoyer manuellement les journaux
- Comment nettoyer les anciens journaux stockés dans le bundle sf-logs
- Comment déboguer les installations d'Automation Suite ayant échoué
- Comment désactiver le déchargement de la somme de contrôle de la carte réseau
- Impossible d'exécuter une installation hors ligne sur le système d'exploitation RHEL 8.4
- Erreur lors du téléchargement du bundle
- L'installation hors ligne échoue en raison d'un fichier binaire manquant
- Problème de certificat dans l'installation hors ligne
- Erreur de validation de la chaîne de connexion SQL
- Échec après la mise à jour du certificat
- Automation Suite requiert que Backlog_wait_time soit défini sur 1
- Impossible de se connecter après la migration
- Définition d'un délai d'expiration pour les portails de gestion
- Mettre à jour les connexions du répertoire sous-jacent
- Kinit : impossible de trouver le KDC pour le domaine <domaine AD> lors de l’obtention des informations d’identification initiales
- Kinit : Keytab ne contient aucune clé appropriée pour *** lors de l'obtention des informations d'identification initiales
- L'opération GSSAPI a échoué en raison de l'erreur suivante : un code d'état non valide a été fourni (les informations d'identification du client ont été révoquées).
- Échec de la connexion de l'utilisateur <ADDOMAIN><aduser>. Raison : le compte est désactivé.
- Alarme reçue pour l'échec de la tâche Kerberos-tgt-update
- Fournisseur SSPI : serveur introuvable dans la base de données Kerberos
- Impossible d'obtenir l'image du bac à sable
- Les pods ne s'affichent pas dans l'interface utilisateur ArgoCD
- Échec de la sonde Redis
- Le serveur RKE2 ne démarre pas
- Secret introuvable dans l'espace de noms UiPath
- ArgoCD passe à l'état Progression (Progressing) après la première installation
- INCOHÉRENCE INATTENDUE ; EXÉCUTER fsck MANUELLEMENT
- L’opérateur d’auto-guérison et le référentiel Sf-k8-utils manquants
- MongoDB ou applications métier dégradées après la restauration du cluster
- Services défectueux après la restauration ou la restauration du cluster
- Document Understanding n'est pas affiché sur la barre de gauche d'Automation Suite
- État Échec (Failed) lors de la création d'une session de labellisation des données
- État Échec (Failed) lors de la tentative de déploiement d'une compétence ML
- La tâche de migration échoue dans ArgoCD
- La reconnaissance de l'écriture manuscrite avec l'Extracteur de formulaires intelligents (Intelligent Form Extractor) ne fonctionne pas
- Utilisation de l'outil de diagnostic d'Automation Suite
- Utilisation de l'outil Automation Suite Support Bundle
- Explorer les journaux
Présentation 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, valable 3 mois. Vous devez 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é (il peut s'agir du certificat auto-signé ou fourni par le client), qui a expiré dans 90 jours. Si vous souhaitez disposer de votre propre certificat pour la signature du jeton d'identité, vous pouvez le configurer à l'aide des instructions de la section Gestion des certificats.
-
Certificat interne pour MongoDB généré via le gestionnaire de certificats. Les versions 2021.10.3 et antérieures d'Automation Suite fournissent un certificat interne pour MongoDB valable 90 jours. À partir de la version 2021.10.4, Les certificats sont valables 3 ans et sont mis à jour automatiquement.
Pour plus de détails, consultez Mise à jour manuelle du certificat MongoDB pour les utilisateurs d'Apps.
- 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é.
- 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 plus d’informations, 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 sudo ./configureUiPathAS.sh tls-cert update
.
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.
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.
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é.
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
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd cert list --cert-type https
- 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
- Installation en ligne
- Installation hors ligne