Avec la multiplication du nombre de vos instances Amazon Elastic Compute Cloud (Amazon EC2)et la croissance de votre activité, la mise en place d’une solution sécurisée pour vous connecter et administrer vos machines virtuelles est essentielle.
En tant que SysOps, vous pensez dans un premier temps à la mise en place d’un Bastion, d’un VPN, de clés privées, de restrictions d’IP, etc. Il existe cependant une solution SaaS gratuite proposée par AWS qui vous permettra de vous connecter à vos EC2, sans ouvrir un seul port ni exposer aucune IP publique.
Dans cet article nous allons vous présenter AWS Session Manager, un service d’AWS System Manager, puis nous verrons ensemble les choses importantes à savoir pour sa configuration et utilisation.
Session Manager est une des nombreuses fonctionnalités proposée par AWS Systems Manager. Entièrement géré, elle permet de se connecter et de gérer des machines virtuelles (Amazon EC2, machines sur site, etc.), ainsi qu’à vos nœuds Kubernetes sur AWS Elastic Kubernetes Service (EKS), sans pour autant déployer et entretenir une infrastructure basée sur un SSH Bastion.
En plus de vous donner un accès simplifié et sécurisé à un shell sur vos machines, soit via l’AWS CLI, soit via votre navigateur en un clic, Session Manager vous fournira une interface de gestion complète et sécurisée, facilement auditable grâce à une intégration à AWS CloudWatch ou AWS S3, sans pour autant exposer des ports, de maintenir un hôte Bastion ou de gérer des paires de clés SSH.
Vous aurez également la possibilité de vous adapter aux politiques de votre entreprises nécessitant un accès contrôlé à vos machines, tout en étant sensible aux bonnes pratiques de sécurité
Session Manager est une fonctionnalité AWS Systems Manager entièrement gérée. Avec Session Manager, vous pouvez gérer vos instances Amazon Elastic Compute Cloud (Amazon EC2), vos appareils périphériques, vos serveurs et machines virtuelles (VM) sur site. Vous pouvez utiliser soit un shell interactif basé sur un navigateur en un clic, soit l'interface de ligne de commande AWS (AWS CLI). Session Manager fournit une gestion sécurisée et auditable des nœuds sans qu'il soit nécessaire d'ouvrir des ports entrants, de maintenir des hôtes bastion ou de gérer des clés SSH.
Session Manager vous permet également de vous conformer aux politiques d'entreprise qui nécessitent un accès contrôlé aux nœuds gérés, des pratiques de sécurité strictes et des journaux entièrement auditables avec les détails d'accès aux nœuds, tout en offrant aux utilisateurs finaux un accès multiplateforme simple en un clic à vos nœuds gérés. Pour démarrer avec Session Manager, ouvrez la console AWS Systems Manager puis choisissez dans le volet de navigation Session Manager.
Accéder à ses instances EC2 grâce à AWS Session Manager
Prenons comme exemple votre instance EC2, gérée par une équipe composée d’un administrateur, d’un chef de projet et de développeurs :
Vous n’avez pas besoin d’ouvrir un quelconque port ou de mettre en place une infrastructure particulière ; n’ouvrez que les ports nécessaires à votre application (80 et/ou 443 pour un site web, par exemple), et ajoutez une identité IAM à votre EC2 afin d’activer Session Manager sur cette instance.
Créez des comptes de services sur vos instances EC2 (administrator, maintainer, developper, etc.) et assignez ces comptes à vos utilisateurs grâce à un simple tag (SSMSessionRunAs). Vous pourrez ainsi configurer l’accès de chaque utilisateur à chaque instance, facilement.
Configurez l’intégration à CloudWatch et gardez un oeil sur toutes les commandes effectuées et leurs retours, afin de facilement détecter les erreurs commises et de plus facilement vos applications
Enfin, gardez toutes communications entre vos services chiffrés de bout en bout grâce au chiffrement par AWS Key Management Service (KMS).
💡
Vous avez aussi la possibilité de ne lancer qu’une seule commande grâce à Run Command, minimisant les fausses manipulations
Pré-requis pour la configuration
Gestion des logs
Par défaut, la console de Session Manager vous fournira des détails en rapport avec les sessions en cours et terminée, vous permettant de facilement voir les utilisateur connectés et depuis quel compte, avec les dates de début et de fin de session.
En revanche, si vous voulez activer les logs de session et voir, pour chaque session, quelles commandes ont été rentrées et quel était leurs retours, vous devez connecter soit un Log Group Amazon CloudWatchsoit un Bucket Amazon S3.
Tandis qu’avec Amazon S3 seul la journalisation de session est activée, avec Amazon CloudWatch vous pouvez avoir également accès à la transmission continue des logs de sessions, plutôt que d’attendre la fin de la sessions pour avoir accès aux logs ; c’est pour ça que nous utiliserons Amazon CloudWatch pour la suite de cet article, que nous encrypterons avec KMS.
Instances EC2 compatibles
Sur le papier, toutes les instances EC2 (et même vos ressources on-premise) sont compatibles avec SessionManager : il vous suffit d’installer l’AWS Systems Manager Agent (SSM Agent) sur ces dernières.
Néanmoins, certaines images Amazon pour vos instances EC2 sont livrées avec l’agent SSM déjà installé. Seulement ces images permettent de ne pas avoir besoin d’installer l’agent SSM :
Amazon Linux Base AMIs dated 2017.09 and later
Amazon Linux 2
Amazon Linux 2 ECS-Optimized Base AMIs
macOS 10.14.x (Mojave), 10.15.x (Catalina), and 11.x (Big Sur)
SUSE Linux Enterprise Server (SLES) 12 and 15
Ubuntu Server 16.04, 18.04, and 20.04
Windows Server 2008-2012 R2 AMIs published in November 2016 or later
Windows Server 2016, 2019, and 2022
⚠️
Une fois l’agent SSM en place, il vous faudra ajouter une identité IAM afin d’activer Session Manager sur cette instance.
Comment se connecter à une VM dans un réseau privé avec AWS Session Manager ?
Nous allons maintenant voir comment configurer AWS Systems Manager et les services nécessaires afin d’accéder en toute sécurité à ses VMs grâce à Session Manager.
Configuration de Session Manager
La configuration de Session Manager d’une manière sécurisée nécessite la mise en place de plusieurs éléments en amont :
Deux keys KMS (une pour le Log Group, une pour Session Manager)
Un Log Group Amazon CloudWatch afin de récupérer toutes les informations de session.
Des identités IAM (EC2 et users)
Création des clés principales KMS pour chiffrer les données de session
Afin de garantir une sécurité optimale pour la transmission des données de session, il est nécessaire de les chiffrer à l’aide d'AWS Key Management Service.
Création de la clé pour le Log Group CloudWatch
Nous commençons par créer une clé KMS grâce à l’AWS CLI: aws kms create-key
Notez le KeyId dans les informations qui vous sont retournées par cette commande, nous en aurons besoin pour les prochaines commandes.
Avant de modifier les permissions, nous allons lui attribuer un alias afin de facilement la différencier des autres. On lui donne l’alias system-manager/cloudwatch-loggroup :
aws kms create-alias --alias-name alias/system-manager/cloudwatch-loggroup --target-key-id <KEY ID>
Nous pouvons maintenant récupérer la key policy actuelle et mettre en place nos droits pour chiffrer le Log Group.
On commence par récupérer la policy actuelle :
aws kms get-key-policy --key-id <KEY ID> --policy-name default --output text > ./policy.json
Appliquez enfin la nouvelle policy à la clé :
aws kms put-key-policy --key-id <KEY ID> --policy-name default --policy file://policy.json
Création de la clé pour le Session Manager
Pour Session Manager, la création de la clé sont plus simple :
on commence par créer une clé KMS et noter son ID : aws kms create-key
puis on crée un alias pour cette clée : aws kms create-alias --alias-name alias/system-manager/session-manager --target-key-id <KEY ID>
Création et encryption du Log Group Amazon CloudWatch
Nous allons maintenant créer un Log Group dans Amazon CloudWatch et y connecter notre première clé KMS.
Vous aurez besoin :
du <KEY ARN> de la clé avec l’alias system-manager/cloudwatch-loggroup
du <LOG GROUP NAME> que vous avez défini lors de la mise à jour des policies.
Une fois ces informations en votre possession, vous pouvez créer le Log Group :
aws logs create-log-group --log-group-name <LOG GROUP NAME> --kms-key-id <KEY ARN>
Création et association du rôle IAM pour les instances EC2
Afin d’activer Session Manager sur nos instances EC2, nous devons créer un rôle IAM listant toutes les autorisation nécessaires.
Dans un premier temps, nous allons créer un custom policy avec tous les droits pour System Manager, CloudWatch et KMS ; puis, nous créerons un Role afin d’appliquer cette policy aux instances EC2.
Commencer par créer un fichier system_manager_policy.json, puis ajoutez-y le contenu suivant (sans les commentaires) :
{
"Version": "2012-10-17",
"Statement": [
// Autorise toutes actions avec SSM sur toutes les ressources
{
"Effect": "Allow",
"Action": [
"ssm:DescribeAssociation",
"ssm:GetDeployablePatchSnapshotForInstance",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:GetManifest",
"ssm:GetParameter",
"ssm:GetParameters",
"ssm:ListAssociations",
"ssm:ListInstanceAssociations",
"ssm:PutInventory",
"ssm:PutComplianceItems",
"ssm:PutConfigurePackageResult",
"ssm:UpdateAssociationStatus",
"ssm:UpdateInstanceAssociationStatus",
"ssm:UpdateInstanceInformation"
],
"Resource": "*"
},
// Autorise toutes actions avec les messages SSM sur toutes les ressources
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
// Autorise toutes actions avec les messages EC2 sur toutes les ressources
{
"Effect": "Allow",
"Action": [
"ec2messages:AcknowledgeMessage",
"ec2messages:DeleteMessage",
"ec2messages:FailMessage",
"ec2messages:GetEndpoint",
"ec2messages:GetMessages",
"ec2messages:SendReply"
],
"Resource": "*"
},
// Autorise la decryption de seulement 2 clés KMS (remplacez les <KEY ARN> par les ARN des deux clés KMS créés précédemment)
{
"Effect": "Allow",
"Action": "kms:Decrypt",
"Resource": [
"<KEY ARN>",
"<KEY ARN>"
]
},
// Autorise la génération d'information en rapport avec les clés et accorde des droits d'écriture pour CloudWatch sur toutes les ressources
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
Une fois votre policy configurée, vous pouvez la créer avec la commande suivante :
aws iam create-policy --policy-name CUSTOMSystemManagerPolicyForEC2 --policy-document file://system_manager_policy.json
Créez ensuite le fichier ec2-trust-policy.json et ajoutez-y ce schéma :
Ensuite, créez le Role AWS avec la commande suivante :
aws iam create-role --role-name CUSTOMServiceRoleForSystemManager --assume-role-policy-document file://ec2-trust-policy.json
Puis attachez à ce Role AWS la policy précédemment crée :
aws iam attach-role-policy --policy-arn <CUSTOMSystemManagerPolicyForEC2 ARN> --role-name CUSTOMServiceRoleForSystemManager
Ensuite, afin de pouvoir attacher ce Role AWS à vos instances EC2, il va falloir créer un instance-profile et l’associer avec votre Role AWS.
Commencez par créer votre instance-profile :
aws iam create-instance-profile --instance-profile-name CUSTOMServiceRoleForSystemManager-Instance-Profile
Puis associez le avec votre Role AWS :
aws iam add-role-to-instance-profile --role-name CUSTOMServiceRoleForSystemManager--instance-profile-name CUSTOMServiceRoleForSystemManager-Instance-Profile
Enfin, récupérez l’id de votre instance EC2 et lancez cette commande afin de l’associer avec votre instance-profile :
aws ec2 associate-iam-instance-profile --instance-id <EC2 INSTANCE ID>--iam-instance-profile Name=CUSTOMServiceRoleForSystemManager-Instance-Profile
💡
Vous pouvez vérifier que l’instance-profile a bien été ajoutée avec la commande aws ec2 describe-iam-instance-profile-associations
⚠️
Si jamais votre instance EC2 est déjà associé avec un instance-profile, vous devrez utiliser aws ec2 replace-iam-instance-profile-association à la place de aws ec2 associate-iam-instance-profile
Configuration de Session Manager avec KMS et CloudWatch
Avant de nous connecter à notre instance, nous allons mettre en place davantage de sécurité en chiffrant les données de sessions que générera Session Manager.
Pour cela, nous nous rendons dans notre AWS Console, service Systems Manager, rubrique Session Manager :
Cliquez sur Preferences, puis Edit. Vous arriverez sur la page de configuration suivante :
Commençons par régler nos préférences générales. Réduisez le Idle session timeout à 5 minutes, puis cochez la case Enable KMS encryption. Ces options apparaissent :
Cochez Select a KMS key, puis choisissez la clé avec l’alias alias/system-manager/session-manager.
Configurons maintenant CloudWatch afin d’activer la récupération continue des informations de session. Commencez par cocher la case CloudWatch logging, la partie suivante devrait s’afficher :
Comme vous pouvez le voir sur la capture d’écran, vous devrez :
Sélectionner Stream session logs dans la partie Choose your preferred logging option
Cocher la case Allow only encrypted CloudWatch log groups
Sélectionner Choose a log group name from the list puis recherchez le nom de votre Log Group créé précédemment ; sélectionnez-le, en vérifiant qu’il est bien Encrypted
Sauvegardez ces paramètres en cliquant sur Save en bas de la page, et vous êtes prêts à vous connecter à vos instances EC2 grâce à AWS Systems Manager !
Connexion à une instance EC2 avec Session Manager.
Maintenant qu’AWS Systems Manager et votre instance EC2 sont configurés, nous allons pouvoir nous y connecter et explorer les différentes options qui s’offrent à nous.
Connexion à l’instance EC2
Pour vous connecter à votre instances EC2, vous avez le choix entre 2 solutions :
par l’AWS Console, vous offrant un accès à votre instance dans le navigateur
par l’AWS CLI, vous offrant un accès à votre instance dans votre terminal préféré
Pour lancer une session dans votre navigateur, rendez-vous dans votre AWS Console, service Systems Manager, rubrique Session Manager :
Cliquez sur Start session, vous arriverez sur cette page :
Sélectionnez votre instance EC2, puis cliquez sur Start session. Un nouvel onglet se lancera, où vous aurez accès à un shell à travers votre navigateur !
Pour vous connecter via l’AWS CLI, vous devez vous munir de l’id de votre instance EC2 et de lancer cette commande :
aws ssm start-session --target <EC2 INSTANCE ID>
Maintenant que les instances sont configurées, que notre chiffrement avec KMS est en place et que la connexion marche, nous allons faire un point sur les options supplémentaires qui s’offrent à nous.
Utilisateur par défaut, session et permissions
En nous connectant à notre machine avec Session Manager, nous pouvons constater plusieurs choses :
l’interpréteur de commande par défaut est sh
l’utilisateur auquel nous sommes connecté est ssm-user
nous nous trouvons dans le dossier /usr/bin
On remarque également que ssm-user a l’autorisation d’utiliser sudo sans mot de passe. Renseignons-nous un peu plus sur cet utilisateur :
Les règles d’utilisation de sudo pour l’utilisateur ssm-user se trouve dans le fichier /etc/sudoers.d/ssm-agent-users
Dans ce fichier, seul l’utilisateur ssm-user est enregistré, avec la capacité d’utiliser sudo sans mot de passe.
On remarque, en regardant dans /etc/passwd, que notre shell par défaut et notre home ne correspondent pas avec notre session actuelle (/usr/bin/sh plutôt que /bin/bash, et /usr/bin plutôt que /home/ssm-user)
Enfin, on remarque qu’un groupe porte le même nom que notre utilisateur, avec son GID identique à l’UID de ssm-user (1001)
Concernant l’agent, regardons les processus qui nous permettent de nous connecter à notre instance. Nous pouvons noter la présence de 3 services différents :
On peut voir que pour chaque session, un nouveau ssm-session-worker est lancé avec l’id de votre session. En cas d’arrêt du processus amazon-ssm-agent, votre session continuera de tourner, mais il vous sera impossible d’en créer une nouvelle sans redémarrer votre instance. En cas d’arrêt du processus ssm-session-worker <SESSION ID>, la session se fermera mais vous serez toujours dans la capacité de vous reconnecter sans pour autant redémarrer votre instance EC2.
Regardons enfin les logs du service amazon-ssm-agent, regroupant nos trois processus vu au dessus :
Nous pouvons voir que l’agent va enregistrer, dans ses logs, toutes les interventions d’un utilisateur utilisant sudo avec :
l’utilisateur de base (ssm-user)
le chemin où la commande a été lancée (/usr/bin)
l’utilisateur cible de sudo (root)
la commande lancée (/bin/echo ... par exemple)
Les autres commandes, n’utilisant pas sudo, ne seront pas enregistrées dans les logs du service amazon-ssm-agent. Regardons dans les informations remontées à AWS CloudWatch pour aller plus loin dans le monitoring de session.
Analyse des données de sessions transmises à CloudWatch
Afin d’analyser les logs transmis, nous nous rendons dans l’AWS Console → AWS CloudWatch → Log groups → system-manager/session-logs. Nous aurons accès à une liste de sessions :
Sélectionnez-en une, puis regardons les logs transmis par cette session :
Vous pouvez voir que, pour chaque commande effectuée, AWSSystems Manager transmet :
des informations à propos de l’event (eventVersion, eventTime)
la region (awsRegion)
l’instance cible (target)
l’identité de l’utilisateur utilisant Systems Manager (userIdentity)
l’utilisateur utilisé par Session Manager (runAsUser)
l’identifiant de la session (sessionId)
la commande lancée, et son retour (sessionData)
⚠️
Faites attention lorsque vous rentrerez des informations sensibles à l’aide de AWSSystems Manager, comme des secrets ou autre : ils seront enreegistrés en clair dans AWSCloudWatch.
Vous pouvez par exemple utiliser pass ou n’importe quel autre gestionnaire de secrets, afin d’injecter des informations sensibles dans vos lignes de commandes.
Configuration supplémentaire et conclusion
Meilleure gestion des utilisateurs grâce à l’option Run As
Ajout des utilisateurs à nos instances EC2
Avant toute chose, vous devez créer l’utilisateur sur votre machine virtuelle.
Possible plusieurs utilisateurs ? → via création locale (useradd, groupadd) puis en adaptant le Tag IAM
Permissions accordées à l’user ? modifiables ? → gestion d’utilisateur local = Tag sur l’user IAM (SSMSessionRunAs) + sudo / groups
Une fois sur la page de configuration de Session Manager, cochez la case Enable Run As support for Linux instances afin de pouvoir vous connecter, sur vos instances Linux, avec un utilisateur différent de celui créé de base. Laissez la zone de texte Operating system user name vide si vous ne voulez pas avoir d’utilisateur par defaut (et donc refuser tous les utilisateurs n’ayant pas de tag pour accéder à n’importe quelle instance via Session Manager) :
Sauvegardez les modifications, puis passez à l’étape suivante.
Ajout du tag aux utilisateurs IAM et connexion avec le nouveau compte
Sur quel utilisateur se connecte session manager ? → ssm-user par défaut, autre possible ? → oui, via IAM Tag sur l’user IAM (SSMSessionRunAs)
Comment gérer globalement une politique d’accès à toutes les machines virtuelles ? (par env., etc.)
Conclusion : une véritable alternative aux autres méthodes de connexion ?
Pérennité et maintenance de la solution
Maintenance de l’agent SSM ? mise à jour manuelle ou que faire si agent down ? stop puis restart
Conclusion: pousser plus sur une procédure d’accès si l’agent tombe
Prix total de la solution (Systems Manager + CloudWatch + KMS)
Pricing : peanuts
Le coût de la solution n’est pas très élevée pour tous les avantages qu’elle apporte.
Avantages et inconvénients AWS Session Manager / EC2
AWS Session Manager :
Avantages
Inconvénients
Solution totalement intégrée avec les autres services AWS (permissions IAM, restrictions sur des tags…)
Nécessite des mécanismes complémentaires en cas d’accès à une zone privée (VPC Endpoints)
Permet de désactiver l’accès en SSH à l’ensemble des instances
ㅤ
Traçabilité des connections via l’historique des sessions SSM
ㅤ
Auditabilité des actions effectuées possible dans S3 ou Cloudwatch
ㅤ
EC2 Instance Connect :
Avantages
Inconvénients
Ajoute du contrôle sur qui peut se connecter à une instance
Traçabilité limitée à l’envoi de clés sur une instance. Impossible de savoir si une connexion a été réellement initiée
Simplifie grandement le processus de déploiement des clés publiques
Pas d’auditabilité sur les actions effectuées sur l’instance
Plus besoin de déploiement de clés à long terme
Ajout d’une sur-couche à la connexion native SSH
S'inscrire à la newsletter DevSecOps Keltio
Pour recevoir tous les mois des articles d'expertise du domaine
Comment se connecter à une VM dans un réseau privé avec AWS Session Manager ?
