Présentation des certificats

Découvrez comment gérer les certificats requis par Automation Suite et comprendre le processus de rotation 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 :

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 effectue une connexion avec le service à l'aide d'une URL, telle qu'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, valable 3 mois. Vous devez remplacer le certificat auto-signé par un certificat de domaine après l'installation. Reportez-vous à la section 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), qui expire dans 90 jours. Si vous souhaitez disposer de votre propre certificat pour la signature des jetons d'identité, reportez-vous à la section Gérer les certificats.
• 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.
• 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

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 uipathctl config tls-certificates 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 clés secrètes à 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