Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Problèmes connus
-
(2024.12 et 2024.12.01) Échec de Regex lors de l'enregistrement d'un nouvel utilisateur de Cognito
(2024.08) Préparation à une défaillance de l'AMI d'infrastructure
(2024.06) L'application d'un instantané échoue lorsque le nom du groupe AD contient des espaces
(2024.04 et 2024.04.01) Échec de la suppression RES dans GovCloud
(2024.04 - 2024.04.02) Le bureau virtuel Linux peut être bloqué à l'état « REPRISE » au redémarrage
(2024.04.02 et versions antérieures) La clé privée pour accéder à l'hôte Bastion n'est pas valide
Problèmes connus 2024.x
........................
(2024.12 et 2024.12.01) Échec de Regex lors de l'enregistrement d'un nouvel utilisateur de Cognito
Description du bogue
Si vous tentez d'enregistrer des utilisateurs de AWS Cognito via le portail Web dont le préfixe d'e-mail contient » . «, par exemple<firstname>.<lastname>@<company>.com, cela provoquera une erreur indiquant que le nom d'utilisateur de Cognito ne correspond pas au modèle d'expression régulière défini.
Cette erreur est due au fait que RES génère automatiquement des noms d'utilisateur à partir du préfixe de courrier électronique de l'utilisateur. Cependant, les noms d'utilisateur marqués de «. » ne sont pas des utilisateurs valides pour les VDI dans certaines distributions Linux prises en charge par RES. Ce correctif supprime tout «. » dans le préfixe d'e-mail lors de la génération d'un nom d'utilisateur afin que le nom d'utilisateur soit valide sur les VDI RES Linux.
Versions concernées
Versions RES 2024.12 et 2024.12.01
Mitigation
-
Exécutez les commandes suivantes pour télécharger
patch.pyetcognito_sign_up_email_fix.patchpour la version 2024.12 oucognito_sign_up_email_fix.patchpour la version 2024.12.01, en les<output-directory>remplaçant par le répertoire dans lequel vous souhaitez télécharger le script de correctif et le fichier de correctif, et par le nom de votre<environment-name>environnement RES :-
Le correctif s'applique aux normes RES 2024.12 et 2024.12.01.
-
Le script de correctif nécessite la AWS CLI v2, Python 3.9.16 ou supérieur et Boto3.
-
Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES.
OUTPUT_DIRECTORY=<output-directory> ENVIRONMENT_NAME=<environment-name> RES_VERSION=<res-version> # either 2024.12 or 2024.12.01 mkdir -p ${OUTPUT_DIRECTORY} curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/${RES_VERSION}/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/${RES_VERSION}/patch_scripts/patches/cognito_sign_up_email_fix.patch --output ${OUTPUT_DIRECTORY}/cognito_sign_up_email_fix.patch -
-
Accédez au répertoire dans lequel le script de correctif et le fichier de correctif ont été téléchargés. Exécutez la commande de correctif suivante :
python3 ${OUTPUT_DIRECTORY}/patch.py --environment-name ${ENVIRONMENT_NAME} --res-version ${RES_VERSION} --module cluster-manager --patch ${OUTPUT_DIRECTORY}/cognito_sign_up_email_fix.patch -
Redémarrez l'instance de Cluster Manager pour votre environnement. Vous pouvez également mettre fin à l'instance depuis la console de gestion Amazon EC2.
INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-cluster-manager \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID} -
Vérifiez l'état de l'instance de Cluster Manager en vérifiant l'activité du groupe de dimensionnement automatique en commençant par son nom
<RES-EnvironmentName>-cluster-manager-asg. Attendez que la nouvelle instance soit lancée avec succès.
........................
(2024.12.01 et versions antérieures) Erreur de mauvais certificat non valide lors de la connexion au VDI à l'aide d'un domaine personnalisé
Description du bogue
Lorsque vous déployez la recette External Resources et RES avec un nom de domaine de portail personnalisé, vous CertificateRenewalNode ne parvenez pas à actualiser le certificat TLS pour la connexion VDI avec l'erreur suivante dans : /var/log/user-data.log
{ "type": "urn:ietf:params:acme:error:unauthorized", "detail": "Error finalizing order :: OCSP must-staple extension is no longer available: see https://letsencrypt.org/2024/12/05/ending-ocsp", "status": 403 }
Par conséquent, vous rencontrerez une erreur indiquant net::ERR_CERT_DATE_INVALID (Chrome) ou Error code: SSL_ERROR_BAD_CERT_DOMAIN (FireFox) lorsque vous vous connectez à vos VDI sur le portail Web RES.
Versions concernées
2024.12.01 et versions antérieures
Mitigation
-
Accédez à la console EC2. Si une instance est nommée
CertificateRenewalNode-, mettez-la hors service. -
Accédez à la console Lambda. Ouvrez le code source de la fonction Lambda nommée.
-CertificateRenewalLambda-Identifiez la ligne commençant par./acme.sh --issue --dns dns_aws --ocsp-must-staple --keylength 4096et supprimez l'--ocsp-must-stapleargument. -
Sélectionnez Déployer et attendez que le changement de code prenne effet.
-
Pour déclencher manuellement la fonction Lambda : allez dans l'onglet Test, puis sélectionnez Test. Aucune saisie supplémentaire n'est requise. Cela devrait créer une instance de certificat EC2 qui met à jour le certificat et PrivateKey les secrets dans Secret Manager. L'instance sera automatiquement résiliée une fois les secrets mis à jour.
-
Mettez fin à l'instance dcv-gateway existante :
<env-name>-vdc-gatewayet attendez que le groupe auto scaling en déploie automatiquement une nouvelle.
Détails de l'erreur
Let's Encrypt mettra fin au support OCSP en 2025. À compter du 30 janvier 2025, les Must-Staple demandes OCSP échoueront sauf si le compte demandeur a préalablement émis un certificat contenant l'extension OCSP Must Staple. Vérifiez https://letsencrypt.org/2024/12/05/ending-ocsp/
........................
(2024.12 et 2024.12.01) Les utilisateurs d'Active Directory ne peuvent pas se connecter par SSH à Bastion Host
Description du bogue
Les utilisateurs d'Active Directory reçoivent un message d'erreur de refus d'autorisation lorsqu'ils se connectent à l'hôte Bastion en suivant les instructions du portail Web RES.
L'application Python qui s'exécute sur l'hôte Bastion ne parvient pas à lancer le service SSSD en raison d'une variable d'environnement manquante. Par conséquent, les utilisateurs d'AD sont inconnus du système d'exploitation et ne peuvent pas se connecter.
Versions concernées
2024.12 et 2024.12.01
Mitigation
-
Connectez-vous à l'instance Bastion Host depuis la console EC2.
-
Modifiez
/etc/environmentet ajoutezenvironment_name=<res-environment-name>une nouvelle ligne sous IDEA_CLUSTER_NAME. -
Exécutez les commandes suivantes sur l'instance :
source /etc/environment sudo service supervisord restart sudo systemctl restart supervisord -
Réessayez de vous connecter à l'hôte Bastion en suivant les instructions du portail Web RES.
........................
(2024.10) L'arrêt automatique du VDI est interrompu pour les environnements RES déployés dans des VPC isolés
Description du bogue
Avec la version 2024.10 RES, l'arrêt automatique des VDI a été ajouté pour les VDI inactifs pendant un certain temps. Ce paramètre peut être configuré dans Paramètres du bureau → Serveur → Session.
L'arrêt automatique VDI n'est actuellement pas pris en charge pour les environnements RES déployés dans des VPC isolés.
Versions concernées
2024,10
Mitigation
Nous travaillons actuellement sur un correctif qui sera inclus dans une future version. Cependant, il est toujours possible d'arrêter manuellement les VDI dans les environnements RES déployés dans des VPC isolés.
........................
(2024.10 et versions antérieures) Impossible de lancer VDI pour les types d'instances Graphic Enhanced
Description du bogue
Lorsqu'un VDI Amazon Linux 2 - x86_64, RHEL 8 - x86_64 ou RHEL 9 x86_64 est lancé sur un type d'instance graphique amélioré (g4, g5), l'instance reste bloquée dans l'état de provisionnement. Cela signifie que l'instance n'atteindra jamais l'état « Prêt » et ne sera jamais disponible pour la connexion.
Cela se produit parce que le serveur X n'instancie pas correctement sur les instances. Après avoir appliqué ce correctif, nous vous suggérons également d'augmenter la taille du volume racine de vos piles logicielles pour les instances graphiques à 50 Go afin de garantir un espace suffisant pour installer toutes les dépendances.
Versions concernées
Toutes les versions RES 2024.10 ou antérieures.
Mitigation
-
Téléchargez les fichiers patch.py
et graphic_enhanced_instance_types_fix.patch en les remplaçant <output-directory>par le répertoire dans lequel vous souhaitez télécharger le script et le fichier de correctif et par le nom de votre environnement RES dans la commande ci-dessous :<environment-name>Le correctif ne s'applique qu'à RES 2024.10.
Le script de correctif nécessite la AWS CLI v2, Python 3.9.16 ou supérieur et Boto3.
Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES.
OUTPUT_DIRECTORY=<output-directory> ENVIRONMENT_NAME=<environment-name> mkdir -p ${OUTPUT_DIRECTORY} curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.10/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.10/patch_scripts/patches/graphic_enhanced_instance_types_fix.patch --output ${OUTPUT_DIRECTORY}/graphic_enhanced_instance_types_fix.patch -
Accédez au répertoire dans lequel le script de correctif et le fichier de correctif ont été téléchargés. Exécutez la commande de correctif suivante :
python3 ${OUTPUT_DIRECTORY}/patch.py --environment-name ${ENVIRONMENT_NAME} --res-version 2024.10 --module virtual-desktop-controller --patch ${OUTPUT_DIRECTORY}/graphic_enhanced_instance_types_fix.patch -
Pour mettre fin à l'instance Virtual Desktop Controller (vdc-controller) de votre environnement, exécutez les commandes suivantes en remplaçant le nom de votre environnement RES comme indiqué.
INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-vdc-controller \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID} -
Lancez une nouvelle instance une fois que le groupe cible commençant par le nom
<RES-EnvironmentName>-vdc-extest devenu sain. Nous recommandons que toutes les nouvelles piles logicielles que vous enregistrez pour les instances graphiques disposent d'au moins 50 Go de stockage.
........................
(2024.08) Préparation à une défaillance de l'AMI d'infrastructure
Description du bogue
Lorsque vous préparez des AMI à l'aide d'EC2 Image Builder conformément aux instructions répertoriées dans la documentation des prérequis, le processus de création échoue avec le message d'erreur suivant :
CmdExecution: [ERROR] Command execution has resulted in an error
Cela est dû à des erreurs dans le fichier de dépendances fourni dans la documentation.
Versions concernées
2024,08
Mitigation
Créez de nouvelles ressources EC2 Image Builder :
(Suivez ces étapes si vous n'avez jamais préparé d'AMI pour les instances RES)
-
Téléchargez le fichier res-installation-scripts.tar.gz mis à jour.
-
Suivez les étapes répertoriées sous Préparer les images Amazon Machine (AMI) sur la page des conditions préalables.
Réutilisation des ressources précédentes d'EC2 Image Builder :
(Suivez ces étapes si vous avez préparé des AMI pour les instances RES)
-
Téléchargez le fichier res-installation-scripts.tar.gz mis à jour.
-
Accédez à EC2 Image Builder → Composants → Cliquez sur le composant créé pour préparer les AMI RES.
-
Notez l'emplacement S3 indiqué sous Contenu → DownloadRESInstallScripts étape → entrées → source.
-
L'emplacement S3 ci-dessus contient le fichier de dépendances précédemment utilisé. Remplacez ce fichier par le fichier téléchargé lors de la première étape.
........................
(2024.08) Les bureaux virtuels ne parviennent pas à monter le compartiment read/write Amazon S3 avec l'ARN du compartiment racine et un préfixe personnalisé
Description du bogue
Research and Engineering Studio 2024.08 ne parvient pas à monter des compartiments read/write S3 sur une instance d'infrastructure de bureau virtuel (VDI) lorsqu'il utilise un ARN de bucket racine (c'est-à-direarn:aws:s3:::example-bucket) et un préfixe personnalisé (nom du projet ou nom du projet et nom d'utilisateur).
Les configurations de bucket qui ne sont pas concernées par ce problème sont les suivantes :
-
compartiments en lecture seule
-
read/write compartiments avec un préfixe intégré à l'ARN du bucket (c'est-à-dire
arn:aws:s3:::example-bucket/example-folder-prefix) et un préfixe personnalisé (nom du projet ou nom du projet et nom d'utilisateur) -
read/write buckets avec un ARN de bucket racine, mais sans préfixe personnalisé
Une fois que vous avez provisionné une instance VDI, le répertoire de montage spécifié pour ce compartiment S3 ne comportera pas de compartiment monté. Bien que le répertoire de montage du VDI soit présent, il sera vide et ne contiendra pas le contenu actuel du bucket. Lorsque vous écrivez un fichier dans le répertoire à l'aide du terminal, l'erreur Permission denied,
unable to write a file est générée et le contenu du fichier n'est pas transféré dans le compartiment S3 correspondant.
Versions concernées
2024,08
Mitigation
-
Pour télécharger le script de correctif et le fichier de correctif (
patch.pyets3_mount_custom_prefix_fix.patch), exécutez la commande suivante en les<output-directory>remplaçant par le répertoire dans lequel vous souhaitez télécharger le script de correctif et le fichier de correctif et<environment-name>par le nom de votre environnement RES :-
Le correctif ne s'applique qu'à RES 2024.08.
-
Le script de correctif nécessite la AWS CLI v2, Python 3.9.16 ou supérieur et Boto3.
-
Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations Amazon S3 pour écrire dans le compartiment créé par RES.
OUTPUT_DIRECTORY=<output-directory> ENVIRONMENT_NAME=<environment-name> mkdir -p ${OUTPUT_DIRECTORY} curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.08/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.08/patch_scripts/patches/s3_mount_custom_prefix_fix.patch --output ${OUTPUT_DIRECTORY}/s3_mount_custom_prefix_fix.patch -
-
Accédez au répertoire dans lequel le script de correctif et le fichier de correctif sont téléchargés. Exécutez la commande de correctif suivante :
python3 ${OUTPUT_DIRECTORY}/patch.py --environment-name ${ENVIRONMENT_NAME} --res-version 2024.08 --module virtual-desktop-controller --patch ${OUTPUT_DIRECTORY}/s3_mount_custom_prefix_fix.patch -
Pour mettre fin à l'instance de Virtual Desktop Controller (vdc-controller) de votre environnement, exécutez les commandes suivantes. (Vous avez déjà défini le nom de votre environnement RES à la
ENVIRONMENT_NAMEvariable lors de la première étape.)INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-vdc-controller \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}Note
Pour les configurations VPC privées, si ce n'est pas déjà fait, pour la
<RES-EnvironmentName>-vdc-custom-credential-broker-lambdafonction, assurez-vous d'ajouter le nomAWS_STS_REGIONAL_ENDPOINTSet laEnvironment variablevaleur de.regionalPour plus d’informations, consultez Conditions requises pour les compartiments Amazon S3 pour les déploiements de VPC isolés. -
Une fois que le groupe cible commençant par le nom
sera rétabli, de nouveaux VDI devront être lancés. Les compartiments read/write S3 dotés de l'ARN du bucket racine et d'un préfixe personnalisé devront être correctement montés.<RES-EnvironmentName>-vdc-ext
........................
(2024.06) L'application d'un instantané échoue lorsque le nom du groupe AD contient des espaces
Problème
RES 2024.06 ne parvient pas à appliquer les instantanés des versions précédentes si les noms des groupes AD contiennent des espaces.
Les journaux du gestionnaire de clusters (sous le /<environment-name>/cluster-manager groupe de CloudWatch journaux) incluront l'erreur suivante lors de la synchronisation AD :
[apply-snapshot] authz.role-assignments/<Group name with spaces>:group#<projectID>:project FAILED_APPLY because: [INVALID_PARAMS] Actor key doesn't match the regex pattern ^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{1,20}:(user|group)$
L'erreur est due au fait que RES n'accepte que les noms de groupes répondant aux exigences suivantes :
Il ne peut contenir que des lettres ASCII minuscules et majuscules, des chiffres, un tiret (-), un point (.) et un trait de soulignement (_)
Le tiret (-) n'est pas autorisé comme premier caractère
Il ne doit pas contenir d'espace.
Versions concernées
2024,06
Mitigation
-
Pour télécharger le script de correctif et le fichier de correctif (patch.py
et groupname_regex.patch ), exécutez la commande suivante, en les <output-directory>remplaçant par le répertoire dans lequel vous souhaitez placer les fichiers et par le nom de votre environnement<environment-name>RES :-
Le correctif ne s'applique qu'à RES 2024.06
-
Le script de correctif nécessite la AWS CLI v2, Python 3.9.16 ou supérieur et Boto3.
-
Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES :
OUTPUT_DIRECTORY=<output-directory>ENVIRONMENT_NAME=<environment-name>mkdir -p ${OUTPUT_DIRECTORY} curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.06/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.06/patch_scripts/patches/groupname_regex.patch --output ${OUTPUT_DIRECTORY}/groupname_regex.patch
-
-
Accédez au répertoire dans lequel le script de correctif et le fichier de correctif sont téléchargés. Exécutez la commande de correctif suivante :
python3 patch.py --environment-name ${ENVIRONMENT_NAME} --res-version 2024.06 --module cluster-manager --patch ${OUTPUT_DIRECTORY}/groupname_regex.patch -
Pour redémarrer l'instance de Cluster Manager pour votre environnement, exécutez les commandes suivantes : Vous pouvez également mettre fin à l'instance depuis la console de gestion Amazon EC2.
INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-cluster-manager \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}
Note
Le correctif permet aux noms de groupes AD de contenir des lettres ASCII minuscules et majuscules, des chiffres, des tirets (-), des points (.), des traits de soulignement (_) et des espaces d'une longueur totale comprise entre 1 et 30 inclus.
........................
(2024.06 et versions antérieures) Les membres du groupe ne sont pas synchronisés avec RES lors de la synchronisation AD
Description du bogue
Les membres du groupe ne se synchroniseront pas correctement avec RES si le GroupOU est différent de l'UserOU.
RES crée un filtre ldapsearch lorsqu'il tente de synchroniser les utilisateurs d'un groupe AD. Le filtre actuel utilise incorrectement le paramètre UserOu au lieu du paramètre GroupOu. Le résultat est que la recherche ne renvoie aucun utilisateur. Ce comportement ne se produit que dans les cas où UserSOU et GroupOu sont différents.
Versions concernées
Toutes les versions RES 2024.06 ou antérieures
Mitigation
Pour résoudre le problème, procédez comme suit :
-
Pour télécharger le script patch.py et le fichier group_member_sync_bug_fix.patch, exécutez les commandes suivantes, en les remplaçant par
<output-directory>le répertoire local dans lequel vous souhaitez télécharger les fichiers et par la version de RES que vous souhaitez patcher :<res_version>Note
-
Le script de correctif nécessite la AWS CLI v2, Python 3.9.16 ou supérieur et Boto3.
-
Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES.
-
Le correctif ne prend en charge que les versions RES 2024.04.02 et 2024.06. Si vous utilisez le 2024.04 ou le 2024.04.01, vous pouvez suivre les étapes répertoriées dans la section pour mettre à jour votre environnement Mises à jour mineures des versions vers le 2024.04.02 avant d'appliquer le correctif.
-
Version RES : RES 2024.04.02
Lien de téléchargement du correctif : 2024.04.02_group_member_sync_bug_fix.patch
-
Version RES : RES 2024.06
Lien de téléchargement du correctif : 2024.06_group_member_sync_bug_fix.patch
-
OUTPUT_DIRECTORY=<output-directory>RES_VERSION=<res_version>mkdir -p ${OUTPUT_DIRECTORY} curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/${RES_VERSION}/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/${RES_VERSION}/patch_scripts/patches/${RES_VERSION}_group_member_sync_bug_fix.patch --output ${OUTPUT_DIRECTORY}/${RES_VERSION}_group_member_sync_bug_fix.patch -
-
Accédez au répertoire dans lequel le script de correctif et le fichier de correctif sont téléchargés. Exécutez la commande de correctif suivante, en la
<environment-name>remplaçant par le nom de votre environnement RES :cd ${OUTPUT_DIRECTORY} ENVIRONMENT_NAME=<environment-name>python3 patch.py --environment-name ${ENVIRONMENT_NAME} --res-version ${RES_VERSION} --module cluster-manager --patch $PWD/${RES_VERSION}_group_member_sync_bug_fix.patch -
Pour redémarrer l'instance de cluster-manager de votre environnement, exécutez les commandes suivantes :
INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-cluster-manager \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}
........................
(2024.06 et versions antérieures) CVE-2024-6387, Regresshion, vulnérabilité de sécurité dans RHEL9 et Ubuntu VDI
Description du bogue
CVE-2024-6387
Pour RES, la configuration standard consiste à passer par l'hôte bastion pour accéder en SSH aux bureaux virtuels, et l'hôte bastion n'est pas affecté par cette vulnérabilité. Cependant, l'AMI (Amazon Machine Image) par défaut que nous fournissons pour RHEL9 et Ubuntu2024 VDI (infrastructure de bureau virtuel) dans TOUTES les versions RES utilise une version OpenSSH vulnérable aux menaces de sécurité.
Cela signifie que les VDI RHEL9 et Ubuntu2024 existants pourraient être exploitables, mais que l'attaquant aurait besoin d'accéder à l'hôte du bastion.
Vous trouverez plus de détails sur le problème ici
Versions concernées
Toutes les versions RES 2024.06 ou antérieures.
Mitigation
RHEL9 et Ubuntu ont publié des correctifs pour OpenSSH qui corrigent la faille de sécurité. Ils peuvent être extraits à l'aide du gestionnaire de packages correspondant à la plateforme.
Si vous avez des VDI RHEL9 ou Ubuntu existants, nous vous recommandons de suivre les instructions PATCH EXISTING VDI ci-dessous. Pour appliquer des correctifs aux futurs VDI, nous vous recommandons de suivre les instructions de PATCH FUTURE VDI. Ces instructions décrivent comment exécuter un script pour appliquer la mise à jour de la plateforme à vos VDI.
APPLIQUER DES CORRECTIFS AUX VDI EXISTANTS
-
Exécutez la commande suivante pour patcher tous les VDI Ubuntu et RHEL9 existants :
-
Le script de correctif nécessite la AWS CLI v2.
-
Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations de AWS Systems Manager pour envoyer une commande d'exécution de Systems Manager.
aws ssm send-command \ --document-name "AWS-RunRemoteScript" \ --targets "Key=tag:res:NodeType,Values=virtual-desktop-dcv-host" \ --parameters '{"sourceType":["S3"],"sourceInfo":["{\"path\":\"https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.06/patch_scripts/scripts/patch_openssh.sh\"}"],"commandLine":["bash patch_openssh.sh"]}'
-
-
Vous pouvez vérifier que le script a bien été exécuté sur la page Exécuter la commande
. Cliquez sur l'onglet Historique des commandes, sélectionnez l'ID de commande le plus récent et vérifiez que tous les ID d'instance comportent un message de réussite.
APPLIQUEZ DES CORRECTIFS AUX FUTURS VDI
-
Pour télécharger le script de correctif et le fichier de correctif (patch.py
et update_openssh.patch ), exécutez les commandes suivantes, en les <output-directory>remplaçant par le répertoire dans lequel vous souhaitez télécharger les fichiers et<environment-name>par le nom de votre environnement RES :Note
-
Le correctif ne s'applique qu'à RES 2024.06.
-
Le script de correctif nécessite AWS CLI (v2), Python 3.9.16 ou supérieur et Boto3.
-
Configurez votre copie de la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES.
OUTPUT_DIRECTORY=<output-directory>ENVIRONMENT_NAME=<environment-name>curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.06/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.06/patch_scripts/patches/update_openssh.patch --output ${OUTPUT_DIRECTORY}/update_openssh.patch -
-
Exécutez la commande de correctif suivante :
python3 ${OUTPUT_DIRECTORY}/patch.py --environment-name ${ENVIRONMENT_NAME} --res-version 2024.06 --module virtual-desktop-controller --patch ${OUTPUT_DIRECTORY}/update_openssh.patch -
Redémarrez l'instance du contrôleur VDC pour votre environnement à l'aide des commandes suivantes :
INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-vdc-controller \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}
Important
L'application de correctifs aux futurs VDI n'est prise en charge que sur les versions RES 2024.06 et ultérieures. Pour appliquer des correctifs aux futurs VDI dans des environnements RES dont les versions sont antérieures à 2024.06, commencez par mettre à niveau l'environnement RES vers 2024.06 en suivant les instructions fournies à l'adresse :. Mises à jour majeures des versions
........................
(2024.04-2024.04.02) La limite d'autorisation IAM fournie n'est pas attachée au rôle des instances VDI
Le problème
Les sessions de bureau virtuel n'héritent pas correctement de la configuration des limites d'autorisation de leur projet. Cela est dû au fait que la limite d'autorisation définie par le IAMPermissionBoundary paramètre n'a pas été correctement attribuée à un projet lors de sa création.
Versions concernées
2024,04 - 2024,04.02
Mitigation
Procédez comme suit pour permettre aux VDI d'hériter correctement de la limite d'autorisations attribuée à un projet :
-
Pour télécharger le script de correctif et le fichier de correctif (patch.py
et vdi_host_role_permission_boundary.patch ), exécutez la commande suivante, en les remplaçant par le répertoire local dans lequel vous souhaitez placer les fichiers : <output-directory>-
Le correctif ne s'applique qu'à RES 2024.04.02. Si vous utilisez la version 2024.04 ou 2024.04.01, vous pouvez suivre les étapes répertoriées dans le document public pour les mises à jour de version mineures afin de mettre à jour votre environnement vers la version 2024.04.02.
-
Le script de correctif nécessite AWS CLI (v2), Python 3.9.16 ou supérieur et Boto3.
-
Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES.
OUTPUT_DIRECTORY=<output-directory>curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.04.02/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.04.02/patch_scripts/patches/vdi_host_role_permission_boundary.patch --output ${OUTPUT_DIRECTORY}/vdi_host_role_permission_boundary.patch -
-
Accédez au répertoire dans lequel le script de correctif et le fichier de correctif sont téléchargés. Exécutez la commande de correctif suivante, en la
<environment-name>remplaçant par le nom de votre environnement RES :python3 patch.py --environment-name<environment-name>--res-version 2024.04.02 --module cluster-manager --patch vdi_host_role_permission_boundary.patch -
Redémarrez l'instance de cluster-manager dans votre environnement en exécutant cette commande, en la
<environment-name>remplaçant par le nom de votre environnement RES. Vous pouvez également mettre fin à l'instance depuis la console de gestion Amazon EC2.ENVIRONMENT_NAME=<environment-name>INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-cluster-manager \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}
........................
(2024.04.02 et versions antérieures) Les instances Windows NVIDIA dans ap-southeast-2 (Sydney) ne démarrent pas
Le problème
Les Amazon Machine Images (AMI) sont utilisées pour créer des bureaux virtuels (VDI) dans RES avec des configurations spécifiques. Chaque AMI possède un identifiant associé qui diffère selon les régions. L'ID AMI configuré dans RES pour lancer des instances Windows Nvidia dans ap-southeast-2 (Sydney) est actuellement incorrect.
AMI-ID ami-0e190f8939a996cafpour ce type d'instance, la configuration est incorrectement répertoriée dans ap-southeast-2 (Sydney). L'ID AMI ami-027cf6e71e2e442f4 doit être utilisé à la place.
Les utilisateurs obtiendront le message d'erreur suivant lorsqu'ils essaieront de lancer une instance avec l'ami-0e190f8939a996cafAMI par défaut.
An error occured (InvalidAMIID.NotFound) when calling the RunInstances operation: The image id ‘[ami-0e190f8939a996caf]’ does not exist
Étapes pour reproduire le bogue, y compris un exemple de fichier de configuration :
Déployez RES dans la région ap-southeast-2.
Lancez une instance à l'aide de la pile logicielle Windows-NVIDIA par défaut (ID AMI
ami-0e190f8939a996caf).
Versions concernées
Toutes les versions de RES 2024.04.02 ou antérieures sont concernées
Mitigation
Les mesures d'atténuation suivantes ont été testées sur la version RES 2024.01.01 :
-
Enregistrez une nouvelle pile logicielle avec les paramètres suivants
ID D'AMI :
ami-027cf6e71e2e442f4Système d'exploitation : Windows
Fabricant du GPU : NVIDIA
Minimum. Taille de stockage (Go) : 30
Minimum. RAM (GO) : 4
Utilisez cette pile logicielle pour lancer Windows-NVIDIA des instances
........................
(2024.04 et 2024.04.01) Échec de la suppression RES dans GovCloud
Le problème
Pendant le processus de suppression RES, le UnprotectCognitoUserPool Lambda désactive la protection contre la suppression pour les groupes d'utilisateurs de Cognito qui seront supprimés ultérieurement. L'exécution Lambda est démarrée par le. InstallerStateMachine
En raison des différences de version de la AWS CLI par défaut entre la version commerciale et les GovCloud régions, l'update_user_poolappel dans le Lambda échouera dans les GovCloud régions.
Les clients recevront le message d'erreur suivant lorsqu'ils tenteront de supprimer RES dans une GovCloud région :
Parameter validation failed: Unknown parameter in input: \"DeletionProtection\", must be one of: UserPoolId, Policies, LambdaConfig, AutoVerifiedAttributes, SmsVerificationMessage, EmailVerificationMessage, EmailVerificationSubject, VerificationMessageTemplate, SmsAuthenticationMessage, MfaConfiguration, DeviceConfiguration, EmailConfiguration, SmsConfiguration, UserPoolTags, AdminCreateUserConfig, UserPoolAddOns, AccountRecoverySetting
Étapes pour reproduire le bogue :
Déployer RES dans une GovCloud région
Supprimer la pile RES
Versions concernées
Versions RES 2024.04 et 2024.04.01
Mitigation
Les mesures d'atténuation suivantes ont été testées sur la version 2024.04 de RES :
Ouvrez le
UnprotectCognitoUserPoolLambdaConvention de dénomination :
<env-name>-InstallerTasksUnprotectCognitoUserPool-...
-
Paramètres d'exécution -> Modifier -> Sélectionnez Runtime
Python 3.11-> Enregistrer. Ouverte CloudFormation.
Supprimer la pile RES -> laisser Retain Installer Resource NON COCHÉE -> Supprimer.
........................
(2024.04 - 2024.04.02) Le bureau virtuel Linux peut être bloqué à l'état « REPRISE » au redémarrage
Le problème
Les bureaux virtuels Linux peuvent rester bloqués en état « REPRISE » lors du redémarrage après un arrêt manuel ou programmé.
Une fois l'instance redémarrée, le AWS Systems Manager n'exécute aucune commande à distance pour créer une nouvelle session DCV et le message de journal suivant est absent des journaux du contrôleur vdc (sous le groupe de CloudWatch journaux) : /<environment-name>/vdc/controller CloudWatch
Handling message of type DCV_HOST_REBOOT_COMPLETE_EVENT
Versions concernées
2024,04 - 2024,04.02
Mitigation
Pour récupérer les bureaux virtuels bloqués à l'état « REPRISE » :
-
Connectez-vous en SSH à l'instance problématique depuis la console EC2.
-
Exécutez les commandes suivantes sur l'instance :
sudo su - /bin/bash /root/bootstrap/latest/virtual-desktop-host-linux/configure_post_reboot.sh sudo reboot -
Attendez que l'instance redémarre.
Pour éviter que les nouveaux bureaux virtuels ne rencontrent le même problème :
-
Pour télécharger le script de correctif et le fichier de correctif (patch.py
et vdi_stuck_in_resuming_status.patch ), exécutez la commande suivante en les remplaçant par le répertoire dans lequel vous souhaitez placer les fichiers : <output-directory>Note
Le correctif ne s'applique qu'à RES 2024.04.02.
-
Le script de correctif nécessite la AWS CLI v2, Python 3.9.16 ou supérieur et Boto3.
-
Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES.
OUTPUT_DIRECTORY=<output-directory>curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.04.02/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.04.02/patch_scripts/patches/vdi_stuck_in_resuming_status.patch --output ${OUTPUT_DIRECTORY}/vdi_stuck_in_resuming_status.patch -
Accédez au répertoire dans lequel le script de correctif et le fichier de correctif sont téléchargés. Exécutez la commande de correctif suivante, en la
<environment-name>remplaçant par le nom de votre environnement RES et<aws-region>par la région dans laquelle RES est déployé :python3 patch.py --environment-name<environment-name>--res-version 2024.04.02 --module virtual-desktop-controller --patch vdi_stuck_in_resuming_status.patch --region<aws-region> -
Pour redémarrer l'instance de contrôleur VDC pour votre environnement, exécutez les commandes suivantes, en
<environment-name>remplaçant par le nom de votre environnement RES :ENVIRONMENT_NAME=<environment-name>INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-vdc-controller \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}
........................
(2024.04.02 et versions antérieures) Impossible de synchroniser les utilisateurs AD dont SAMAccountName l'attribut inclut des majuscules ou des caractères spéciaux
Le problème
RES ne parvient pas à synchroniser les utilisateurs AD après la configuration du SSO pendant au moins deux heures (deux cycles de synchronisation AD). Les journaux du gestionnaire de clusters (sous le /<environment-name>/cluster-manager groupe de CloudWatch journaux) incluent l'erreur suivante lors de la synchronisation AD :
Error: [INVALID_PARAMS] Invalid params: user.username must match regex: ^(?=.{3,20}$)(?![_.])(?!.*[_.]{2})[a-z0-9._]+(?<![_.])$
L'erreur est due au fait que RES n'accepte qu'un nom d'utilisateur SAMAccount répondant aux exigences suivantes :
-
Il ne peut contenir que des lettres ASCII minuscules, des chiffres, un point (.), un trait de soulignement (_).
-
Le point ou le trait de soulignement ne sont pas autorisés comme premier ou dernier caractère.
-
Il ne peut pas contenir deux points continus ou deux traits de soulignement (par exemple,.., __, ._, _.).
Versions concernées
2024.04.02 et versions antérieures
Mitigation
-
Pour télécharger le script de correctif et le fichier de correctif (patch.py
et samaccountname_regex.patch ), exécutez la commande suivante, en les remplaçant par le répertoire dans lequel vous <output-directory>souhaitez placer les fichiers :Note
Le correctif ne s'applique qu'à RES 2024.04.02.
-
Le script de correctif nécessite la AWS CLI v2, Python 3.9.16 ou supérieur et Boto3.
-
Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES.
OUTPUT_DIRECTORY=<output-directory>curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.04.02/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.04.02/patch_scripts/patches/samaccountname_regex.patch --output ${OUTPUT_DIRECTORY}/samaccountname_regex.patch -
Accédez au répertoire dans lequel le script de correctif et le fichier de correctif sont téléchargés. Exécutez la commande de correctif suivante, en la
<environment-name>remplaçant par le nom de votre environnement RES :python3 patch.py --environment-name<environment-name>--res-version 2024.04.02 --module cluster-manager --patch samaccountname_regex.patch -
Pour redémarrer l'instance de Cluster Manager pour votre environnement, exécutez les commandes suivantes en
<environment-name>remplaçant par le nom de votre environnement RES. Vous pouvez également mettre fin à l'instance depuis la console de gestion Amazon EC2.ENVIRONMENT_NAME=<environment-name>INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-cluster-manager \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}
........................
(2024.04.02 et versions antérieures) La clé privée pour accéder à l'hôte Bastion n'est pas valide
Le problème
Lorsqu'un utilisateur télécharge la clé privée pour accéder à l'hôte Bastion depuis le portail Web RES, la clé n'est pas correctement formatée : plusieurs lignes sont téléchargées en une seule ligne, ce qui rend la clé non valide. L'utilisateur obtiendra le message d'erreur suivant lorsqu'il tentera d'accéder à l'hôte du bastion avec la clé téléchargée :
Load key "<downloaded-ssh-key-path>": error in libcrypto<user-name>@<bastion-host-public-ip>: Permission denied (publickey,gssapi-keyex,gssapi-with-mic)
Versions concernées
2024.04.02 et versions antérieures
Mitigation
Nous vous recommandons d'utiliser Chrome pour télécharger les clés, car ce navigateur n'est pas concerné.
Le fichier clé peut également être reformaté en créant une nouvelle ligne après -----BEGIN PRIVATE KEY----- et une autre ligne juste avant. -----END PRIVATE KEY-----
........................