Sicherheit und Compliance

Sicherheits- und Compliance-Funktionen in der Automation Suite auf OpenShift.

Sicherheitskontexteinschränkungen (SCC) für UiPath-Dienste

Die UiPath® Automation Suite erfordert die standardmäßige restricted-v2 Sicherheitskontexteinschränkung (SCC) für alle Workload-Pods. Dieser SCC ist in OpenShift integriert und steht allen authentifizierten Benutzern automatisch über die Standardeinstellung ClusterRoleBinding system:openshift:scc:restricted-v2 zur Verfügung.

Wichtig:

Die SCC-Zuweisung für Dienstkonten in den Automation Suite-Namespaces darf nicht geändert werden. Gewähren Sie dem Standarddienstkonto beispielsweise nicht anyuid oder andere zulässige SCCs.

Sicherheitskontext für UiPath®-Dienste

Dieser Abschnitt enthält Details zum Sicherheitskontext der UiPath® Dienste.

Alle UiPath®-Dienste werden mit einem Sicherheitskontext konfiguriert, der in ihrem Abschnitt spec definiert ist.

Das folgende Beispiel zeigt eine typische Konfiguration für UiPath®-Dienste:

spec:
  securityContext:
    runAsNonRoot: true
  containers:
    - securityContext:
        allowPrivilegeEscalation: false
        privileged: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
  hostPID: false
  hostNetwork: false

Für einige UiPath®-Dienste gibt es Ausnahmen von der typischen Sicherheitskontextkonfiguration:

• Insights has multiple features that use the Chromium Linux SUID Sandbox. While elevated access is not required for installing Insights, it is essential for specific feature functionality. For details, refer to Configuring the Insights custom security context.
• Process Mining verwendet die folgenden Airflow-Dienste, deren Sicherheitskontext von der typischen Konfiguration für UiPath®-Dienste abweicht:
  • Der Dienst statsd , wie im folgenden Beispiel gezeigt:

    securityContext:
        runAsUser: 65534
        seLinuxOptions:
          level: s0:c27,c4
    

  • Die scheduler, webserver und andere Airflow-Pods, wie im folgenden Beispiel gezeigt:

      securityContext:
        fsGroup: 1000
        runAsGroup: 1000
        runAsNonRoot: true
        runAsUser: 50000
        seLinuxOptions:
          level: s0:c27,c4
        supplementalGroups:
          - 1000
    

  • Der dynamische Runtime-Pod, wie im folgenden Beispiel gezeigt:

      securityContext:
        fsGroup: 1000
        runAsGroup: 1000
        runAsNonRoot: true
        runAsUser: 1001
        seLinuxOptions:
          level: s0:c27,c4
        supplementalGroups:
          - 1000
    

In einigen Fällen können die Benutzer-IDs und Gruppen-IDs je nach Umgebung größer oder gleich 1000 sein. Stellen Sie sicher, dass Sie die Benutzer- und Gruppen-IDs gemäß Ihren Sicherheitsprinzipien und den Sicherheitsrichtlinien Ihrer Organisation konfigurieren.

Netzwerkrichtlinien

Die folgende Tabelle enthält eine allgemeine Richtlinie für Netzwerkrichtlinien. Sie enthält eine Liste von Routen, die zum Konfigurieren des <uipath> -Namespace erforderlich sind.

Quelle	Ziel (Destination)	Richtung	Ports	Richtlinientyp	Bedingungen
Alle Pods in uipath	Alle extern	Verweigern	Alle	Netzwerkrichtlinie	Standardmäßige Richtlinie „Alle verweigern“.
Alle Pods in uipath	Alle Pods in uipath	Zulassen	Alle	Netzwerkrichtlinie	Interne Namespacekommunikation
Alle Pods in uipath	Kube-System-DNS	Auslauf	53 TCP/UDP	Netzwerkrichtlinie	DNS-Auflösung
Alle Pods in uipath	Externe IPs	Auslauf	Alle	Netzwerkrichtlinie	Externe Kommunikation
Alle Pods in uipath	Istiod	Auslauf	Alle	Netzwerkrichtlinie	Dienstgeflechtsteuerung
Prometheus	Alle Pods in uipath	Ingress	Benutzerdefinierte Scraping-Ports	Netzwerkrichtlinie	Überwachen des Zugriffs
Istio-Gateway	Alle Pods in uipath	Ingress	Alle	Netzwerkrichtlinie	Gateway-Datenverkehr
Kube-System	Alle Pods in uipath	Ingress	Alle	Netzwerkrichtlinie	Systemzugriff
Redis-System	Alle Pods in uipath	Ingress	9091/TCP	Netzwerkrichtlinie	Redis-Überwachung
Aufgeführte Dienste	Redis Namespace	Auslauf	Alle	Netzwerkrichtlinie	Redis-Zugriff

Anforderungen an Clusterberechtigungen

Automation Suite requires the cluster admin role during the installation to automate the entire installation process. Alternatively, you can install Automation Suite with lower permissions. An installation with lower permissions involves some additional steps. For the permissions that the installation requires, refer to Step 2: Creating the required roles.

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 kann auf FIPS 140-2-fähigen Maschinen ausgeführt werden.

Aktivieren von FIPS 140-2 für Neuinstallationen

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:

1. Bevor Sie die Installation der Automation Suite starten, aktivieren Sie FIPS 140-2 auf Ihren Maschinen.

2. Führen Sie die Automation Suite-Installation durch, indem Sie die Installationsanweisungen in dieser Anleitung befolgen.

   Hinweis:

   • If you install AI Center on a FIPS 140-2-enabled machine and also use Microsoft SQL Server, some additional configuration is required. For details, refer to SQL requirements for AI Center.
   • Make sure Insights is disabled, as it is not supported on FIPS 140-2. If you need to use Insights, you can deploy it on a dedicated non-FIPS node. For details, refer to How to deploy Insights in a FIPS-enabled cluster.

3. Legen Sie das fips_enabled_nodes-Flag in der input.json-Datei auf true fest.

4. 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 einer Zertifizierungsstelle 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.

   For details on how to add your own FIPS 140-2-compliant token-signing and TLS certificates, refer to Certificate configuration.