Résolution des problèmes de disponibilité des nœuds gérés - AWS Systems Manager
Solution 1 : vérifier que SSM Agent est installé et s'exécute sur le nœud géréSolution 2 : vérifier qu'un profil d'instance IAM a été spécifié pour l'instance (EC2 instances uniquement)Solution 3 : vérifier la connectivité des points de terminaison de serviceSolution 4 : vérifier la prise en charge du système d'exploitation cibleSolution 5 : vérifier que vous travaillez de la même manière Région AWS que l' EC2 instance AmazonSolution 6 : vérifier la configuration du proxy à laquelle vous avez postulé SSM Agent sur votre nœud géréSolution 7 : installer un certificat TLS sur les instances gérées

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.

Résolution des problèmes de disponibilité des nœuds gérés

Pour plusieurs AWS Systems Manager outils tels que Run Command, Distributor, et Session Manager, vous pouvez choisir de sélectionner manuellement les nœuds gérés sur lesquels vous souhaitez exécuter une opération. Après avoir spécifié que vous souhaitez choisir les nœuds manuellement, le système affiche alors une liste de nœuds gérés sur lesquels vous pouvez exécuter l'opération.

Cette rubrique fournit des informations qui vous aideront à déterminer pourquoi un nœud géré confirmé comme en cours d'exécution ne figure pas dans vos listes de nœuds gérés dans Systems Manager.

Pour qu'un nœud soit géré par Systems Manager et figure dans les listes de nœuds gérés, il doit remplir trois conditions :

  • SSM Agent doit être installé et exécuté sur le nœud doté d'un système d'exploitation compatible.

    Note

    Certains ont AWS géré Amazon Machine Images (AMIs) sont configurés pour lancer des instances avec SSM Agentpréinstallé. (Vous pouvez également configurer un AMI pour préinstaller SSM Agent.) Pour plus d'informations, consultez Trouver les AMIs avec SSM Agent préinstallé.

  • Pour les instances Amazon Elastic Compute Cloud (Amazon EC2), vous devez associer un profil d'instance AWS Identity and Access Management (IAM) à l'instance. Ce profil d'instance permet à celles-ci de communiquer avec le service Systems Manager. Si vous n'attribuez pas de profil d'instance à l'instance, vous devez l'enregistrer à l'aide d'une activation hybride, ce qui ne constitue pas le scénario le plus fréquent.

  • SSM Agent doit être en mesure de se connecter à un point de terminaison Systems Manager afin de s'enregistrer auprès du service. Le nœud géré est ensuite disponible pour le service, comme le confirme le signal que celui-ci envoie toutes les cinq minutes afin de vérifier l'état de l'instance.

  • Une fois que le statut d'un nœud géré a été maintenu Connection Lost pendant au moins 30 jours, il est possible que le nœud ne soit plus répertorié dans le Fleet Manager console. Pour le rétablir dans la liste, le problème à l'origine de la perte de connexion doit être résolu.

Après avoir vérifié qu'un nœud géré est en cours d'exécution, vous pouvez utiliser la commande suivante pour vérifier si SSM Agent enregistré avec succès auprès du service Systems Manager. Cette commande ne renvoie pas de résultats tant que l'enregistrement n'a pas réussi.

Linux & macOS
aws ssm describe-instance-associations-status \
    --instance-id instance-id
Windows
aws ssm describe-instance-associations-status ^
    --instance-id instance-id
PowerShell
Get-SSMInstanceAssociationsStatus `
    -InstanceId instance-id

Si l'enregistrement a abouti et que le nœud géré est disponible pour les opérations de Systems Manager, la commande renvoie des résultats semblables aux suivants.

{
    "InstanceAssociationStatusInfos": [
        {
            "AssociationId": "fa262de1-6150-4a90-8f53-d7eb5EXAMPLE",
            "Name": "AWS-GatherSoftwareInventory",
            "DocumentVersion": "1",
            "AssociationVersion": "1",
            "InstanceId": "i-02573cafcfEXAMPLE",
            "Status": "Pending",
            "DetailedStatus": "Associated"
        },
        {
            "AssociationId": "f9ec7a0f-6104-4273-8975-82e34EXAMPLE",
            "Name": "AWS-RunPatchBaseline",
            "DocumentVersion": "1",
            "AssociationVersion": "1",
            "InstanceId": "i-02573cafcfEXAMPLE",
            "Status": "Queued",
            "AssociationName": "SystemAssociationForScanningPatches"
        }
    ]
}

Si l'enregistrement n'est pas terminé ou a échoué, la commande renvoie des résultats semblables aux suivants :

{
    "InstanceAssociationStatusInfos": []
}

Si la commande ne renvoie aucun résultat au bout de 5 minutes environ, utilisez les informations suivantes pour résoudre les problèmes liés à vos nœuds gérés.

Rubriques

Solution 1 : vérifier que SSM Agent est installé et s'exécute sur le nœud géré

Assurez-vous de disposer de la dernière version de SSM Agent est installé et s'exécute sur le nœud géré.

Pour déterminer si SSM Agent est installé et s'exécute sur un nœud géré, voirVérification du statut de l'SSM Agent et démarrage de l'agent.

Pour installer ou réinstaller SSM Agent sur un nœud géré, consultez les rubriques suivantes :

Solution 2 : vérifier qu'un profil d'instance IAM a été spécifié pour l'instance (EC2 instances uniquement)

Pour les instances Amazon Elastic Compute Cloud (Amazon EC2), vérifiez que l'instance est configurée avec un profil d'instance AWS Identity and Access Management (IAM) qui permet à l'instance de communiquer avec l'API Systems Manager. Vérifiez également que votre utilisateur est associé à une politique d'approbation IAM qui permet à votre utilisateur afin de communiquer avec l'API Systems Manager.

Note

Les serveurs locaux, les périphériques périphériques et les machines virtuelles (VMs) utilisent un rôle de service IAM au lieu d'un profil d'instance. Pour plus d’informations, consultez la section Créer le rôle de service IAM requis pour Systems Manager dans les environnements hybrides et multicloud.

Pour déterminer si un profil d'instance doté des autorisations nécessaires est attaché à une EC2 instance

  1. Ouvrez la EC2 console Amazon à l'adresse https://console.aws.amazon.com/ec2/.

  2. Dans le panneau de navigation, choisissez Instances.

  3. Sélectionnez l'instance pour laquelle rechercher un profil d'instance.

  4. Sous l'onglet Description du panneau inférieur, recherchez Rôle IAM et sélectionnez le nom du rôle.

  5. Sur la page Résumé du rôle pour le profil d'instance, sous l'onglet Autorisations, vérifiez que AmazonSSMManagedInstanceCore est bien répertorié sous Politiques d'autorisations.

    Si vous utilisez plutôt une politique personnalisée, vérifiez qu'elle fournit les mêmes autorisations que AmazonSSMManagedInstanceCore.

    Ouvrir AmazonSSMManagedInstanceCore dans la console

    Pour obtenir des informations sur les autres politiques qui peuvent être attachées à un profil d’instance pour Systems Manager, consultez Configurer des autorisations d’instance requises pour Systems Manager.

Solution 3 : vérifier la connectivité des points de terminaison de service

Vérifiez que l'instance est connectée aux points de terminaison de service Systems Manager. Cette connectivité est fournie en créant et en configurant des points de terminaison de VPC pour Systems Manager, ou en autorisant le trafic sortant HTTPS (port 443) vers les points de terminaison de service.

Pour les EC2 instances Amazon, le point de terminaison du service Systems Manager Région AWS est utilisé pour enregistrer l'instance si votre configuration de cloud privé virtuel (VPC) autorise le trafic sortant. Toutefois, si la configuration VPC avec laquelle l'instance a été lancée n'autorise pas le trafic sortant et que vous ne pouvez pas modifier cette configuration pour permettre la connexion aux points de terminaison de service publics, vous devez configurer des points de terminaison d'interface pour votre VPC.

Pour plus d'informations, consultez Améliorer la sécurité des EC2 instances en utilisant des points de terminaison VPC pour Systems Manager.

Solution 4 : vérifier la prise en charge du système d'exploitation cible

Vérifiez que l'opération que vous avez choisie peut être exécutée sur le type de nœud géré que vous souhaitez voir figurer dans la liste. Certaines opérations Systems Manager peuvent cibler uniquement des instances Windows ou uniquement des instances Linux. Par exemple, les documents Systems Manager (SSM) AWS-InstallPowerShellModule et AWS-ConfigureCloudWatchne peuvent être exécutés que sur des instances Windows. Sur la page Exécuter une commande, si vous sélectionnez l'un de ces documents et que vous sélectionnez Choisir des instances manuellement, seules vos instances Windows sont répertoriées et disponibles à la sélection.

Solution 5 : vérifier que vous travaillez de la même manière Région AWS que l' EC2 instance Amazon

Les EC2 instances Amazon sont créées et disponibles dans des régions spécifiques Régions AWS, telles que la région USA Est (Ohio) (us-east-2) ou Europe (Irlande) (eu-west-1). Assurez-vous que vous travaillez dans la Région AWS même EC2 instance Amazon que vous souhaitez utiliser. Pour de plus amples informations, consultez Choisir une région dans Mise en route avec la AWS Management Console.

Solution 6 : vérifier la configuration du proxy à laquelle vous avez postulé SSM Agent sur votre nœud géré

Vérifiez que la configuration du proxy à laquelle vous avez appliqué votre demande SSM Agent sur votre nœud géré est correct. Si la configuration de proxy est incorrecte, le nœud ne peut pas se connecter aux points de terminaison de service requis, ou Systems Manager risque de mal identifier le système d'exploitation du nœud géré. Pour plus d’informations, consultez Configuration SSM Agent pour utiliser un proxy sur des nœuds Linux et Configuration SSM Agent pour utiliser un proxy pour Windows Server Instances.

Solution 7 : installer un certificat TLS sur les instances gérées

Un certificat TLS (Transport Layer Security) doit être installé sur chaque instance gérée que vous utilisez. AWS Systems Manager Services AWS utilisez ces certificats pour chiffrer les appels vers d'autres Services AWS personnes.

Un certificat TLS est déjà installé par défaut sur chaque EC2 instance Amazon créée à partir de n'importe quel Amazon Machine Image (AMI). La plupart des systèmes d'exploitation modernes incluent le certificat TLS requis d'Amazon Trust Services CAs dans leur magasin de confiance.

Pour déterminer si le certificat requis est installé sur votre instance, exécutez la commande suivante en fonction du système d'exploitation de celle-ci. Assurez-vous de remplacer la region partie de l'URL par celle Région AWS où se trouve votre instance gérée.

Linux & macOS
curl -L https://ssm.region.amazonaws.com
Windows
Invoke-WebRequest -Uri https://ssm.region.amazonaws.com

La commande doit renvoyer une erreur UnknownOperationException. Si vous recevez un message d'erreur SSL/TLS, cela peut signifier que le certificat requis n'est pas installé.

Si vous constatez que les certificats Amazon Trust Services CA requis ne sont pas installés sur vos systèmes d'exploitation de base, sur les instances créées à partir de AMIs qui ne sont pas fournis par Amazon ou sur vos propres serveurs locaux et vous devez installer et VMs autoriser un certificat d'Amazon Trust Services, ou utiliser AWS Certificate Manager (ACM) pour créer et gérer des certificats pour un service intégré pris en charge.

Chacune de vos instances gérées doit avoir l'un des certificats TLS (Transport Layer Security) suivants installé.

  • Amazon Root CA 1

  • Starfield Services Root Certificate Authority – G2

  • Starfield Class 2 Certificate Authority

Pour plus d'informations sur ACM, consultez le Guide de l'utilisateur AWS Certificate Manager.

Si les certificats figurant dans votre environnement informatique sont gérés par un objet de politique de groupe (GPO), vous pouvez avoir besoin de configurer une politique de groupe pour inclure l'un de ces certificats.

Pour plus d'informations sur les certificats Amazon Root et Starfield, consultez le billet de blog How to Prepare for AWS's Move to Its Own Certificate Authority.