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.

Découvrez les détails techniques du SSM Agent

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

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 spécifiez pour le IAM rôle que vous avez choisi pour la configuration de gestion d'hôte par défaut. Sous Linux, seul le compte root peut accéder à ces informations d'identification. ActivéWindows Server, seuls le SYSTEM compte 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.

Lorsqu'il SSM Agent est installé sur une machine, il nécessite des autorisations pour communiquer avec le service Systems Manager. Sur les instances Amazon Elastic Compute Cloud (AmazonEC2), 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.

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 :

Configuration SSM Agent pour une utilisation avec la norme fédérale de traitement de l'information (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 l' AWS Systems Manager Agent (SSM Agent) pour qu'il utilise les FIPS points de terminaison 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 obtenir la 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 deFIPS, voir Federal Information Processing Standard (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. Il s'ssm-useragit de l'utilisateur du système d'exploitation par défaut lorsqu'une session démarreSession Manager, une fonctionnalité de 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'EC2instance 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'IPv4adresse 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 nouvelles fonctionnalités sont ajoutées à Systems Manager ou que des mises à jour sont apportées aux fonctionnalités existantes. Le fait de ne pas utiliser la dernière version de l'agent peut empêcher votre nœud géré d'utiliser diverses capacités 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, veuillez consulter Automatisation des mises à jour de l'SSM Agent. Abonnez-vous à la page des notes de SSM Agent publication GitHub pour recevoir des notifications concernant les SSM Agent mises à jour.

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 parSSM Agent, tels qu'un fichier d'informations d'identification, des ressources pour la communication entre processus (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 remplaçant region avec la région dans laquelle vous travaillez, par exemple us-east-2 pour 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 (AmazonEC2) 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 VPC point de terminaison, vous devez créer une politique d'autorisation Amazon S3 personnalisée, puis l'associer à votre profil d'instance (pour les EC2 instances) ou à votre rôle de service (pour les nœuds non EC2 gérés).

Pour plus d'informations sur l'utilisation d'un point de terminaison de cloud privé virtuel (VPC) dans vos opérations de Systems Manager, voir Améliorer la sécurité des EC2 instances en utilisant des VPC points de terminaison 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 de manière explicite dans un profil d'instance ou un rôle de service uniquement lorsque vous utilisez un VPC point de terminaison.

{
        "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:::amazon-ssm-packages-us-east-2/*",
                    "arn:aws:s3:::us-east-2-birdwatcher-prod/*",
                    "arn:aws:s3:::aws-ssm-document-attachments-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 ManagerAPIs. 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 GitHubafin que vous puissiez adapter l'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.