SSM vs SSH : quel accès garder pour déployer sur EC2 ?
Pourquoi on déploie sur EC2 via AWS Systems Manager plutôt que par SSH direct, ce que cela simplifie vraiment, et ce que cela ne remplace pas.
- Operations
- Auth
- CI/CD
Sur une instance EC2, beaucoup d’équipes gardent SSH par habitude.
Le raisonnement est simple : on veut pouvoir entrer sur la machine si quelque chose casse.
Le problème, c’est que ce besoin de secours finit souvent par devenir le chemin normal de déploiement.
Le vrai sujet
Le sujet n’est pas de savoir si SSH “marche”. Bien sûr que SSH marche.
Le sujet est de savoir quel accès on veut normaliser pour la production :
- un accès réseau permanent exposé par la machine ;
- ou une commande distante déclenchée via IAM, tracée par AWS, sans port 22 ouvert.
Dans notre cas, le bon choix était le second.
Pourquoi on garde SSM pour le déploiement
AWS Systems Manager nous apporte trois choses utiles d’un coup :
- pas de clé SSH à distribuer ou à faire tourner ;
- pas de port 22 à exposer ;
- une exécution déclenchée depuis le pipeline avec une identité AWS explicite.
Dit autrement, le déploiement devient un sujet d’autorisations IAM et de commandes rejouables, pas un sujet d’accès shell persistant.
Ce que SSH encourage trop facilement
SSH n’est pas mauvais en soi. Le problème est ce qu’il encourage dans beaucoup d’organisations :
- “je me connecte juste pour vérifier”
- “je corrige à la main, on automatisera plus tard”
- “je relance le service moi-même”
Pris une fois, ce raccourci semble anodin. Repris plusieurs fois, il crée une prod qui vit partiellement hors du code et hors du pipeline.
Ce que SSM ne remplace pas
SSM n’est pas un talisman.
Il ne remplace pas :
- des commandes de déploiement lisibles ;
- un bon chargement des secrets ;
- des logs exploitables ;
- un runbook quand le déploiement rate.
Il déplace simplement le point de contrôle : moins d’accès machine permanents, plus d’actions explicites et scriptables.
Notre critère simple
Pour un déploiement applicatif normal, on préfère :
- CI via OIDC pour obtenir des credentials temporaires ;
- SSM pour exécuter la commande sur l’instance ;
- zéro SSH direct dans le chemin nominal.
Si quelqu’un doit entrer manuellement sur la machine pour que le déploiement passe, c’est en général que le système de déploiement n’est pas encore assez propre.
Avec du recul
Le gain principal n’est pas “la sécurité” au sens abstrait.
Le vrai gain, c’est la discipline opérationnelle.
SSM nous aide à garder une frontière nette :
- le pipeline déploie ;
- l’IAM autorise ;
- la machine exécute ;
- et la prod ne dépend pas d’une clé privée qui traîne encore quelque part.