- Überblick
- Anforderungen
- Bereitstellungsvorlagen
- Anleitung: Vorbereiten der Installation
- Anleitung: Vorbereiten der Installation
- Schritt 2: Konfigurieren der OCI-konformen Registrierung für Offline-Installationen
- Schritt 3: Konfigurieren des externen Objektspeichers
- Schritt 4: Konfigurieren des High Availability Add-on
- Schritt 5: Konfigurieren von SQL-Datenbanken
- Schritt 7: Konfigurieren des DNS
- Schritt 8: Konfigurieren der Datenträger
- Schritt 9: Konfigurieren der Einstellungen auf Kernel- und Betriebssystemebene
- Schritt 10: Konfigurieren der Knotenports
- Schritt 11: Anwenden verschiedener Einstellungen
- Schritt 12: Validieren und Installieren der erforderlichen RPM-Pakete
- Cluster_config.json-Beispiel
- Allgemeine Konfiguration
- Profilkonfiguration
- Zertifikatkonfiguration
- Datenbankkonfiguration
- Konfiguration des externen Objektspeichers
- Vorsignierte URL-Konfiguration
- ArgoCD-Konfiguration
- Konfiguration der Kerberos-Authentifizierung
- Externe OCI-konforme Registrierungskonfiguration
- Disaster Recovery: Aktiv/Passiv- und Aktiv/Aktiv-Konfigurationen
- Konfiguration des High Availability Add-ons
- Spezifische Orchestrator-Konfiguration
- Insights-spezifische Konfiguration
- Process Mining-spezifische Konfiguration
- Spezifische Konfiguration für Document Understanding
- Spezifische Konfiguration für Automation Suite Robots
- AI Center-spezifische Konfiguration
- Konfiguration der Überwachung
- Optional: Konfigurieren des Proxyservers
- Optional: Aktivieren der Widerstandsfähigkeit gegen zonale Ausfälle in einem HA-fähigen Produktionscluster mit mehreren Knoten
- Optional: Übergeben einer benutzerdefinierten resolv.conf-Datei
- Optional: Erhöhen der Fehlertoleranz
- Hinzufügen eines dedizierten Agent-Knotens mit GPU-Unterstützung
- Hinzufügen eines dedizierten Agentenknotens für Automation Suite-Roboter
- Schritt 15: Konfigurieren der temporären Docker-Registrierung für Offline-Installationen
- Schritt 16: Validieren der Voraussetzungen für die Installation
- Manuell: Durchführen der Installation
- Nach der Installation
- Zugreifen auf die Automation Suite
- Verwalten der Zertifikate
- Durchführen von Vorgängen nach der Installation
- Clusterverwaltung
- Verwalten von Produkten
- Erste Schritte mit dem Clusterverwaltungsportal
- Migrieren von Redis vom clusterinternen zum externen High Availability Add-on
- Migrieren von Daten zwischen Objectstores
- Clusterinterner Objectstore zu einem externen Objectstore migrieren
- Migrieren von der clusterinternen Registrierung zu einer externen OCI-konformen Registrierung
- Manueller Wechsel zum sekundären Cluster in einem Aktiv-/Passiv-Setup
- Disaster Recovery: Durchführen von Vorgängen nach der Installation
- Umwandlung einer bestehenden Installation in eine Multi-Site-Einrichtung
- Richtlinien zum Upgrade einer Aktiv/Passiv- oder Aktiv/Aktiv-Bereitstellung
- Leitlinien zum Sichern und Wiederherstellen einer Aktiv-/Passiv- oder Aktiv/Aktiv-Bereitstellung
- Skalieren einer Bereitstellung mit einem einzelnen Knoten (Auswertung) zu einer Bereitstellung mit mehreren Knoten (HA).
- Überwachung und Warnungen
- Migration und Upgrade
- Migrieren zwischen Automation Suite-Clustern
- Aktualisieren der Automation Suite
- Herunterladen der Installationspakete und Übertragen aller Dateien auf den ersten Serverknoten
- Abrufen der zuletzt angewendeten Konfiguration aus dem Cluster
- Aktualisieren der Clusterkonfiguration
- Konfigurieren der OCI-konformen Registrierung für Offline-Installationen
- Ausführen des Upgrades
- Durchführen von Vorgängen nach dem Upgrade
- Produktspezifische Konfiguration
- Konfigurieren von Orchestrator-Parametern
- Konfigurieren von AppSettings
- Konfigurieren der maximalen Anforderungsgröße
- Überschreiben der Speicherkonfiguration auf Clusterebene
- Konfigurieren von NLog
- Speichern von Roboterprotokollen in Elasticsearch
- Konfigurieren von Anmeldeinformationsspeichern
- Konfigurieren der Verwendung von einem Verschlüsselungsschlüssel pro Mandant
- Bereinigen der Orchestrator-Datenbank
- Best Practices und Wartung
- Fehlersuche und ‑behebung
- Fehlerbehebung bei Diensten während der Installation
- Deinstallieren des Clusters
- Löschen von Offline-Artefakten für mehr Speicherplatz
- So löschen Sie Redis-Daten
- So können Sie die Istio-Protokollierung aktivieren
- So werden Protokolle manuell bereinigt
- So löschen Sie alte Protokolle, die im sf-logs-Bucket gespeichert sind
- So deaktivieren Sie Streaming-Protokolle für das AI Center
- Fehlerbehebung bei fehlgeschlagenen Automation Suite-Installationen
- So löschen Sie Bilder aus dem alten Installationsprogramm nach dem Upgrade
- Deaktivieren von TX-Prüfsummen-Offloading
- So legen Sie die ArgoCD-Protokollebene manuell auf Info fest
- So erweitern Sie den AI Center-Speicher
- So wird der codierte pull_secret_value für externe Registrierungen generiert
- Umgang mit schwachen Verschlüsselungen in TLS 1.2
- So überprüfen Sie die TLS-Version
- So arbeiten Sie mit Zertifikaten
- So planen Sie die Ceph-Sicherung und Wiederherstellung von Daten
- Sammeln von DU-Nutzungsdaten mit dem clusterinternen Objektspeicher (Ceph)
- So installieren Sie RKE2 SELinux in Air-Gap-Umgebungen
- How to clean up old differential backups on an NFS server
- Fehler beim Herunterladen des Pakets
- Die Offlineinstallation schlägt aufgrund fehlender binärer Dateien fehl
- Zertifikatproblem bei der Offlineinstallation
- Validierungsfehler bei der SQL-Verbindungszeichenfolge
- Azure-Datenträger nicht als SSD markiert
- Fehler nach der Zertifikatsaktualisierung
- Virenschutz verursacht Probleme bei der Installation
- Automation Suite funktioniert nach Betriebssystem-Upgrade nicht
- Bei der Automation Suite muss „backlog_wait_time“ auf 0 gesetzt werden.
- Die temporäre Registrierungsinstallation schlägt unter RHEL 8.9 fehl
- Häufiges Neustartproblem bei UiPath-Namespace-Bereitstellungen während Offline-Installationen
- DNS-Einstellungen werden von CoreDNS nicht berücksichtigt
- Upgrade schlägt aufgrund eines fehlerhaften Ceph . fehl
- Rke2 wird aufgrund von Platzproblemen nicht gestartet
- Upgrade schlägt aufgrund von klassischen Objekten in der Orchestrator-Datenbank fehl
- Ceph-Cluster in beeinträchtigtem Status nach parallelem Upgrade
- Dienst-Upgrade schlägt für Apps fehl
- Timeouts beim direkten Upgrade
- Upgrade schlägt in Offline-Umgebungen fehl
- Snapshot-controller-crds Pod im Status CrashLoopBackOff nach dem Upgrade
- Upgrade schlägt aufgrund überschriebener Insights-PVC-Größen fehl
- Festlegen eines Timeout-Intervalls für die Verwaltungsportale
- Die Authentifizierung funktioniert nach der Migration nicht
- kinit: KDC kann für Realm <AD Domain> beim Abrufen der ersten Anmeldeinformationen nicht gefunden werden
- Kinit: Keytab enthält keine geeigneten Schlüssel für *** beim Abrufen der ersten Anmeldeinformationen
- GSSAPI-Vorgang aufgrund eines ungültigen Statuscodes fehlgeschlagen
- Alarm für fehlgeschlagenen Kerberos-tgt-update-Auftrag erhalten
- SSPI-Anbieter: Server in Kerberos-Datenbank nicht gefunden
- Anmeldung eines AD-Benutzers aufgrund eines deaktivierten Kontos fehlgeschlagen
- ArgoCD-Anmeldung fehlgeschlagen
- Aktualisieren Sie die zugrunde liegenden Verzeichnisverbindungen
- Fehler beim Abrufen des Sandbox-Abbilds
- Pods werden nicht in der ArgoCD-Benutzeroberfläche angezeigt
- Redis-Testfehler
- RKE2-Server kann nicht gestartet werden
- Secret nicht im UiPath-Namespace gefunden
- ArgoCD wechselt nach der ersten Installation in den Status „In Bearbeitung“.
- Fehlende Ceph-rook-Metriken in Überwachungs-Dashboards
- Diskrepanz bei gemeldeten Fehlern bei diagnostischen Zustandsprüfungen
- Kein normales Upstream-Problem
- Redis-Start wird durch Antivirenprogramm blockiert
- Document Understanding erscheint nicht auf der linken Leiste der Automation Suite
- Fehlerstatus beim Erstellen einer Datenbeschriftungssitzung
- Fehlerstatus beim Versuch, eine ML-Fähigkeit bereitzustellen
- Migrationsauftrag schlägt in ArgoCD fehl
- Die Handschrifterkennung mit dem Intelligent Form Extractor funktioniert nicht oder arbeitet zu langsam
- Ausführen von Hochverfügbarkeit mit Process Mining
- Die Process Mining-Datenaufnahme ist bei der Anmeldung über Kerberos fehlgeschlagen
- Verbindung mit der Datenbank „AutomationSuite_ProcessMining_Lager“ über eine Verbindungszeichenfolge im pyodbc-Format nicht möglich
- Die Airflow-Installation schlägt mit „sqlaldemy.exc.ArgumentError“ fehl: URL konnte nicht analysiert werden rfc1738 aus Zeichenfolge „
- So fügen Sie eine IP-Tabellenregel hinzu, um den SQL Server-Port 1433 zu verwenden
- Dem Automation Suite-Zertifikat des Servers, auf dem CData Sync ausgeführt wird, wird nicht vertraut
- Ausführen des Diagnosetools
- Verwenden des Automation Suite-Supportpakets
- Erkunden von Protokollen
- Untersuchen der zusammengefassten Telemetrie

Automation Suite unter Linux – Installationsanleitung
Der Installationsprozess generiert selbstsignierte Zertifikate in Ihrem Namen. Diese Zertifikate sind FIPS-konform und laufen in 90 Tagen ab. Sie müssen sie durch Zertifikate ersetzen, die von einer vertrauenswürdigen Zertifizierungsstelle (CA) signiert wurden, sobald die Installation abgeschlossen ist. Wenn Sie die Zertifikate nicht aktualisieren, funktioniert die Installation nach 90 Tagen nicht mehr.
Wenn Sie die Automation Suite auf einem FIPS-fähigen Host installiert haben und die Zertifikate aktualisieren möchten, stellen Sie sicher, dass sie mit FIPS kompatibel sind.
Das Installationspaket bietet ein Clusterverwaltungstool, mit dem Sie Zertifikate nach der Installation aktualisieren können. Um auf das Tool zuzugreifen, navigieren Sie zum Speicherort des Installationspakets:
cd /opt/UiPathAutomationSuite/cd /opt/UiPathAutomationSuite/Führen Sie den folgenden Befehl aus, um die CSR und den privaten Schlüssel zu generieren:
# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf
# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN,DNS:apps.$AS_FQDN
EOF
# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csr# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf
# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN,DNS:apps.$AS_FQDN
EOF
# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csrIhr IT-Team verwendet die erhaltenen Werte, um ein signiertes Zertifikat zu generieren. Der generierte private Schlüssel bleibt lokal.
Um weitere Informationen zu Serverzertifikaten anzuzeigen, führen Sie den folgenden Befehl aus:
./bin/uipathctl config tls-certificates --help./bin/uipathctl config tls-certificates --helpAusgabe:
************************************************************************************
Manage tls certificates
Usage:
uipathctl config tls-certificates [flags]
uipathctl config tls-certificates [command]
Available Commands:
get Get the current tls certificates
update Update tls certificates
Flags:
-h, --help help for tls-certificates
Global Flags:
--context string name of the kubeconfig context to use
-f, --force override all user prompts to true
--kubeconfig string kubectl configuration file (default: ~/.kube/config)
--log-format string log format. one of [text,json] (default "text")
--log-level string set log level. one of [trace,debug,info,error] (default "info")
-q, --quiet disable progress indicators (emoji/formatted status messages)
--timeout duration timeout of the command (default: 90 minutes) (default 1h30m0s)
--versions string optional path to versions file
Use "uipathctl config tls-certificates [command] --help" for more information about a command.
************************************************************************************************************************************************************************
Manage tls certificates
Usage:
uipathctl config tls-certificates [flags]
uipathctl config tls-certificates [command]
Available Commands:
get Get the current tls certificates
update Update tls certificates
Flags:
-h, --help help for tls-certificates
Global Flags:
--context string name of the kubeconfig context to use
-f, --force override all user prompts to true
--kubeconfig string kubectl configuration file (default: ~/.kube/config)
--log-format string log format. one of [text,json] (default "text")
--log-level string set log level. one of [trace,debug,info,error] (default "info")
-q, --quiet disable progress indicators (emoji/formatted status messages)
--timeout duration timeout of the command (default: 90 minutes) (default 1h30m0s)
--versions string optional path to versions file
Use "uipathctl config tls-certificates [command] --help" for more information about a command.
************************************************************************************uipathctl config tls-certificates ausführen können.
Aktualisieren der Clusterzertifikate
Online-Installation: So finden Sie das Serverzertifikat
istio-ingressgateway-certs im Namespace istio-system .
Sehen Sie sich die Zertifikatsdateien in der folgenden Liste an:
- Das Server-TLS-Zertifikat wird als
tls.crtgespeichert. - Privater Server-TLS-Schlüssel als
tls.key - CA-Paket wird als
ca.crtgespeichert.
Sie können die Geheimnisse mit dem folgenden Befehl überprüfen:
kubectl -n istio-system get secrets istio-ingressgateway-certs -o yamlkubectl -n istio-system get secrets istio-ingressgateway-certs -o yamlZertifikate werden auch im UiPath-Namespace gespeichert. Das gilt für jedes UiPath®-Produkt, das Zertifikatinformationen benötigt, um eingehenden Aufrufen zu vertrauen. Weitere Informationen finden Sie unter Grundlegendes zur Containerarchitektur bezüglich Zertifikaten.
Offlineinstallation: So finden Sie das Serverzertifikat
rootCA.crt und tls.crtverwenden: ArgoCD und Docker-Registrierung. Die Zertifikate werden 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 login alm.cluster_fqnd --username argocd_username --password argocd_password
argocd cert list --cert-type https# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd login alm.cluster_fqnd --username argocd_username --password argocd_password
argocd cert list --cert-type httpsSo aktualisieren Sie Serverzertifikate
Führen Sie den folgenden Befehl aus, um den Zertifikatschlüssel zu entschlüsseln:
# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key
openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key
openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/keyuipathctl aus, um das Zertifikat zu aktualisieren. Sie benötigen den Pfad zu jeder der drei Zertifikatsdateien. Alle Zertifikatsdateien müssen das Format PEM haben.
- Zertifizierungsstellenpaket – Dieses Paket sollte nur die Kettenzertifikate enthalten, die zum Signieren des TLS-Serverzertifikats verwendet werden. Das Kettenlimit beträgt bis zu neun Zertifikate.
-
Serverzertifikat – Öffentliches Serverzertifikat
Hinweis:Die Dateiserver.crtmuss die gesamte Kette enthalten, wie im folgenden Beispiel gezeigt:-----server cert----- -----root ca chain----------server cert----- -----root ca chain----- -
Privater Schlüssel – Privater Schlüssel für das Serverzertifikat
./bin/uipathctl config tls-certificates update --cert server.crt --cacert ca.crt --key server.key./bin/uipathctl config tls-certificates update --cert server.crt --cacert ca.crt --key server.key
/directory/path/to/store/certificate gespeichert.
Zugriff auf das TLS-Zertifikat
Zum Ausgeben der Zertifikatsdateien führen Sie den folgenden Befehl aus, wobei Sie das Verzeichnis angeben, in dem die Zertifikate gespeichert sind.
./bin/uipathctl config tls-certificates get --show-details./bin/uipathctl config tls-certificates get --show-detailsHinzufügen des Zertifizierungsstellenzertifikats zum Host-Truststore
Sie sind dafür verantwortlich, sicherzustellen, dass die generierten Zertifikate vertrauenswürdig sind.
Um das Zertifikat zum Host-VM-Truststore hinzuzufügen, führen Sie die folgenden Befehle auf allen Knoten im Cluster aus:
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trustUm weitere Informationen über zusätzliche Zertifikate von Zertifizierungsstellen anzuzeigen, führen Sie den folgenden Befehl aus:
./bin/uipathctl config additional-ca-certificates --help./bin/uipathctl config additional-ca-certificates --helpAusgabe:
***************************************************************************************
Manage additional ca certificates
Usage:
uipathctl config additional-ca-certificates [flags]
uipathctl config additional-ca-certificates [command]
Available Commands:
get Get the current additional ca certificates
update Update additional ca certificates
Flags:
-h, --help help for additional-ca-certificates
Global Flags:
--context string name of the kubeconfig context to use
-f, --force override all user prompts to true
--kubeconfig string kubectl configuration file (default: ~/.kube/config)
--log-format string log format. one of [text,json] (default "text")
--log-level string set log level. one of [trace,debug,info,error] (default "info")
-q, --quiet suppress all output except for errors and warnings
--timeout duration timeout of the command (default: 90 minutes) (default 1h30m0s)
--versions string optional path to versions file
Use "uipathctl config additional-ca-certificates [command] --help" for more information about a command.
******************************************************************************************************************************************************************************
Manage additional ca certificates
Usage:
uipathctl config additional-ca-certificates [flags]
uipathctl config additional-ca-certificates [command]
Available Commands:
get Get the current additional ca certificates
update Update additional ca certificates
Flags:
-h, --help help for additional-ca-certificates
Global Flags:
--context string name of the kubeconfig context to use
-f, --force override all user prompts to true
--kubeconfig string kubectl configuration file (default: ~/.kube/config)
--log-format string log format. one of [text,json] (default "text")
--log-level string set log level. one of [trace,debug,info,error] (default "info")
-q, --quiet suppress all output except for errors and warnings
--timeout duration timeout of the command (default: 90 minutes) (default 1h30m0s)
--versions string optional path to versions file
Use "uipathctl config additional-ca-certificates [command] --help" for more information about a command.
***************************************************************************************uipathctl config additional-ca-certificates ausführen können.
Aktualisieren der Zertifikate von Zertifizierungsstellen
Um die Zertifikate von Zertifizierungsstellen zu aktualisieren, gehen Sie wie folgt vor:
- Aktualisieren Sie die Datei
cluster_config.json, um auf die Datei mitadditional_ca_certszu verweisen. Weitere Informationen zu diesem Parameter finden Sie unter Zertifikatkonfiguration. - Wenden Sie das Manifest an:
./bin/uipathctl manifest apply cluster_config.json --versions versions.json./bin/uipathctl manifest apply cluster_config.json --versions versions.jsonWichtig: Dieser Befehl kann mit Fehlern fehlschlagen wie:Fahren Sie unabhängig vom Fehler mit Schritt 3 fort, um Bereitstellungen neu zu starten und die Umgebung zu stabilisieren.Error: [failed to wait for application argocd/<app-name1>: timed out waiting for the condition, failed to wait for application argocd/<app-name2>: timed out waiting for the condition]]Error: [failed to wait for application argocd/<app-name1>: timed out waiting for the condition, failed to wait for application argocd/<app-name2>: timed out waiting for the condition]] - Starten Sie alle Bereitstellungen und zustandsbehafteten Gruppen im
uipath-Namespace manuell neu:kubectl rollout restart deployment -n <uipath> kubectl rollout restart sts -n <uipath>kubectl rollout restart deployment -n <uipath> kubectl rollout restart sts -n <uipath>
get aus dem Abschnitt Zugriff auf die Zertifikate von Zertifizierungsstellen verwenden und sie in der Datei .pem des Zertifizierungsstellenzertifikats anfügen, die Sie im Feld additional_ca_certs angeben müssen.
.pem-Format sein und kann mehr als ein Zertifikat enthalten.
Zugriff auf das Zertifikat von einer Zertifizierungsstelle
Um die bereits konfigurierten Zertifikate von Zertifizierungsstellen herunterzuladen, führen Sie den folgenden Befehl aus:
./bin/uipathctl config additional-ca-certificates get ./bin/uipathctl config additional-ca-certificates getHinzufügen des Zertifizierungsstellenzertifikats zum Host-Truststore
Sie sind dafür verantwortlich, sicherzustellen, dass die generierten Zertifikate vertrauenswürdig sind.
Um das Zertifikat zum Host-VM-Truststore hinzuzufügen, führen Sie die folgenden Befehle auf allen Knoten im Cluster aus:
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trustBei Windows-Umgebungen lesen Sie bitte diese Anleitung , um vertrauenswürdige Stammzertifikate zu installieren.
Die Automation Suite bietet zwei Methoden, um die Rotation von Identitätstoken-Signaturzertifikaten zu verwalten: automatisch und manuell.
Um weitere Informationen zu Identitätstoken-Signaturzertifikaten anzuzeigen, führen Sie den folgenden Befehl aus:
./bin/uipathctl config token-signing-certificates --help./bin/uipathctl config token-signing-certificates --helpAusgabe:
************************************************************************************
Manage token signing certificates
Usage:
uipathctl config token-signing-certificates [flags]
uipathctl config token-signing-certificates [command]
Available Commands:
automatic-key-management Manage key management
get Get the current token signing certificate
rotate Rotate token signing certificates
update Update future token signing certificate
Flags:
-h, --help help for token-signing-certificates
Global Flags:
--context string name of the kubeconfig context to use
-f, --force override all user prompts to true
--kubeconfig string kubectl configuration file (default: ~/.kube/config)
--log-format string log format. one of [text,json] (default "text")
--log-level string set log level. one of [trace,debug,info,error] (default "info")
-q, --quiet suppress all output except for errors and warnings
--timeout duration timeout of the command (default: 90 minutes) (default 1h30m0s)
--versions string optional path to versions file
Use "uipathctl config token-signing-certificates [command] --help" for more information about a command.
************************************************************************************************************************************************************************
Manage token signing certificates
Usage:
uipathctl config token-signing-certificates [flags]
uipathctl config token-signing-certificates [command]
Available Commands:
automatic-key-management Manage key management
get Get the current token signing certificate
rotate Rotate token signing certificates
update Update future token signing certificate
Flags:
-h, --help help for token-signing-certificates
Global Flags:
--context string name of the kubeconfig context to use
-f, --force override all user prompts to true
--kubeconfig string kubectl configuration file (default: ~/.kube/config)
--log-format string log format. one of [text,json] (default "text")
--log-level string set log level. one of [trace,debug,info,error] (default "info")
-q, --quiet suppress all output except for errors and warnings
--timeout duration timeout of the command (default: 90 minutes) (default 1h30m0s)
--versions string optional path to versions file
Use "uipathctl config token-signing-certificates [command] --help" for more information about a command.
************************************************************************************Sie können eine maximale Schlüssellänge von 4096 Bit zum Signieren von Zertifikaten verwenden. Als Best Practice empfehlen wir dringend, eine Schlüssellänge von mindestens 512 Bit (64 Byte) zu verwenden.
uipathctl config token-signing-certificates ausführen können.
Automatische Zertifikatsrotation
Automatische Zertifikatsrotation bedeutet, dass die Automation Suite den Lebenszyklus der Signaturschlüssel verwaltet. Dazu gehören das Rotieren von Schlüsseln alle 90 Tage, die Ankündigung neuer Schlüssel 14 Tage vor der Rotation, die Aufbewahrung alter Schlüssel für 14 Tage nach der Rotation und das Löschen nach Ablauf des 14-Tage-Zeitraums.
Wenn Sie von einer älteren Version auf 2.2510 aktualisieren, ist die automatische Zertifikatsrotation standardmäßig deaktiviert. Um die automatische Schlüsselverwaltung zu aktivieren, verwenden Sie den folgenden Befehl:
./bin/uipathctl config token-signing-certificates automatic-key-management enable./bin/uipathctl config token-signing-certificates automatic-key-management enableDie Aktivierung der automatischen Zertifikatsrotation kann zu einer Ausfallzeit von bis zu einer Stunde führen.
Die automatische Zertifikatsrotation ist standardmäßig für Neuinstallationen der Automation Suite aktiviert. Um die automatische Schlüsselverwaltung zu deaktivieren, verwenden Sie den folgenden Befehl:
./bin/uipathctl config token-signing-certificates automatic-key-management disable./bin/uipathctl config token-signing-certificates automatic-key-management disableWenn die automatische Verwaltungsfunktion deaktiviert ist, müssen Signaturzertifikate manuell aktualisiert und rotiert werden. Weitere Informationen zur manuellen Schlüsselverwaltung finden Sie in der Dokumentation zum manuellen Aktualisieren und Rotieren des Zertifikats.
Manuelles Aktualisieren des Zertifikats
Führen Sie den folgenden Befehl aus, um das neue Zertifikat zum Signieren des Tokens hochzuladen:
Der folgende Befehl ersetzt nicht das vorhandene Tokensignaturzertifikat.
.pem hat.
server.crt muss die gesamte Kette enthalten, wie im folgenden Beispiel gezeigt:
-----server cert-----
-----root ca chain----------server cert-----
-----root ca chain-----./bin/uipathctl config token-signing-certificates update --cert server.crt --key server.key./bin/uipathctl config token-signing-certificates update --cert server.crt --key server.keyManuelles Rotieren des Zertifikats
Um das alte Zertifikat zu rotieren oder durch das neue zu ersetzen, führen Sie den folgenden Befehl aus:
./bin/uipathctl config token-signing-certificates rotate./bin/uipathctl config token-signing-certificates rotateDie Vorlaufzeit zwischen der Zertifikat-Aktualisierung und dem Rotieren sollte etwa 24 bis 48 Stunden betragen.
Wir benötigen diese Vorlaufzeit, um die Authentifizierung für zwischengespeicherte Token, die von einem alten Zertifikat signiert wurden, weiterhin unterstützen zu können.
Wenn Sie das Zertifikat zu früh vor dem Ablauf des Cache-Tokens rotieren, kann dies zu Ausfallzeiten führen. Möglicherweise müssen Sie dann auch alle Ihre Roboter neu starten.
Notfall-Zertifikatsrotation
Führen Sie die folgenden Schritte aus, um eine Notfall-Zertifikatsaktualisierung durchzuführen:
Zugreifen auf das Zertifikat
Führen Sie den folgenden Befehl aus, um das aktuelle Tokensignaturzertifikat herunterzuladen:
./bin/uipathctl config token-signing-certificates get --show-details./bin/uipathctl config token-signing-certificates get --show-details Standardmäßig laufen RKE2-Zertifikate in 12 Monaten ab. In den 90 Tagen vor ihrem Ablaufdatum werden Zertifikate rotiert, wenn Sie RKE2 neu starten.
Weitere Informationen finden Sie unter RKE2 – Erweiterte Optionen – Zertifikatsrotation.
Überprüfen des Ablaufdatums des RKE2-Zertifikats
if [[ -d "/var/lib/rancher/rke2/server/tls" ]]; then
dir="/var/lib/rancher/rke2/server/tls"
elif [[ -d "/var/lib/rancher/rke2/agent/tls" ]]; then
dir="/var/lib/rancher/rke2/agent/tls"
else
dir="/var/lib/rancher/rke2/agent/"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt; do
# Extract the expiry date from the certificate
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
doneif [[ -d "/var/lib/rancher/rke2/server/tls" ]]; then
dir="/var/lib/rancher/rke2/server/tls"
elif [[ -d "/var/lib/rancher/rke2/agent/tls" ]]; then
dir="/var/lib/rancher/rke2/agent/tls"
else
dir="/var/lib/rancher/rke2/agent/"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt; do
# Extract the expiry date from the certificate
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
doneDie Ausgabe, die Sie erhalten, sollte in etwa so aussehen wie im folgenden Bild:
Rotieren des RKE2-Zertifikats
Standardmäßig laufen RKE2-Zertifikate in 12 Monaten ab. In den 90 Tagen vor ihrem Ablaufdatum werden Zertifikate rotiert, wenn Sie RKE2 neu starten. Wenn die Gültigkeit der Zertifikate jedoch den Zeitraum von 90 Tagen überschreitet, müssen Sie die Zertifikate manuell rotieren, indem Sie die unter RKE2 – Erweiterte Optionen – Zertifikatsrotation genannten Schritte ausführen.
Wenn Sie den Ablaufzeitpunkt von RKE2-Zertifikaten an bestimmte Anforderungen anpassen möchten, ist dies möglich, bevor Sie die RKE2-Dienste für Server- und Agent-Knoten neu starten.
Um die RKE2-Zertifikate zu rotieren, müssen Sie zuerst eine Reihe von Aktionen auf den Serverknoten ausführen und dann mit einigen Schritten für die Agent-Knoten fortfahren.
- Stoppen Sie den RKE2-Server:
systemctl stop rke2-server.servicesystemctl stop rke2-server.service - Löschen Sie alle verbleibenden RKE2-Prozesse:
rke2-killall.shrke2-killall.sh - Löschen Sie die Datei
dynamic-cert.jsonunter/var/lib/rancher/rke2/server/tls/. -
Um den Ablaufzeitraum der RKE2-Zertifikate anzupassen, verwenden Sie den folgenden Befehl. Beachten Sie, dass in diesem Beispiel der Gültigkeitszeitraum auf 1000 Tage festgelegt wird, Sie können diesen Wert jedoch basierend auf Ihren Anforderungen ändern.
SERVICE_NAME="rke2-server.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reloadSERVICE_NAME="rke2-server.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reload - Starten Sie den RKE2-Server neu:
systemctl start rke2-server.servicesystemctl start rke2-server.serviceHinweis: Wenn der Cluster über mehrere Serverknoten verfügt, werden die Schritte 1–4 möglicherweise nicht vollständig ausgeführt, da etcd den Ringalgorithmus eventuell nicht abschließen kann. Wiederholen Sie in diesem Fall die Schritte 1–4 auf anderen Serverknoten. - Löschen Sie das Geheimnis
rke2-servingaus dem Namespacekube-system:kubectl delete secret -n kube-system rke2-servingkubectl delete secret -n kube-system rke2-servingHinweis:Bei einer Bereitstellung mit mehreren Knoten können Sie diekubectl-Befehle möglicherweise erst ausführen, wenn Sie die ersten vier Vorgänge auf der erforderlichen Anzahl von Serverknoten abgeschlossen haben. Damit wird die Quorum-Anforderung von etcd erfüllt. Sie können das Geheimnisrke2-servingsofort nach dem Start des RKE2-Servers entfernen.
kubectl get nodes sollte dann erfolgreich ausgeführt werden. Wenn Ihre Serverknoten bereit sind, können Sie mit den Agent-Knoten fortfahren, um die Zertifikate neu zu generieren.
Führen Sie die folgenden Schritte auf den Agent-Knoten aus:
- Stoppen Sie den RKE2-Server:
systemctl stop rke2-agent.servicesystemctl stop rke2-agent.service - Löschen Sie alle verbleibenden RKE2-Prozesse:
rke2-killall.shrke2-killall.sh -
Um den Ablaufzeitraum der RKE2-Zertifikate anzupassen, verwenden Sie den folgenden Befehl. Beachten Sie, dass in diesem Beispiel der Gültigkeitszeitraum auf 1000 Tage festgelegt wird, Sie können diesen Wert jedoch basierend auf Ihren Anforderungen ändern.
SERVICE_NAME="rke2-agent.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reloadSERVICE_NAME="rke2-agent.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reload - Starten Sie den RKE2-Server neu:
systemctl start rke2-agent.servicesystemctl start rke2-agent.service
- Generieren einer Certificate Signing Request (CSR) und eines privaten Schlüssels
- Verwalten von Serverzertifikaten
- Aktualisieren der Clusterzertifikate
- Zugriff auf das TLS-Zertifikat
- Hinzufügen des Zertifizierungsstellenzertifikats zum Host-Truststore
- Verwalten zusätzlicher Zertifikate von Zertifizierungsstellen
- Aktualisieren der Zertifikate von Zertifizierungsstellen
- Zugriff auf das Zertifikat von einer Zertifizierungsstelle
- Hinzufügen des Zertifizierungsstellenzertifikats zum Host-Truststore
- Verwalten von Identitätstoken-Signaturzertifikaten
- Automatische Zertifikatsrotation
- Manuelles Aktualisieren des Zertifikats
- Manuelles Rotieren des Zertifikats
- Notfall-Zertifikatsrotation
- Zugreifen auf das Zertifikat
- Verwalten von RKE2-Zertifikaten
- Überprüfen des Ablaufdatums des RKE2-Zertifikats
- Rotieren des RKE2-Zertifikats
- Verwalten des externen OCI-konformen Registrierungszertifikats