- Überblick
- Anforderungen
- Installation
- Nach der Installation
- Migration und Upgrade
- Aktualisieren der Automation Suite auf EKS/AKS
- Schritt 1: Verschieben der Identitätsorganisationsdaten von einer eigenständigen in die Automation Suite
- Schritt 2: Wiederherstellen der eigenständigen Produktdatenbank
- Schritt 3: Sichern der Plattformdatenbank in der Automation Suite
- Schritt 4: Zusammenführen von Organisationen in der Automation Suite
- Schritt 5: Aktualisieren der migrierten Produktverbindungszeichenfolgen
- Schritt 6: Migrieren des eigenständigen Orchestrators
- Schritt 7: Migrieren von eigenständigen Insights
- Schritt 8: Migrieren des eigenständigen Test Managers
- Schritt 9: Löschen des Standardmandanten
- Durchführen der Migration eines einzelnen Mandanten
- Migrieren von der Automation Suite unter Linux zur Automation Suite unter EKS/AKS
- Überwachung und Warnungen
- Clusterverwaltung
- Produktspezifische Konfiguration
- Konfigurieren von Orchestrator-Parametern
- Orchestrator-appSettings
- Konfigurieren von AppSettings
- Konfigurieren der maximalen Anforderungsgröße
- Überschreiben der Speicherkonfiguration auf Clusterebene
- Konfigurieren von Anmeldeinformationsspeichern
- Konfigurieren der Verwendung von einem Verschlüsselungsschlüssel pro Mandant
- Bereinigen der Orchestrator-Datenbank
- Fehlersuche und ‑behebung
- Das Sicherungssetup funktioniert nicht, da die Verbindung mit Azure Government fehlgeschlagen ist
- Hängende Pods im uipath-Namespace bei Aktivierung von benutzerdefinierten Knoten-Markierungen
- Automation Hub und Apps können mit Proxy-Setup nicht gestartet werden
- Pods können nicht mit FQDN in einer Proxy-Umgebung kommunizieren
- SQL-Verbindungszeichenfolge der Testautomatisierung wird ignoriert
- EKS-Sicherung aufgrund der Velero-Version
- Die Velero-Sicherung schlägt mit dem Fehler „FehlgeschlageneValidierung“ fehl
- Beim Zugriff auf den FQDN wird der Fehler „RBAC-Zugriff verweigert“ zurückgegeben

Automation Suite in der EKS/AKS-Installationsanleitung
Sicherheit und Compliance
Sicherheitskontext für UiPath®-Dienste
Dieser Abschnitt enthält Details zum Sicherheitskontext der UiPath® Dienste.
Alle UiPath®-Dienste werden mit einem Sicherheitskontext konfiguriert, der im Abschnitt spec definiert ist. Das folgende Beispiel zeigt die Konfiguration für alle Dienste mit Ausnahme von du-cjk-ocr:
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 1000
fsGroup: 1000
containers:
- securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
hostPID: false
hostNetwork: false
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 1000
fsGroup: 1000
containers:
- securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
hostPID: false
hostNetwork: false
Im Fall des Dienstes du-cjk-ocr lautet der Wert des Parameters readOnlyRootFilesystem false. Weitere Informationen zu du-cjk-ocr finden Sie in der Document Understanding-Dokumentation.
In einigen Fällen können die Benutzer-IDs und Gruppen-IDs größer oder gleich 1000 sein. Solche Werte sind je nach Umgebung zulässig. Es ist wichtig, dass Sie die Benutzer- und Gruppen-IDs gemäß Ihren Sicherheitsprinzipien und den Sicherheitsrichtlinien Ihrer Organisation konfigurieren.
Gatekeeper- und OPA-Richtlinien
Automation Suite ist mit Gatekeeper und OPA-Richtlinien vorkonfiguriert. Wenn Sie Ihre eigene Gatekeeper-Komponente und OPA-Richtlinien verwenden, können Sie diese Komponenten bei der Automation Suite-Installation überspringen. Weitere Informationen finden Sie unter Automation Suite-Stack. Überprüfen Sie in diesem Fall die OPA-Richtlinien und die Ausnahmen, die für die Installation und Ausführung der Automation Suite erforderlich sind.
Standardmäßig werden diese Richtlinien nur in den folgenden UiPath®-Namespaces ausgeführt: -uipath, uipath-installer, uipath-infra, airflow und argocd.
OPA-Richtlinien
| Policy | Actions | Auszuschließende Namespaces/Images |
|---|---|---|
Steuert die Einschränkung der Eskalation auf Stammberechtigungen. Entspricht dem Feld allowPrivilegeEscalation in einer PodSecurityPolicy |
|
|
| Konfiguriert eine Zulassungsliste von Apparmor-Profilen für die Verwendung durch Container. Dies entspricht bestimmten Anmerkungen, die auf eine PodSecurityPolicy angewendet werden. |
|
|
Steuert Linux-Funktionen auf Containern. Entspricht den Feldern allowedCapabilities und requiredDropCapabilities in einer PodSecurityPolicy. |
|
|
Steuert die Zulassungsliste für FlexVolume-Treiber. Entspricht dem Feld allowedFlexVolumes in PodSecurityPolicy. |
|
|
|
|
| |
Steuert die Zuweisung einer FSGroup, die die Volumes des Pods besitzt. Entspricht dem Feld fsGroup in einer PodSecurityPolicy. |
|
|
Steuert die Verwendung des Host-Dateisystems. Entspricht dem Feld allowedHostPaths in einer PodSecurityPolicy. |
|
|
Die Freigabe von Host-PID- und IPC-Namespaces durch Pod-Container ist nicht zulässig. Entspricht den Feldern hostPID und hostIPC in einer PodSecurityPolicy. |
|
|
| Steuert die Verwendung des Hostnetzwerk-Namespace durch Pod-Container. |
|
|
Steuert, ob ein Container den privilegierten Modus aktivieren kann. Entspricht dem Feld privileged in einer PodSecurityPolicy. |
|
|
Steuert die zulässigen procMount -Typen für den Container. Entspricht dem Feld allowedProcMountTypes in einer PodSecurityPolicy. |
|
|
| Erfordert die Verwendung eines schreibgeschützten Stammdateisystems durch Pod-Container. |
|
|
Steuert das von Containern verwendete Seccomp-Profil. Entspricht der Anmerkung seccomp.security.alpha.kubernetes.io/allowedProfileNames in einer PodSecurityPolicy. |
|
|
| Definiert eine Zulassungsliste von seLinuxOptions-Konfigurationen für Pod-Container. |
|
|
| Steuert die Benutzer- und Gruppen-IDs des Containers und einiger Volumes. |
|
|
| Schränkt einhängbare Volume-Typen auf die vom Benutzer angegebenen Typen ein. |
|
|
- Der
dapr-system-Namespace wird nur benötigt, wenn Sie Process Mining und Task Mining installieren. - Der
airflow-Namespace wird nur benötigt, wenn Sie Process Mining installieren.
Andere OPA-Richtlinien
| Policy | Actions | Auszuschließende Namespaces/Images |
|---|---|---|
Steuert die Fähigkeit eines Pods, automountServiceAccountToken zu aktivieren. |
|
|
| Erfordert, dass Container-Images mit einer Zeichenfolge aus der angegebenen Liste beginnen. |
|
|
|
| Keine Angabe | |
| Lässt nicht alle Dienste vom Typ „Lastausgleich“ zu. |
|
|
| Lässt nicht alle Dienste vom Typ NodePort zu. |
|
|
| Benutzer dürfen keine Ingress-Dateien mit einem leeren Hostnamen oder einem Platzhalter (*) erstellen können, da dies ihnen ermöglichen würde, den Datenverkehr für andere Dienste im Cluster abzufangen, auch wenn sie keinen Zugriff auf diese Dienste haben. |
|
|
| Erfordert, dass für Container Speicher- und CPU-Grenzwerte festgelegt sind. Schlägt Grenzen so ein, dass sie innerhalb der angegebenen Maximalwerte liegen. |
|
|
| Erfordert, dass für Container Speicher- und CPU-Anforderungen festgelegt sind. Schränkt Anforderungen ein, damit sie innerhalb der angegebenen Maximalwerte liegen. |
|
|
| Legt ein maximales Verhältnis für Containerressourcenlimits zu Anforderungen fest. |
|
|
| Erfordert, dass Container definierte Ressourcen festgelegt haben. |
|
|
Verknüpfen von ClusterRole- und Rollenressourcen mit dem Benutzer system:anonymous und der Gruppe system:unauthenticated nicht möglich. |
| Keine Angabe |
| Erfordert, dass Container-Images ein anderes Bild-Tag als die in der angegebenen Liste haben. |
| Keine Angabe |
| Erfordert, dass für Container ein vorübergehendes Speicherlimit festgelegt ist, das innerhalb der angegebenen Maximalwerte liegt. |
|
|
|
| Keine Angabe | |
Erfordert, dass Ingress-Ressourcen nur HTTPS sind. Ingress-Ressourcen müssen die Anmerkung kubernetes.io/ingress.allow-http enthalten, die auf false festgelegt ist. Standardmäßig ist eine gültige TLS {}-Konfiguration erforderlich. Dies kann optional gemacht werden, indem der Parameter tlsOptional auf true festgelegt wird. |
|
|
| Erfordert, dass Container-Images einen Digest enthalten. |
|
|
| Blockiert die Aktualisierung des Dienstkontos auf Ressourcen, die über Pods abstrahieren. Diese Richtlinie wird im Prüfungsmodus ignoriert. |
| Keine Angabe |
|
|
| |
| Erfordert, dass Pods Bereitschafts- und/oder Aktivitätstests haben. |
|
|
| Erfordert, dass Speicherklassen bei Verwendung angegeben werden. |
| Keine Angabe |
| Erfordert, dass alle Ingress-Regelhosts eindeutig sind. |
| Keine Angabe |
| Erfordert, dass Dienste eindeutige Selektoren innerhalb eines Namespace haben. Selektoren gelten als identisch, wenn sie identische Schlüssel und Werte haben. Selektoren können ein gemeinsames Schlüssel-/Wertpaar haben, solange sich mindestens ein eindeutiges Schlüssel-/Wertpaar befindet. |
| Keine Angabe |
- Der
dapr-system-Namespace wird nur benötigt, wenn Sie Process Mining und Task Mining installieren. - Der
airflow-Namespace wird nur benötigt, wenn Sie Process Mining installieren. prereq**sind temporäre Namespaces, die beim Ausführen einer Voraussetzungs- oder Zustandsprüfung erstellt wurden. Die Namespaces löschen sich nach Abschluss selbst.
Netzwerkrichtlinien
Die Automation Suite ist mit standardmäßigen Kubernetes-Netzwerkrichtlinien vorkonfiguriert, um dem Prinzip des Netzwerkzugriffs mit den geringsten Berechtigungen zu folgen. Sie können die Installation der von UiPath bereitgestellten Netzwerkrichtlinien überspringen, indem Sie network-policies unter der Liste exclude components in input.json hinzufügen. Weitere Informationen zu optionalen Komponenten finden Sie unter Automation Suite-Stack.
Die Automation Suite erzwingt das Netzwerk von, nach und innerhalb des uipath-Namespace. Wenn Sie Ihre eigenen Netzwerkrichtlinien mitbringen oder ein benutzerdefiniertes CNI haben (z. B. Cilium Enterprise oder Citizena Taberna Enterprise), stellen Sie sicher, dass Sie Ihre Richtlinien aktualisieren, um das Helm-Diagramm network-policies widerzuspiegeln.
Sie können das Helm-Diagramm network-policies der Automation Suite finden, indem Sie den folgenden Befehl ausführen.
- Sie müssen
<automation-suite-version>im folgenden Befehl durch Ihre aktuelle Automation Suite-Version ersetzen. - Sie müssen die Datei entpacken, um das Helm-Diagramm zu extrahieren.
helm pull oci://registry.uipath.com/helm/network-policies --version <automation-suite-version>
helm pull oci://registry.uipath.com/helm/network-policies --version <automation-suite-version>
Anforderungen an Clusterberechtigungen
Clusteradministratorzugriff ist für uipathctl auf Ihrem Verwaltungsknoten erforderlich, um die Automation Suite in einem dedizierten Cluster zu installieren und zu verwalten. Diese Zugriffsebene wird für Komponenten auf Systemebene in der Automation Suite benötigt, z. B. Istio (Routing-/Dienstgeflecht) und ArgoCD (Bereitstellung und Anwendungslebenszyklusverwaltung), sowie zum Erstellen von Namespaces im Zusammenhang mit der Automation Suite. Für freigegebene Cluster sind keine Administratorrechte erforderlich.
FIPS 140-2
Die FIPS 140-2 (Federal Information Processing Standards 140-2) sind ein Sicherheitsstandard, der die Effektivität von kryptografischen Modulen überprüft.
Die Automation Suite auf AKS kann auf FIPS 140-2-fähigen Knoten ausgeführt werden.
Sie können FIPS 140-2 auf den AKS-Knoten aktivieren, auf denen Sie die Automation Suite in den folgenden Szenarien installieren:
- Szenario 1: Neuinstallationen – Aktivieren Sie FIPS 140-2, bevor Sie eine Neuinstallation der Automation Suite 2023.4 oder höher durchführen.
- Szenario 2: Vorhandene Installationen – Aktivieren Sie FIPS 140-2, nachdem Sie eine Automation Suite-Installation auf einer Maschine durchgeführt haben, bei der FIPS 140-2 deaktiviert ist.
Szenario 1: Neue Installationen
Führen Sie die folgenden Schritte aus, um FIPS 140-2 auf den Maschinen zu aktivieren, auf denen Sie eine Neuinstallation der Automation Suite durchführen möchten:
- Bevor Sie die Installation der Automation Suite starten, aktivieren Sie FIPS 140-2 auf Ihren Maschinen.
- Führen Sie die Automation Suite-Installation durch, indem Sie die Installationsanweisungen in dieser Anleitung befolgen.
- Wenn Sie das AI Center auf einer FIPS 140-2-fähigen Maschine installieren und auch dem Microsoft SQL-Server verwenden, sind einige zusätzliche Konfigurationen erforderlich. Weitere Informationen finden Sie unter SQL-Anforderungen für das AI Center.
- Stellen Sie sicher, dass Insights deaktiviert ist, da es von FIPS 140-2 nicht unterstützt wird.
- Legen Sie das
fips_enabled_nodes-Flag in derinput.json-Datei auftruefest. - Stellen Sie sicher, dass Ihre Zertifikate FIPS 140-2-konform sind.
Hinweis:
Standardmäßig generiert die Automation Suite selbstsignierte FIPS 140-2-kompatible Zertifikate, deren Ablaufdatum vom von Ihnen gewählten Automation Suite-Installationstyp abhängt.
Es wird dringend empfohlen, diese selbstsignierten Zertifikate bei der Installation durch Zertifikate von Zertifizierungsstellen zu ersetzen. Um die Automation Suite auf FIPS 140-2-fähigen Maschinen verwenden zu können, müssen die neu bereitgestellten Zertifikate FIPS 140-2-kompatibel sein. Eine Liste der in Frage kommenden Verschlüsselungen, die von RHEL unterstützt werden, finden Sie in der RHEL-Dokumentation.
Weitere Informationen zum Hinzufügen eigener FIPS 140-2-konformer Tokensignatur- und TLS-Zertifikate finden Sie unter Zertifikatkonfiguration.
Szenario 2: Vorhandene Installationen
Sie können die Automation Suite auf Maschinen mit deaktiviertem FIPS 140-2 installieren und dann den Sicherheitsstandard auf denselben Maschinen aktivieren. Dies ist auch möglich, wenn Sie auf eine neue Automation Suite-Version aktualisieren.
Führen Sie die folgenden Schritte aus, um FIPS 140-2 auf den Maschinen zu aktivieren, auf denen Sie bereits eine Automation Suite-Installation durchgeführt haben:
- Führen Sie eine reguläre Automation Suite-Installation oder ein Upgrade auf Maschinen durch, bei denen FIPS 140-2 deaktiviert ist.
- Aktivieren Sie FIPS 140-2 auf allen Ihren Maschinen.
- Stellen Sie sicher, dass Ihre Zertifikate FIPS 140-2-konform sind.
Hinweis:
Um die Automation Suite auf FIPS 140-2-fähigen Maschinen zu verwenden, müssen Sie Ihre Zertifikate durch neue FIPS 140-2-kompatible Zertifikate ersetzen, die von einer Zertifizierungsstelle signiert wurden. Eine Liste der in Frage kommenden Verschlüsselungen, die von RHEL unterstützt werden, finden Sie in der RHEL-Dokumentation.
Weitere Informationen zum Hinzufügen eigener FIPS 140-2-konformer Tokensignatur- und TLS-Zertifikate finden Sie unter Zertifikatkonfiguration.
- Stellen Sie sicher, dass Ihre Produktauswahl den FIPS 140-2-Anforderungen entspricht:
- Wenn Sie das AI Center auf einer FIPS 140-2-fähigen Maschine installieren und auch dem Microsoft SQL-Server verwenden, sind einige zusätzliche Konfigurationen erforderlich. Weitere Informationen finden Sie unter SQL-Anforderungen für das AI Center.
- Wenn Sie Insights zuvor aktiviert haben, müssen Sie es deaktivieren, da es von FIPS 140-2 nicht unterstützt wird. Weitere Informationen zum Deaktivieren von Produkten nach der Installation finden Sie unter Verwalten von Produkten.
- Starten Sie Ihre Maschinen neu und überprüfen Sie, ob Sie FIPS 140-2 erfolgreich aktiviert haben.
- Führen Sie das
uipathctl-Installationsprogramm erneut aus.