Übersicht über Zertifikate

Wichtig:

For details on the certificates you must provide, see Certificate requirements.

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-trustor ein. 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:

• Self-signed certificate generated at the time of installation, which is valid for 3 months. You must replace the self-signed certificate with a domain certificate post-installation. See Managing certificates.

• Identity Server certificate for signing JWT tokens used in authentication. If the certificate for signing the JWT token is not provided, Automation Suite uses the currently configured TLS certificate (can be the self-signed one or customer provided one), which expired in 90 days. If you want to have your own certificate for signing identity token, you can configure using the instructions in Managing certificates.

• Internes Zertifikat für MongoDB , das über den Zertifikatsmanager generiert wurde. Die Automation Suite-Version 2021.10.3 und älter stellt ein internes Zertifikat für MongoDB bereit, das 90 Tage gültig ist. Ab Version 2021.10.4 Zertifikate sind 3 Jahre gültig und werden automatisch aktualisiert.

  For more details, see MongoDB manual certificate update for Apps users.

• 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.
• If you configure Active Directory using a username and password, LDAPS (LDAP Over SSL) is optional. If you opt for LDAPS, you must provide a certificate. This certificate will be added into Automation Suite’s Trusted Root Certification Authorities. For details, see Microsoft documentation.

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