Ü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 seinen eigenen Zertifikatspeicher. Bei REHL OS befindet sich der Trust Store für Zertifikate 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 dem Cert-Trustor-Container als auch dem Orchestrator-Dienstcontainer angefügt. Es hat den gleichen Pfad wie der Trust Store für REHL OS-Zertifikate: /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 und drei Monate lang gültig ist. Sie müssen das selbstsignierte Zertifikat nach der Installation durch ein Domänenzertifikat ersetzen. Siehe Verwalten von Zertifikaten

• 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), das in 90 Tagen abläuft. Wenn Sie Ihr eigenes Zertifikat zum Signieren von Identitätstokens haben möchten, siehe Verwalten von Zertifikaten.
• RKE2-Zertifikate werden generiert und laufen standardmäßig in 12 Monaten ab. Wenn die Zertifikate bereits abgelaufen sind oder in weniger als 90 Tagen ablaufen, werden sie beim Neustart von RKE2 rotiert.

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.

Dieses Zertifikat wird den vertrauenswürdigen Stammzertifizierungsstellen der Automation Suite hinzugefügt.

Funktionsweise der Zertifikatsaktualisierung/-rotation

Onlineinstallation

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 sudo ./configureUiPathAS.sh tls-cert update 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 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:

Bei Evaluierungsinstallationen mit einem Knoten werden die Pods durch das Update verkleinert. Alle Pods werden heruntergefahren und neu gestartet. Dieser Vorgang führt zu Ausfallzeiten.

Bei HA-fähigen Produktionsinstallationen mit mehreren Knoten erfolgt die Aktualisierung mit der fortlaufenden Bereitstellungsmethode. Wenn Microservices zwei Pods für Hochverfügbarkeitszwecke haben, löscht das Update einen der Pods und eine neue Version des Pods wird angezeigt. Sobald der neue erfolgreich gestartet wurde, wird der alte entfernt. Es wird eine kurze Ausfallzeit geben, während der alte Pod noch nicht beendet ist.

Offline-Installation

Zusätzlich zu den Zertifikaten, die für eine Onlineinstallation spezifisch sind, hat eine Offlinebereitstellung zwei zusätzliche Speicherorte, an denen rootCA.crt und tls.crt verwendet werden. Zertifikate werden in der ArgoCD- und Docker-Registrierung verwendet und dann sowohl im Docker- als auch im ArgoCD-Namespace gespeichert.

Sie können die Geheimnisse mit dem folgenden Befehl überprüfen:

# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd cert list --cert-type https