- Vue d'ensemble (Overview)
- Prérequis
- Installation
- Post-installation
- Migration et mise à niveau
- Mise à niveau d'Automation Suite sur EKS/AKS
- Étape 1 : Déplacement des données d'organisation Identity d'installation autonome vers Automation Suite
- Étape 2 : Restauration de la base de données du produit autonome
- Étape 3 : Sauvegarder la base de données de la plate-forme dans Automation Suite
- Étape 4 : Fusion des organisations dans Automation Suite
- Étape 5 : Mise à jour des chaînes de connexion du produit migré
- Étape 6 : migration de la version autonome d'Orchestrator
- Étape 7 : Migration d’Insights en version autonome
- Étape 8 : suppression du locataire par défaut
- B) Migration à locataire unique
- Migration d'Automation Suite sur Linux vers Automation Suite sur EKS/AKS
- Surveillance et alerte
- Administration du cluster
- Configuration spécifique au produit
- Configuration des paramètres d'Orchestrator
- Paramètres de l'application Orchestrator
- Configuration des paramètres d'application
- Configuration de la taille maximale de la requête
- Remplacement de la configuration du stockage au niveau du cluster
- Configuration des magasins d'informations d'identification
- Configuration de la clé de chiffrement par locataire
- Nettoyer la base de données Orchestrator
- Rotation des informations d’identification de stockage d’objets blob
- Désactivation de l'utilisation d'URL pré-signées lors du téléchargement de données vers le stockage Amazon S3
- Configuration de la sécurité de l'application de processus
- Configurer une authentification Kerberos avec l’authentification MSSQL de base pour Process Mining
- Résolution des problèmes
- La configuration de sauvegarde ne fonctionne pas en raison d’un échec de connexion à Azure Government
- Pods dans l'espace de noms uipath bloqués lors de l'activation des rejets de nœuds personnalisés
- Impossible de lancer Automation Hub et Apps avec la configuration proxy
- Les pods ne peuvent pas communiquer avec le nom de domaine complet dans un environnement proxy
- La chaîne de connexion SQL de l’automatisation de test est ignorée
Sécurité et conformité
Cette section fournit des détails sur le contexte de sécurité des services UiPath®.
spec
. L’exemple suivant présente la configuration de l’ensemble des services, à l’exception de 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
, la valeur du paramètre readOnlyRootFilesystem
est false
. Pour plus d'informations sur du-cjk-ocr
, consultez la documentation Document Understanding.
Dans certains cas, les ID d'utilisateur et les ID de groupe peuvent être supérieurs ou égaux à 1000. Ces valeurs sont autorisées en fonction de votre environnement. Il est important de configurer les ID d'utilisateur et de groupe en fonction de vos principes de sécurité et des directives de sécurité de votre organisation.
Automation Suite est préconfiguré avec Gatekeeper et les stratégies OPA. Si vous apportez votre propre composant Gatekeeper et les stratégies OPA, vous pouvez ignorer ces composants lors de l’installation d’Automation Suite. Pour plus de détails, consultez la section Pile d’Automation Suite. Dans ce cas, passez en revue les stratégies OPA et les exceptions nécessaires à l’installation et à l’exécution d’Automation Suite.
-uipath
, uipath-installer
, uipath-infra
, airflow
et argocd
.
Policy |
Actionsd’application |
Espaces de noms/images à exclure |
---|---|---|
Contrôle la restriction de l’escalade aux privilèges root. Correspond au champ
allowPrivilegeEscalation dans PodSecurityPolicy
|
|
|
Configure une liste d'autorisation de profils Apparmor à utiliser par les conteneurs. Cela correspond à des annotations spécifiques appliquées à PodSecurityPolicy. |
|
|
Contrôle les capacités Linux sur les conteneurs. Correspond aux champs
allowedCapabilities et requiredDropCapabilities dans PodSecurityPolicy.
|
|
|
Contrôle la liste d’autorisation des pilotes FlexVolume. Correspond au champ
allowedFlexVolumes dans PodSecurityPolicy.
|
|
|
|
| |
Contrôle l'attribution d'un FSGroup qui possède les volumes du pod. Correspond au champ
fsGroup dans PodSecurityPolicy.
|
|
|
Contrôle l’utilisation du système de fichiers hôte. Correspond au champ
allowedHostPaths dans PodSecurityPolicy.
|
|
|
Interdit le partage des espaces de noms PID et IPC de l'hôte par les conteneurs de pods. Correspond aux champs
hostPID et hostIPC dans PodSecurityPolicy.
|
|
|
Contrôle l'utilisation de l'espace de noms du réseau hôte par les conteneurs de pods. |
|
|
Contrôle la capacité de n'importe quel conteneur à activer le mode privilégié. Correspond au champ
privileged dans PodSecurityPolicy.
|
|
|
Contrôle les types
procMount autorisés pour le conteneur. Correspond au champ allowedProcMountTypes d'une PodSecurityPolicy.
|
|
|
Nécessite l'utilisation d'un système de fichiers racine en lecture seule par les conteneurs de pods. |
|
|
Contrôle le profil seccomp utilisé par les conteneurs. Correspond à l'annotation
seccomp.security.alpha.kubernetes.io/allowedProfileNames sur PodSecurityPolicy.
|
|
|
Définit une liste d'autorisation de configurations seLinuxOptions pour les conteneurs de pods. |
|
|
Contrôle les ID d'utilisateur et de groupe du conteneur et de certains volumes. |
|
|
Limite les types de volumes montables à ceux spécifiés par l'utilisateur. |
|
|
-
L'espace de noms
dapr-system
n'est nécessaire que si vous installez Process Mining et Task Mining. -
L'espace de noms
airflow
n'est nécessaire que si vous installez Process Mining.
Policy |
Actionsd’application |
Espaces de noms/images à exclure |
---|---|---|
Contrôle la capacité de n'importe quel pod à activer
automountServiceAccountToken .
|
|
|
Exige que les images de conteneur commencent par une chaîne de la liste spécifiée. |
|
|
|
|
S/O |
Interdit tous les services de type LoadBalancer. |
|
|
Interdit tous les services de type NodePort. |
|
|
Les utilisateurs ne doivent pas pouvoir créer des entrées avec un nom d'hôte vide ou générique (*), car cela leur permettrait d'intercepter le trafic pour d'autres services du cluster, même s'ils n'ont pas accès à ces services. |
|
|
Exige que les conteneurs aient des limites de mémoire et de processeur définies. Contraint les limites à respecter les valeurs maximales spécifiées. |
|
|
Nécessite que les requêtes de mémoire et de processeur des conteneurs soient définies. Contraint les requêtes à se situer dans les valeurs maximales spécifiées. |
|
|
Définit un ratio maximal entre les limites des ressources de conteneur et les requêtes. |
|
|
Nécessite que les conteneurs aient des ressources définies. |
|
|
Interdit d’associer les ressources ClusterRole et Role à l’utilisateur
system:anonymous et au groupe system:unauthenticated .
|
|
S/O |
Exige que les images de conteneur aient une balise d'image différente de celles de la liste spécifiée. |
|
S/O |
Exige que les conteneurs aient une limite de stockage éphémère définie et que la limite se situe dans les valeurs maximales spécifiées. |
|
|
|
|
S/O |
Exige que les ressources Ingress soient uniquement HTTPS. Les ressources d'entrée doivent inclure l'annotation
kubernetes.io/ingress.allow-http , définie sur false . Par défaut, une configuration TLS {} valide est requise. Cela peut être rendu facultatif en définissant le paramètre tlsOptional sur true .
|
|
|
Les images de conteneur doivent contenir un résumé. |
|
|
Bloque la mise à jour du compte de service sur les ressources qui extraient les pods. Cette stratégie est ignorée en mode audit. |
|
S/O |
|
|
|
Les pods doivent disposer de sondes de disponibilité et/ou de vitalité. |
|
|
Les classes de stockage doivent être spécifiées lors de l'utilisation. |
|
S/O |
Nécessite que tous les hôtes de règles Ingress soient uniques. |
|
S/O |
Nécessite que les services aient des sélecteurs uniques dans un espace de noms. Les sélecteurs sont considérés comme identiques s'ils ont des clés et des valeurs identiques. Les sélecteurs peuvent partager une paire clé/valeur tant qu’il existe au moins une paire clé/valeur distincte entre eux. |
|
S/O |
-
L'espace de noms
dapr-system
n'est nécessaire que si vous installez Process Mining et Task Mining. -
L'espace de noms
airflow
n'est nécessaire que si vous installez Process Mining. -
prereq**
sont des espaces de noms temporaires créés lors de l'exécution d'un prérequis ou d'une vérification de l'état. Les espaces de noms s'auto-suppriment une fois terminés.
network-policies
sous la liste exclude components
dans input.json
. Pour en savoir plus sur les composants facultatifs, consultez la pile Automation Suite.
uipath
. Si vous apportez vos propres stratégies réseau ou si vous avez un CNI personnalisé (par ex., Cilium Enterprise ou Calico Tigera Enterprise), veillez à mettre à jour vos stratégies pour qu'elles reflètent le graphique Helm network-policies
.
network-policies
en exécutant la commande suivante.
- Vous devez remplacer
<automation-suite-version>
par votre version actuelle d'Automation Suite dans la commande suivante. - Vous devez décompresser le fichier pour extraire le graphique Helm.
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
sur votre nœud de gestion afin d'installer et de gérer Automation Suite sur votre cluster dédié. Ce niveau d'accès est nécessaire pour les composants de niveau système dans Automation Suite, tels qu'Istio (routage/service mesh) et ArgoCD (déploiement et gestion du cycle de vie des applications), et pour créer des espaces de noms liés à Automation Suite.
La norme FIPS 140-2 (Federal Information Processing Standards 140-2) est une norme de sécurité qui valide l'efficacité des modules cryptographiques.
Automation Suite sur AKS peut s'exécuter sur des nœuds compatibles FIPS 140-2.
Vous pouvez activer FIPS 140-2 sur les nœuds AKS sur lesquelles vous installez Automation Suite dans les scénarios suivants :
- Scénario 1 : nouvelles installations - Activez FIPS 140-2 avant d’effectuer une nouvelle installation d’Automation Suite 2023.4 ou version ultérieure.
- Scénario 2 : installations existantes - Activez FIPS 140-2 après avoir effectué une installation d'Automation Suite sur une machine avec FIPS-140-2 désactivé.
Pour activer FIPS 140-2 sur les machines sur lesquelles vous prévoyez d'effectuer une nouvelle installation d'Automation Suite, procédez comme suit :
Vous pouvez installer Automation Suite sur des machines avec FIPS 140-2 désactivée, puis activer la norme de sécurité sur ces mêmes machines. Cela est également possible lorsque vous effectuez une mise à niveau vers une nouvelle version d'Automation Suite.
Pour activer FIPS 140-2 sur les machines sur lesquelles vous avez déjà effectué une installation d'Automation Suite, procédez comme suit :