Übersicht über Zertifikate

Auf dieser Seite werden alle Zertifikate beschrieben, die für eine Installation der Automation Suite erforderlich sind, sowie das Prinzip des Zertifikatrotationsprozesses.

Wichtig: Weitere Informationen zu den Zertifikaten, die Sie beim Ersetzen der selbstsignierten Zertifikate vorlegen müssen, finden Sie unter Zertifikatanforderungen.

Funktionsweise von Vertrauenszertifikaten

Die dienstübergreifende Kommunikation zwischen Produkten innerhalb der Automation Suite erfolgt über den FQDN des Clusters. Produkte können keine internen URLs verwenden, um miteinander zu kommunizieren. Der Orchestrator kann beispielsweise eine Verbindung mit Identity Server zur Benutzerauthentifizierung über https://automationsuite.mycompany.com/identity .

Während zwei verschiedene Automation Suite-Produkte den FQDN des Clusters verwenden müssen, können sie auch mehrere Microservices enthalten. Diese Microservices können interne URLs verwenden, um miteinander zu kommunizieren.

Verstehen, wie Kommunikation funktioniert

Im folgenden Diagramm und Flow wird erläutert, wie der Client eine Verbindung mit einem Dienst herstellt und wie die Authentifizierung über den Identitätsdienst erfolgt.

1. Der Client stellt eine Verbindung mit dem Dienst mithilfe der URL her, z. B. Orchestrator, Apps, Insights usw. mithilfe der folgenden URL: https://automationsuite.mycompany.com/myorg/mytenant/service_ .
2. Istio fängt den Aufruf ab und leitet den Aufruf basierend auf dem Pfad von service_ an den jeweiligen Dienst weiter.
3. Der Dienst ruft Identity Service auf, um die eingehende Anforderung vom Roboter über https://automationsuite.mycompany.com/myorg/mytenant/identity_ zu authentifizieren.
4. Istio fängt den Aufruf ab und leitet die Anforderung basierend auf dem Pfad identity_ an Identity Service weiter.
5. Identity Service gibt die Antwort mit dem Ergebnis an Istio zurück.
6. Istio gibt die Antwort an den Dienst zurück. Da der Aufruf über das HTTPS-Protokoll erfolgt, gibt Istio die Antwort mit dem TLS-Zertifikat zurück, damit die Verbindung sicher ist. Wenn der Dienst dem von Istio zurückgegebenen Serverzertifikat vertraut, genehmigt er die Antwort. Andernfalls lehnt der Dienst die Antwort ab.
7. Der Dienst bereitet die Antwort vor und sendet sie zurück an Istio.

8. Istio leitet die Anforderung zurück an den Client. Wenn die Clientmaschine dem Zertifikat vertraut, ist die gesamte Anforderung erfolgreich. Andernfalls schlägt die Anforderung fehl.

   
   

   

   
   

Verstehen, wie Roboter und Orchestrator kommunizieren

In diesem Abschnitt wird ein Szenario beschrieben, in dem ein Roboter versucht, eine Verbindung mit dem Orchestrator in der Automation Suite herzustellen. Im folgenden Diagramm und Flow wird erläutert, wie der Roboter eine Verbindung mit dem Orchestrator herstellt und wie die Authentifizierung über Identity Server erfolgt.

1. Der Roboter stellt über die folgende URL eine Verbindung mit dem Orchestrator her: https://automationsuite.mycompany.com/myorg/mytenant/orchestrator_
2. Istio fängt den Aufruf ab und leitet ihn basierend auf dem orchestrator_ -Pfad an den Orchestrator-Dienst weiter.
3. Der Orchestrator-Dienst ruft Identity Server auf, um die eingehende Anforderung vom Roboter über https://automationsuite.mycompany.com/myorg/mytenant/identity_ zu authentifizieren.
4. Istio fängt den Aufruf ab und leitet die Anforderung basierend auf dem identity_ -Pfad an Identity Server weiter.
5. Identity Server gibt die Antwort mit den Ergebnissen an Istio zurück.
6. Istio gibt die Antwort an den Orchestrator zurück. Da der Aufruf über das HTTPS-Protokoll erfolgt, gibt Istio die Antwort mit dem TLS-Zertifikat zurück, sodass die Verbindung sicher ist. Wenn der Orchestrator dem von Istio zurückgegebenen Serverzertifikat vertraut, genehmigt er auch die Antwort. Andernfalls lehnt der Orchestrator die Antwort ab.
7. Der Orchestrator bereitet die Antwort vor und sendet sie zurück an Istio.

8. Istio leitet die Anforderung zurück an den Roboter. Wenn die Robotermaschine dem Zertifikat vertraut, ist die gesamte Anforderung erfolgreich. Andernfalls schlägt die Anforderung fehl.

   
   

   

   
   

Grundlegendes zur Containerarchitektur im Zusammenhang mit Zertifikaten

Containerebene

In diesem Beispiel verfügt der Container über ein eigenes Betriebssystem (RHEL OS), und der Dienst kann einen Orchestrator darstellen, der auf RHEL OS ausgeführt wird.

Jedes Betriebssystem hat einen eigenen Zertifikatspeicher. Im Fall von RHEL OS befindet sich der Zertifikatsvertrauenswürdigspeicher in /etc/pki/ca-trust/ca/.

In diesem Pfad speichert RHEL OS alle Zertifikate. Jeder Container verfügt über einen eigenen Trust Store für Zertifikate. Als Teil der Automation Suite-Konfiguration fügen wir das gesamte Kettenzertifikat ein, das das Stammzertifikat, alle Zwischenzertifikate sowie das Blattzertifikat enthält, und speichern sie in diesem Pfad. Da Dienste den Stamm- und Zwischenzertifikaten vertrauen, vertrauen sie automatisch allen anderen Zertifikaten, die von den Stamm- und Zwischenzertifikaten erstellt werden.

Pod-Ebene

In der Automation Suite werden Hunderte von Containern ausgeführt. Das manuelle Hinzufügen von Zertifikaten für jeden dieser Container für alle Dienste wäre eine anspruchsvolle Aufgabe. Die Automation Suite enthält jedoch ein freigegebenes Volume und einen Init-Container -Cert-Trustor , um diese Aufgabe zu unterstützen. Init ist ein spezialisierter Container, der vor App-Containern in einem Pod ausgeführt wird, und sein Lebenszyklus endet, sobald er seinen Auftrag abgeschlossen hat.

Im folgenden Beispiel wird der Orchestrator-Dienst in einem Pod ausgeführt. Zur Erinnerung: Ein Pod kann mehr als einen Container enthalten. In diesem Pod fügen wir einen weiteren Init-Container namens Cert-trustorein. Dieser Container enthält das Stammzertifikat, die Zwischenzertifikate und das Blattzertifikat.

Das freigegebene Volume ist sowohl an den Cert-Trustor-Container als auch an den Orchestrator-Dienst-Container angehängt. Er hat denselben Pfad wie der RHEL OS Certificate Trust Store: /etc/pki/ca-trust/ca/source/anchors.

Bevor der Orchestrator ausgeführt werden kann, führt der Cert-Trustor einen Auftrag aus, der die Zertifikate im freigegebenen Volume am Standort /etc/pki/ca-trust/ca/source/anchors hinzufügt und beendet.

Zertifikate sind für den Orchestrator-Dienst über das freigegebene Volume verfügbar.

Bestandsaufnahme aller Zertifikate in der Automation Suite

Während der Installation generierte Zertifikate

Als Teil der Installation der Automation Suite werden die folgenden Zertifikate generiert:

• Selbstsigniertes Zertifikat , das zum Zeitpunkt der Installation generiert wird. Wir empfehlen, das selbstsignierte Zertifikat nach der Installation durch ein Domänenzertifikat zu ersetzen. Siehe Verwalten von Zertifikaten.

  Hinweis: Das Zertifikat kann zum Zeitpunkt der Installation nur generiert werden, wenn Sie dem Automation Suite-Installationsprogramm während der Installation Administratorrechte erteilen. Wenn Sie dem Installationsprogramm keine Administratorberechtigungen erteilen können, müssen Sie das Zertifikat selbst erstellen und verwalten.
• Identity Server-Zertifikat zum Signieren von JWT-Tokens, die bei der Authentifizierung verwendet werden. Wenn das Zertifikat zum Signieren des JWT-Tokens nicht bereitgestellt wird, verwendet die Automation Suite das aktuell konfigurierte TLS-Zertifikat (selbstsigniert oder vom Kunden bereitgestellt). Wenn Sie Ihr eigenes Zertifikat zum Signieren von Identitätstokens haben möchten, siehe Verwalten von Zertifikaten.

Zusätzliche Zertifikate

• Wenn aktiviert, kann das SAML2-Authentifizierungsprotokoll ein Dienstzertifikat verwenden.
• Wenn Sie Active Directory mit einem Benutzernamen und einem Kennwort konfigurieren, ist LDAPS (LDAP Over SSL) optional. Wenn Sie sich für LDAPS entscheiden, müssen Sie ein Zertifikat bereitstellen. Dieses Zertifikat wird den vertrauenswürdigen Stammzertifizierungsstellen der Automation Suite hinzugefügt. Weitere Informationen finden Sie in der Microsoft-Dokumentation.

Funktionsweise der Zertifikatsaktualisierung/-rotation

Die Zertifikate werden an zwei Orten gespeichert:

• istio-ingressgateway-certs in <istio-system>
• <uipath> -Namespace

Um das Zertifikat in den Namespaces <istio-system> und <uipath> zu aktualisieren, müssen Sie den Befehl uipathctl config update-tls-certificates ausführen.

Pods können nur auf Geheimnisse zugreifen, die sich in ihrem Namespace befinden. Beispielsweise können die Pods, die im Namespace <uipath> ausgeführt werden, nicht auf die Geheimnisse zugreifen, die im Namespace <istio-system> gespeichert sind. Daher werden Zertifikate in beide Namespaces kopiert.

Für den Namespace <uipath> fügen wir die Zertifikate in die Pods ein, die Zertifikate benötigen, und starten die Pods neu, damit sie die neuen Zertifikate verwenden können.

Hinweis:

Das Update erfolgt mithilfe der rollierenden Bereitstellungsmethode. Wenn Microservices aus Gründen der Hochverfügbarkeit zwei Pods haben, wird durch das Update einer der Pods gelöscht und es wird eine neue Version des Pods erstellt. Sobald die neue erfolgreich gestartet wurde, wird die alte entfernt. Es gibt eine kurze Ausfallzeit, während der alte Pod noch nicht beendet wird.