AWS Systems ManagerChange Managern'est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour plus d'informations, consultez AWS Systems ManagerChange Managerla section Modification de la disponibilité.

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.

En savoir plus sur les détails techniques de SSM Agent

Utilisez les informations de cette rubrique pour vous aider à implémenter AWS Systems Manager Agent (SSM Agent) et à comprendre son fonctionnement.

Comportement des informations d'identification SSM Agent version 3.2.x.x

SSM Agent stocke un ensemble d'informations d'identification temporaires dans /var/lib/amazon/ssm/credentials (pour Linux et macOS) ou %PROGRAMFILES%\Amazon\SSM\credentials (pour Windows Server) lorsqu'une instance est intégrée à l'aide de la configuration de gestion d'hôte par défaut dans Quick Setup. Les informations d'identification temporaires disposent des autorisations que vous avez spécifiées pour le rôle IAM que vous avez choisi pour la configuration de la gestion de l'hôte par défaut. Sous Linux, seul le compte root peut accéder à ces informations d'identification. Sous Windows Server, seuls le compte SYSTEM et les Administrateurs locaux peuvent accéder à ces informations d'identification.

SSM AgentPriorité des informations d'identification de l'

Cette rubrique décrit des informations importantes sur la façon dont l'SSM Agent est autorisé à exécuter des actions sur vos ressources.

Quand SSM Agent est installé sur une machine, il a besoin d’autorisations pour communiquer avec le service Systems Manager. Sur les instances Amazon Elastic Compute Cloud (Amazon EC2), ces autorisations sont fournies dans un profil d'instance attaché à l'instance. Sur une machine autre que la EC2 machine, obtient SSM Agent normalement les autorisations nécessaires à partir du fichier d'informations d'identification partagé, situé à l'emplacement /root/.aws/credentials (Linux etmacOS) ou %USERPROFILE%\.aws\credentials (Windows Server). Les autorisations nécessaires sont ajoutées à ce fichier durant le processus d'activation hybride. Si un nœud à activation hybride est désenregistré, l’agent peut passer en mode veille prolongée. Pour de plus amples informations, veuillez consulter Comprendre la mise en veille prolongée de SSM Agent.

Dans de rares cas, cependant, des autorisations peuvent être ajoutées à une machine, à un plus grand nombre d'emplacements que ceux où SSM Agent vérifie les autorisations pour exécuter ses tâches.

Supposons, par exemple, que vous ayez configuré une EC2 instance pour qu'elle soit gérée par Systems Manager. Cette configuration inclut l'attachement d'un profil d'instance. Mais vous décidez ensuite d'utiliser cette instance pour les tâches de développeur ou d'utilisateur final, et d'installer l' AWS Command Line Interface (AWS CLI) par-dessus. Dans ce cas, des autorisations supplémentaires sont ajoutées à un fichier d'informations d'identification sur l'instance.

Lorsque vous exécutez une commande Systems Manager sur l'instance, l'SSM Agent peut tenter d'utiliser des informations d'identification différentes de celles que vous pensez qu'il va utiliser, par exemple à partir d'un fichier d'informations d'identification et non d'un profil d'instance. Cela est dû au fait que l'SSM Agent recherche les informations d'identification dans l'ordre prescrit pour la chaîne de fournisseur d'informations d'identification par défaut.

La chaîne de fournisseur par défaut recherche des informations d'identification dans cet ordre :

Pour plus d'informations, consultez les rubriques connexes suivantes :

Configuring SSM Agent for use with the Federal Information Processing Standard (FIPS)

Si vous devez utiliser Systems Manager avec des modules cryptographiques validés par le Federal Information Processing Standard (FIPS) 140-3, vous pouvez configurer AWS Systems Manager Agent (SSM Agent) pour utiliser les points de terminaison FIPS dans les régions prises en charge.

Chaque fois que vous modifiez la configuration, redémarrez l'SSM Agent.

Vous pouvez personnaliser d'autres fonctions de l'SSM Agent en suivant la même procédure. Pour une up-to-date liste des propriétés de configuration disponibles et de leurs valeurs par défaut, consultez la section Définitions des propriétés de configuration dans le amazon-ssm-agent référentiel dans GitHub.

Pour plus d'informations sur la AWS prise en charge de la norme FIPS, consultez la norme fédérale de traitement de l'information (FIPS) 140-3.

À propos du compte local ssm-user

À partir de la version 2.3.50.0 de l'SSM Agent, l'agent crée un compte utilisateur local appelé ssm-user et l'ajoute au répertoire /etc/sudoers.d (Linux et macOS) ou au groupe Administrateurs (Windows Server). Sur les versions de l'agent antérieures à 2.3.612.0, le compte est créé la première fois que l'SSM Agent démarre ou redémarre après l'installation. Sur la version 2.3.612.0 et version ultérieure, le compte ssm-user est créé la première fois qu'une session est démarrée sur une instance. Cet ssm-user est l’utilisateur du système d’exploitation par défaut lorsqu’une session démarre dans Session Manager, un outil d’ AWS Systems Manager. Vous pouvez modifier les autorisations de l'utilisateur ssm-user en le déplaçant vers un groupe ayant moins de privilèges ou en modifiant le fichier sudoers. Le compte ssm-user n'est pas supprimé du système lorsque l'SSM Agent est désinstallé.

Sur Windows Server, l'SSM Agent gère la définition d'un nouveau mot de passe pour le compte ssm-user lorsque chaque session commence. Aucun mot de passe n'est défini pour ssm-user sur des instances gérées Linux.

À partir de la version SSM Agent 2.3.612.0, le compte ssm-user n'est pas créé automatiquement sur les ordinateurs Windows Server qui sont utilisés en tant que contrôleurs de domaine. Pour utiliser Session Manager sur un contrôleur de domaine Windows Server, créez le compte ssm-user manuellement, s'il n'existe pas déjà, et affectez les autorisations d'administrateur de domaine à l'utilisateur.

SSM Agent et le Instance Metadata Service (IMDS)

Systems Manager s'appuie sur les métadonnées de l' EC2 instance pour fonctionner correctement. Systems Manager peut accéder aux métadonnées d'instance en utilisant la version 1 ou la version 2 d'Instance Metadata Service (IMDSv1 et IMDSv2). Votre instance doit pouvoir accéder à l' IPv4 adresse du service de métadonnées d'instance : 169.254.169.254. Pour plus d'informations, consultez la section Métadonnées de l'instance et données utilisateur dans le guide de EC2 l'utilisateur Amazon.

Garder SSM Agent up-to-date

Une nouvelle version de SSM Agent est lancée chaque fois que de nouveaux outils sont ajoutés à Systems Manager ou que des mises à jour sont apportées aux outils existants. Le fait de ne pas utiliser la dernière version de l’agent peut empêcher votre nœud géré d’utiliser divers outils et fonctionnalités de Systems Manager. C'est pourquoi nous vous recommandons d'automatiser le processus permettant de maintenir SSM Agent à jour sur vos machines. Pour plus d'informations, consultez Automatisation des mises à jour de l'SSM Agent. Inscrivez‑vous sur la page SSM Agent Release Notes du site Web de GitHub pour recevoir des notifications sur les mises à jour de SSM Agent.

S’assurer que le répertoire d’installation SSM Agent ne soit pas modifié, déplacé ou supprimé

SSM Agent est installé sur /var/lib/amazon/ssm/ (Linux et macOS) et %PROGRAMFILES%\Amazon\SSM\ (Windows Server). Ces répertoires d’installation contiennent des fichiers et des dossiers critiques utilisés par SSM Agent, tels qu’un fichier d’informations d’identification, des ressources pour la communication interprocessus (IPC) et des dossiers d’orchestration. Aucun élément du répertoire d’installation ne doit être modifié, déplacé ou supprimé. Dans le cas contraire, SSM Agent pourrait cesser de fonctionner correctement.

SSM Agentmises à jour continues par Régions AWS

Une fois qu'une SSM Agent mise à jour est disponible dans son GitHub référentiel, cela peut prendre jusqu'à deux semaines avant que la version mise à jour ne soit déployée auprès de tous Régions AWS à des moments différents. Pour cette raison, vous pouvez recevoir le message d'erreur « Non pris en charge sur la plate-forme actuelle » ou « Mise amazon-ssm-agent à jour vers une ancienne version, veuillez activer l'autorisation de rétrogradation » lorsque vous tentez de déployer une nouvelle version de SSM Agent dans une région.

Pour déterminer votre version disponible de SSM Agent, vous pouvez exécuter une commande curl.

Pour afficher la version de l'agent disponible dans le compartiment de téléchargement global, exécutez la commande suivante.

curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/VERSION

Pour afficher la version de l'agent disponible dans une région spécifique, exécutez la commande suivante en la region remplaçant par la région dans laquelle vous travaillez, par us-east-2 exemple la région USA Est (Ohio).

curl https://s3.region.amazonaws.com/amazon-ssm-region/latest/VERSION

Vous pouvez aussi ouvrir le fichier VERSION directement dans votre navigateur sans exécuter de commande curl.

Communications de l'SSM Agent avec des compartiments S3 gérés par AWS

Au cours de l'exécution de diverses opérations de Systems Manager, AWS Systems Manager Agent (SSM Agent) accède à un certain nombre de compartiments Amazon Simple Storage Service (Amazon S3). Ces compartiments S3 sont accessibles au public et, par défaut, l'SSM Agent s'y connecte en utilisant des appels HTTP.

Toutefois, si vous utilisez un point de terminaison de cloud privé virtuel (VPC) dans le cadre de vos opérations Systems Manager, vous devez fournir une autorisation explicite dans un profil d'instance Amazon Elastic Compute Cloud EC2 (Amazon) pour Systems Manager, ou dans un rôle de service pour les EC2 non-machines dans un environnement hybride et multicloud. Sinon, vos ressources ne peuvent pas accéder à ces compartiments publics.

Pour accorder à vos nœuds gérés l'accès à ces compartiments lorsque vous utilisez un point de terminaison VPC, vous créez une politique d'autorisation Amazon S3 personnalisée, puis vous l'associez à votre profil d'instance ( EC2 pour les instances) ou à votre rôle de service (pour les nœuds non gérésEC2 ).

Pour plus d'informations sur l'utilisation d'un point de terminaison de cloud privé virtuel (VPC) dans vos opérations de Systems Manager, consultez Améliorer la sécurité des EC2 instances en utilisant des points de terminaison VPC pour Systems Manager.

Pour plus d’informations, consultez les rubriques suivantes :

Autorisations de compartiment nécessaires

Le tableau suivant décrit chacun des compartiments S3 auxquels l'SSM Agent peut avoir besoin d'accéder pour des opérations Systems Manager.

Autorisations Amazon S3 requises par l'SSM Agent

Exemple

L'exemple suivant illustre comment fournir l'accès aux compartiments S3 requis pour les opérations Systems Manager dans la région USA Est (Ohio) (us-east-2). Dans la plupart des cas, vous devez fournir ces autorisations explicitement dans un profil d'instance ou un rôle de service uniquement lors de l'utilisation d'un point de terminaison de VPC.

JSON

{
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Effect": "Allow",
                "Action": "s3:GetObject",
                "Resource": [
                    "arn:aws:s3:::aws-windows-downloads-us-east-2/*",
                    "arn:aws:s3:::amazon-ssm-us-east-2/*",
                    "arn:aws:s3:::aws-ssm-us-east-2/*",
                    "arn:aws:s3:::patch-baseline-snapshot-us-east-2/*",
                    "arn:aws:s3:::aws-patch-manager-us-east-2-552881074/*",
                    "arn:aws:s3:::aws-patchmanager-macos-us-east-2-552881074/*"
                ]
            }
        ]
    }

Validation des machines activées par un système hybride à l'aide d'une empreinte matérielle

Dans un environnement hybride et multicloud, il SSM Agent collecte un certain nombre d'attributs système (appelés hachage matériel) et utilise ces attributs pour calculer une empreinte digitale. EC2 L'empreinte digitale est une chaîne opaque que l'agent transmet à certains Systems Manager APIs. Cette empreinte digitale unique associe l'appelant à un nœud géré et activé par un système hybride particulier. L'agent stocke l'empreinte digitale et le hachage matériel sur le disque local, à un emplacement désigné comme Coffre-fort.

L'agent calcule le hachage matériel et l'empreinte digitale lorsque la machine est enregistrée pour une utilisation avec Systems Manager. Ensuite, l'empreinte digitale est transmise au service Systems Manager lorsque l'agent envoie une commande RegisterManagedInstance.

Plus tard, lors de l'envoi d'une commande RequestManagedInstanceRoleToken, l'agent vérifie l'empreinte digitale et le hachage matériel dans le coffre-fort afin de s'assurer que les attributs de la machine actuelle correspondent au hachage matériel stocké. Si les attributs de la machine actuelle correspondent au hachage matériel stocké dans le coffre-fort, l'agent transmet l'empreinte digitale du coffre-fort à une RegisterManagedInstance, et l'appel est alors considéré comme réussi.

Si les attributs de la machine actuelle ne correspondent pas au hachage matériel stocké, l'SSM Agent calcule une nouvelle empreinte digitale, stocke le nouveau hachage matériel et l'empreinte digitale dans le coffre-fort et transmet la nouvelle empreinte digitale à un RequestManagedInstanceRoleToken. Cela provoque l'échec du RequestManagedInstanceRoleToken, et l'agent ne pourra pas obtenir un jeton de rôle pour se connecter au service Systems Manager.

Cet échec est intégré, et il sert d'étape de vérification pour empêcher que plusieurs nœuds gérés communiquent avec le service Systems Manager en tant que même nœud géré.

Lorsqu'il compare les attributs de la machine actuelle au hachage matériel stocké dans le coffre-fort, l'agent utilise la logique suivante pour déterminer si l'ancien et le nouveau hachages correspondent :

Le seuil de similarité est stocké dans le coffre-fort, et fait partie du hachage matériel.

Le seuil de similarité peut être défini après qu'une instance a été enregistrée en utilisant une commande semblable à celle qui suit.

Sur les machines Linux :

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

Sur Windows Server les machines utilisant PowerShell :

cd "C:\Program Files\Amazon\SSM\" `
    .\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1

SSM Agent sur GitHub

Le code source de SSM Agent est disponible sur le site Web de GitHub, vous pouvez ainsi adapter cet agent à vos besoins. Nous vous conseillons d'envoyer des requêtes d'extraction pour les modifications que vous souhaitez inclure. Toutefois, Amazon Web Services ne fournit pas de support pour l'exécution de copies modifiées de ce logiciel.

Comprendre la mise en veille prolongée de SSM Agent

AWS Systems Manager L'hibernation de l'agent (SSM Agent) est un mode opérationnel qui se produit lorsque l'agent ne parvient pas à maintenir une communication correcte avec le service Systems Manager. Pendant la mise en veille prolongée, l’agent réduit sa fréquence de communication et passe en état de veille.

Quand survient la mise en veille prolongée de SSM Agent

La mise en veille prolongée de SSM Agent peut se produire dans les cas suivants :

Comportement des communications lors de la mise en veille prolongée

Lorsque SSM Agent passe en veille prolongée, son modèle de communication avec le service Systems Manager change :

Pendant la veille prolongée, l’agent continue de retenter des tentatives d’authentification et de connexion à une fréquence réduite, mais il ne peut pas traiter de nouvelles commandes ou communiquer des informations de statut détaillées tant que la veille prolongée n’est pas résolue.

Options de configuration pour empêcher la mise en veille prolongée dans les instances hybrides

La principale option de configuration permettant d’éviter la mise en veille prolongée provoquée par des modifications d’empreintes matérielles consiste à ajuster le seuil de similarité :

Sur les machines Linux :

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

Sur les machines Windows Server utilisant PowerShell :

cd "C:\Program Files\Amazon\SSM\" `
.\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1

Le seuil de similarité détermine la rigueur avec laquelle l’agent compare les attributs actuels de la machine avec le hachage matériel stocké :

Journalisation et surveillance de la mise en veille prolongée

Lorsque SSM Agent passe en mode veille prolongée, il crée des entrées de journal qui peuvent vous aider à identifier et résoudre les problèmes liés à l’état de veille prolongée :

Surveillez ces sources de journaux afin de détecter rapidement les événements de veille prolongée et prendre des mesures correctives pour rétablir le fonctionnement normal de l’agent.

Sortir de la mise en veille prolongée

Pour sortir de la veille prolongée, traitez la cause sous-jacente :

Une fois le problème sous-jacent résolu, l’agent doit automatiquement quitter le mode veille prolongée et reprendre son fonctionnement normal lors de la prochaine tentative de communication.