- Überblick
- Anforderungen
- Installation
- Voraussetzungsprüfungen
- Herunterladen der Installationspakete
- uipathctl-Cluster
- uipathctl-Clusterwartung
- uipathctl cluster maintenance disable
- uipathctl cluster maintenance enable
- uipathctl cluster maintenance is-enabled
- uipathctl cluster migration
- uipathctl cluster migration export
- uipathctl cluster migration import
- uipathctl cluster migration run
- uipathctl-Cluster-Upgrade
- uipathctl config
- uipathctl config add-host-admin
- uipathctl config additional-ca-certificates
- uipathctl config additional-ca-certificates get
- uipathctl config additional-ca-certificates update
- uipathctl config-Warnungen
- uipathctl config Alerts add-email
- uipathctl config alerts remove-email
- uipathctl config alerts update-email
- uipathctl config argocd
- uipathctl config argocd ca-certificates
- uipathctl config argocd ca-certificates get
- uipathctl config argocd ca-certificates update
- uipathctl config argocd generate-dex-config
- uipathctl config argocd generate-rbac
- uipathctl config argocd registry
- uipathctl config argocd registry get
- uipathctl config argocd registry update
- uipathctl config enable-basic-auth
- uipathctl config Orchestrator
- uipathctl config Orchestrator get-config
- uipathctl config orchestrator update-config
- uipathctl config saml-certificates get
- uipathctl config saml-certificates rotate
- uipathctl config saml-certificates update
- uipathctl config tls-certificates
- uipathctl config tls-certificates get
- uipathctl config tls-certificates update
- uipathctl config token-signing-certificates
- uipathctl config token-signing-certificates get
- uipathctl config token-signing-certificates rotate
- uipathctl config token-signing-certificates update
- UiPathctl-Zustand
- Uipathctl-Gesundheitspaket
- Uipathctl-Zustandsprüfung
- uipathctl health diagnose
- uipathctl health test
- uipathctl-Manifest
- uipathctl manifest apply
- uipathctl manifest diff
- uipathctl manifest get
- uipathctl manifest get-revision
- uipathctl Manifest list-applications
- uipathctl manifest list-revisions
- uipathctl manifest render
- uipathctl-Voraussetzung
- uipathctl prereq create
- uipathctl prereq run
- „uipathctl“-Ressource
- uipathctl-Ressourcenbericht
- uipathctl-Snapshot
- uipathctl-Snapshot-Sicherung
- uipathctl snapshot backup create
- uipathctl snapshot backup disable
- uipathctl snapshot backup enable
- uipathctl snapshot delete
- uipathctl snapshot list
- uipathctl snapshot restore
- uipathctl snapshot restore create
- uipathctl snapshot restore delete
- uipathctl snapshot restore history
- uipathctl snapshot restore logs
- uipathctl-Version
- 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: Löschen des Standardmandanten
- B) Migration von einzelnen Mandanten
- Migrieren von der Automation Suite unter Linux zur Automation Suite unter EKS/AKS
- Überwachung und Warnungen
- Clusterverwaltung
- Produktspezifische Konfiguration
- Verwenden des Orchestrator-Konfiguratortools
- 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
Sicherheit und Compliance
Dieser Abschnitt enthält Details zum Sicherheitskontext der UiPath® Dienste.
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
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.
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.
-uipath
, uipath-installer
, uipath-infra
, airflow
und argocd
.
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.
Policy |
Actions |
Auszuschließende Namespaces/Images |
---|---|---|
Steuert die Möglichkeit 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 nur HTTPS-Ingress-Ressourcen verwendet werden können. 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 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.
network-policies
unter der Liste exclude components
in input.json
hinzufügen. Weitere Informationen zu optionalen Komponenten finden Sie unter Automation Suite-Stack.
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.
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>
uipathctl
auf Ihrem Verwaltungsknoten erforderlich, um die Automation Suite in Ihrem 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.
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.
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:
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: