Übersicht über Zertifikate

Zertifikate, die für eine Automation Suite-Installation auf EKS/AKS erforderlich sind, einschließlich der Vertrauensarchitektur und des Zertifikatsrotationsprozesses.

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 bereitstellen müssen, finden Sie unter Zertifikatsanforderungen.

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 den Identity Service auf, um die eingehende Anforderung vom Client ü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

Das folgende Diagramm zeigt einen Container mit eigenem Betriebssystem und Vertrauensspeicher für Zertifikate.

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 das RHEL-Betriebssystem alle Zertifikate. Jeder Container verfügt über einen eigenen Zertifikatvertrauenswürdigenspeicher.

Als Teil der Automation Suite-Konfiguration fügen wir das gesamte Kettenzertifikat ein, das das Stammzertifikat und 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 wurden.

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.

1. Der Pod enthält einen Init-Container namens Cert-rustor, der das Stammzertifikat, die Zwischenzertifikate und das Blattzertifikat enthält.

2. Das freigegebene Volume wird sowohl an den Zertifikatspeicher-Container als auch an den Orchestrator-Dienstcontainer angehängt, und zwar über denselben Pfad wie der RHEL OS Certificate Trust Store: /etc/pki/ca-trust/ca/source/anchors.

3. Bevor der Orchestrator ausgeführt werden kann, fügt Certificate-rustor die Zertifikate dem freigegebenen Volume an diesem Speicherort hinzu und wird dann beendet.

4. Zertifikate werden dem 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 erstellt wird. Es wird empfohlen, nach der Installation das selbstsignierte Zertifikat durch ein Domänenzertifikat zu ersetzen. Siehe Verwalten von Zertifikaten.
• Identity Server-Zertifikat zum Signieren von JWT-Tokens, die bei der Authentifizierung verwendet werden. Wird das Zertifikat zum Signieren des JWT-Tokens nicht bereitgestellt, so verwendet die Automation Suite das aktuell konfigurierte TLS-Zertifikat (selbstsigniert oder vom Kunden bereitgestellt). Wenn Sie Ihr eigenes Zertifikat zum Signieren von Identitätstoken verwenden möchten, lesen Sie bitte Verwalten von Zertifikaten.

Zusätzliche Zertifikate

• Wenn aktiviert, kann das SAML2-Authentifizierungsprotokoll ein Dienstzertifikat verwenden.
• Wenn Sie Active Directory mit einem Benutzernamen und Kennwort konfigurieren, ist LDAPS (LDAP über 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 geheime Schlüssel zugreifen, die sich in ihrem Namespace befinden. Beispielsweise können die Pods, die im Namespace uipath ausgeführt werden, nicht auf die geheimen Schlüssel zugreifen, die im Namespace istio-system gespeichert sind. Daher werden Zertifikate in beiden Namespaces kopiert.

Für den Namespace uipath stellen wir die Zertifikate in den Pods bereit, 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.