Gestion de flotte avec Systems Manager

Vous avez 400 instances EC2 et une question qui prend 10 secondes sur l'une d'entre elles : quelle version de l'agent est installée ? La réponse en SSH vous coûte un bastion, un problème de distribution de clés, un port entrant sur chaque security group, et un script shell enroulé autour de 400 noms d'hôtes sans aucune trace de ce qui a tourné où. Systems Manager existe pour que cette question coûte un appel d'API et laisse une piste d'audit.

Le sujet précédent se terminait sur la livraison d'une nouvelle version de votre logiciel. Celui-ci parle du logiciel déjà en marche : l'atteindre, le garder cohérent, et automatiser les parties de votre semaine qui se répètent à l'identique.

Les trois conditions qui rendent un nœud gérable

Tous les outils Systems Manager de ce domaine (Session Manager, Run Command, Patch Manager, State Manager) travaillent sur des nœuds gérés, et rien ne fonctionne tant qu'une instance n'en est pas un. Trois conditions doivent tenir en même temps.

SSM Agent doit être installé et en marche sur un système d'exploitation pris en charge. La plupart des AMI fournies par AWS l'embarquent déjà, ce qui explique pourquoi cette condition passe d'habitude sans rien faire, et pourquoi on l'oublie dès que quelqu'un arrive avec une image maison.

Le nœud doit avoir des credentials qui lui permettent d'appeler l'API Systems Manager. Sur EC2, cela veut dire un instance profile IAM ou l'alternative au niveau du compte vue à la section suivante. Sur un serveur ou une VM on-premises, cela veut dire un service role IAM et une hybrid activation.

L'agent doit pouvoir joindre un endpoint Systems Manager sur le port 443 pour s'enregistrer. Une fois enregistré, le service confirme la santé du nœud par un signal toutes les 5 minutes.

Retenez l'ordre, parce que c'est aussi l'ordre de diagnostic à la fin de cette leçon. Retenez aussi le sens de la connexion : SSM Agent initie toujours la connexion vers l'extérieur. Vous n'ouvrez jamais de port entrant pour Systems Manager, et c'est le seul fait qui fait de cet outillage une amélioration de sécurité par rapport à SSH plutôt qu'une couche de confort posée dessus.

Deux façons de donner des credentials à une instance

L'approche classique est un instance profile IAM portant la managed policy AmazonSSMManagedInstanceCore. Elle vaut par instance, elle est explicite, et c'est presque toujours elle que teste une question sur un nœud isolé mal configuré.

Default Host Management Configuration est l'alternative au niveau du compte, et AWS la recommande quand le cas d'usage le permet. Activez-la et toute instance de ce compte et de cette Region qui tourne en Instance Metadata Service Version 2 avec SSM Agent 3.2.582.0 ou ultérieur devient une managed instance automatiquement, sans aucun instance profile. Elle passe par un service role nommé AWSSystemsManagerDefaultEC2InstanceManagementRole portant la policy AmazonSSMManagedEC2InstanceDefaultPolicy.

Trois détails décident des questions ici.

C'est par Region. L'activer dans eu-west-1 ne fait rien pour us-east-1. Les équipes le découvrent quand la moitié de leur flotte est gérée et l'autre non.

L'instance profile gagne. SSM Agent essaie les permissions de l'instance profile avant celles de Default Host Management Configuration, donc un vieil instance profile qui autorise ssm:UpdateInstanceInformation garde cette instance sur l'ancien chemin et le rôle de compte ne sert jamais. Retirez cette permission des instance profiles existants avant d'activer la fonctionnalité.

La propagation n'est pas immédiate. Après activation, les instances peuvent mettre jusqu'à 30 minutes à récupérer les credentials du nouveau rôle.

Session Manager : un shell sans port entrant

Il est 2 heures du matin et vous avez besoin d'un shell sur une instance de production. Session Manager vous le donne depuis la console ou le CLI, sans port entrant ouvert, sans clé SSH, sans bastion.

La connexion est un canal bidirectionnel entre votre client et SSM Agent. Le trafic est chiffré en TLS 1.2, les demandes d'ouverture du canal sont signées en Sigv4, et vous pouvez ajouter une clé KMS pour chiffrer les données de session par-dessus le chiffrement TLS par défaut. L'accès se donne entièrement par policy IAM, ce qui transforme « donner l'accès production à l'ingénieur d'astreinte pendant sa rotation » en modification de policy plutôt qu'en exercice de rotation de clés.

Deux capacités au-delà du shell interactif méritent d'être nommées.

Le port forwarding redirige un port interne au nœud vers un port local de votre machine. Une base de données qui écoute sur 5432 dans un subnet privé devient localhost:9999 sur votre poste, sans VPN et sans IP publique.

Les shell profiles configurables fixent le shell, les variables d'environnement, le répertoire de travail et les commandes de démarrage de chaque session, ce qui garantit que les sessions atterrissent à un endroit prévisible.

Côté audit, les sessions peuvent être diffusées vers un log group CloudWatch Logs ou un bucket S3, avec ou sans votre propre clé KMS, et CloudTrail enregistre les appels d'API qui les ont ouvertes. Une règle EventBridge sur le début et la fin de session pousse une notification vers SNS.

Voici la fausse idée qui survit à une première lecture de cette fonctionnalité. La journalisation de session ne couvre ni le port forwarding ni les sessions SSH. Dans ces modes, Session Manager n'est qu'un tunnel, et SSH chiffre tout à l'intérieur de la connexion TLS : le service n'a rien à enregistrer. Si un scénario exige une transcription des commandes, la réponse passe par des sessions shell interactives, pas par le port forwarding.

Run Command : une action sur toute la flotte

Session Manager, c'est un nœud et un humain. Run Command, c'est beaucoup de nœuds et un document, et cela ne coûte rien de plus.

Vous choisissez un document SSM de type Command (AWS-RunShellScript, AWS-RunPowerShellScript, AWS-RunPatchBaseline, etc.), vous choisissez des cibles, et vous réglez le débit.

Les cibles prennent quatre formes :

# par ID d'instance
--targets Key=instanceids,Values=i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE

# par tag
--targets Key=tag:Environment,Values=Production

# par nom de resource group (un seul par commande)
--targets Key=resource-groups:Name,Values=web-tier

# par type de ressource dans des resource groups (cinq types au maximum)
--targets Key=resource-groups:ResourceTypeFilters,Values=AWS::EC2::Instance

Deux règles sur le ciblage par tag décident des questions. Plusieurs critères Key se combinent en ET, donc Key=tag:Department,Values=Finance Key=tag:ServerRole,Values=Database ne touche que les nœuds qui portent les deux. Et un tableau de cibles contient au maximum 5 clés avec 5 valeurs chacune.

Passons au contrôle de débit, le même couple que sur les runbooks Automation :

• --max-concurrency est le nombre de nœuds qui exécutent la commande en même temps, en valeur absolue ou en pourcentage. La valeur par défaut est 50. La distribution monte en puissance : la commande part vers un nœud, attend l'accusé de réception, puis deux autres, puis croît de façon exponentielle jusqu'à la limite.
• --max-errors est le nombre d'échecs tolérés avant que Systems Manager cesse d'envoyer. La valeur par défaut est 0, donc le premier échec arrête la distribution.

Déroulons le calcul qu'AWS donne. Envoyez une commande à 50 nœuds avec --max-errors 10% : le seuil vaut 5, donc le système cesse d'envoyer à l'arrivée de la sixième erreur. Les invocations déjà en vol vont jusqu'au bout, et certaines peuvent échouer aussi. Si un scénario exige que jamais plus de N nœuds n'échouent, --max-errors N ne suffit pas : il faut aussi --max-concurrency 1 pour que les invocations avancent une par une.

aws ssm send-command \
  --document-name "AWS-RunShellScript" \
  --targets Key=tag:Environment,Values=Production \
  --parameters 'commands=["systemctl restart nginx"]' \
  --max-concurrency 10 \
  --max-errors 1 \
  --output-s3-bucket-name ops-command-output \
  --service-role-arn arn:aws:iam::111122223333:role/SSMRunCommandNotifications \
  --notification-config NotificationArn=arn:aws:sns:eu-west-1:111122223333:ops-alerts,NotificationEvents=Failed,NotificationType=Command

Deux notes opérationnelles sur la sortie. L'historique des commandes est disponible jusqu'à 30 jours, donc tout ce que vous devez garder plus longtemps part vers S3 ou CloudWatch Logs, ce qui règle aussi la troncature de la console sur les sorties longues. Et ne passez jamais un secret en clair dans les paramètres d'une commande : toute l'activité de l'API Systems Manager est journalisée, donc quiconque accède à ces logs peut le lire. Utilisez un paramètre SecureString, sujet d'une leçon plus loin dans ce sujet.

Fleet Manager et Inventory : voir ce que vous avez

Fleet Manager est la console posée sur tout cela. Elle montre quels nœuds gérés sont en marche ou arrêtés, et elle vous laisse faire de l'administration système sans ouvrir la moindre session : parcourir le système de fichiers et lire le contenu des fichiers, gérer le registre Windows, gérer les comptes et groupes d'utilisateurs du système, voir les processus en cours, consulter les fichiers de logs du nœud, vous connecter à une instance Windows en RDP, et gérer les volumes EBS attachés. Chacune de ces actions est filtrée par IAM, donc vous pouvez accorder la lecture des logs à une équipe support sans lui accorder un shell.

Inventory répond aux questions à l'échelle de la flotte. Il collecte des métadonnées selon un calendrier : applications et versions, composants AWS, fichiers, configuration réseau, mises à jour Windows, détails d'instance, services, tags, clés de registre Windows, rôles Windows, et tout inventaire personnalisé que vous déposez sur le nœud sous forme de fichier JSON. L'intervalle de collecte le plus court est de 30 minutes, donc traitez-le comme un instantané périodique et non comme un flux en direct.

Inventory ne collecte que des métadonnées. Il ne lit pas vos données.

La pièce qui transforme Inventory en véritable outil de reporting est la resource data sync : pointez chaque compte et chaque Region vers un seul bucket S3, puis interrogez les données agrégées avec Athena. C'est la différence entre « quels nœuds de cette Region font tourner OpenSSL 1.0 » et « quels nœuds font tourner OpenSSL 1.0 quelque part dans l'organisation ».

Quand un nœud n'apparaît pas dans la liste

Vous avez vérifié que l'instance est en marche. Elle n'est pas dans la liste des nœuds gérés. Reprenez les trois conditions dans l'ordre, parce que cet ordre trouve la cause avec le moins de travail.

Commencez par le contrôle rapide depuis le nœud lui-même. SSM Agent 3.1.501.0 et ultérieur embarque un outil autonome :

ssm-cli get-diagnostics --output table

Sur Windows Server, lancez ssm-cli.exe get-diagnostics --output table depuis C:\Program Files\Amazon\SSM. Il renvoie une ligne par contrôle avec un statut Success, Failed ou Skipped, et la ligne en échec nomme la condition.

Voici la lecture des lignes :

Côté API, aws ssm describe-instance-associations-status --instance-id i-02573cafcfEXAMPLE renvoie un tableau InstanceAssociationStatusInfos vide tant que l'enregistrement n'a pas réussi, donc un résultat vide au bout de 5 minutes est déjà le signal.

Pour la condition de connectivité, une instance joint soit les endpoints publics par une route HTTPS sortante, soit des VPC endpoints de type interface :

Deux causes de plus valent d'être emportées, parce qu'elles ressemblent à des bugs. Un nœud en statut Connection Lost depuis au moins 30 jours peut disparaître complètement de la liste Fleet Manager tant que le problème de fond n'est pas réglé. Et chaque nœud géré a besoin d'un certificat TLS d'Amazon Trust Services dans son magasin de confiance ; une image maison ou on-premises qui n'en a pas échoue sur une erreur SSL là où vous attendriez un UnknownOperationException de curl -L https://ssm.region.amazonaws.com.

Conseils pour l'examen

• Toute question « l'instance tourne mais n'apparaît pas dans Systems Manager » teste les trois conditions. Lisez l'énoncé pour savoir laquelle a été retirée : pas d'agent, pas d'instance profile, ou pas de route vers les endpoints.
• Un subnet privé sans NAT gateway plus une exigence Session Manager veut dire des VPC endpoints de type interface, et ssmmessages est celui qui porte la session.
• Default Host Management Configuration vaut par compte et par Region, exige IMDSv2, et perd face à un instance profile qui autorise ssm:UpdateInstanceInformation.
• « Aucun port entrant, pas de bastion, pas de clé SSH, et une piste d'audit » est la formule qui désigne Session Manager. Si la même question exige aussi une transcription des commandes, rappelez-vous que le port forwarding et les sessions SSH ne sont pas journalisés.
• Valeurs par défaut de Run Command : concurrence 50, seuil d'erreur 0. Une question où un seul échec a stoppé une commande sur toute la flotte n'a pas fixé --max-errors.
• Pour borner le nombre total d'échecs et pas seulement arrêter la distribution, associez --max-errors à --max-concurrency 1.
• L'historique des commandes dure 30 jours. Toute exigence de rétention plus longue veut dire S3 ou CloudWatch Logs.
• Inventory est un instantané de métadonnées sur calendrier avec un plancher de 30 minutes, et c'est la resource data sync vers S3 qui le rend interrogeable avec Athena à travers les comptes et les Regions.

La règle à emporter : sur AWS, l'accès à une flotte est un problème IAM, pas un problème réseau. Une fois les trois conditions remplies, donner ou retirer l'accès à un serveur devient une modification de policy plutôt qu'une rotation de clés, et chaque action laisse une trace. La leçon suivante s'appuie sur cette même base de nœuds gérés pour garder ces serveurs à jour et empêcher leur configuration de dériver.