AWS Connexion à une instance EC2 – Partie 4: EC2 Instance Connect Endpoint

AWS Connexion à une instance EC2 – Partie 4: EC2 Instance Connect Endpoint

AWS Connexion à une instance EC2 – Partie 4: EC2 Instance Connect Endpoint

omment se connecter à une instance EC2, privée ou publique, de façon sécurisée depuis internet.

Qu’est-ce que AWS EIC Endpoint ?

EIC Endpoint est un Identity-aware TCP proxy (IAP), permettant de contrôler l’accès à vos machines. Grâce à lui, vous pouvez établir directement une connexion à toutes les instances de votre VPC, même les privées (sans IP publique). Ils n’exigent pas que votre VPC dispose d’une connectivité Internet directe à l’aide d’un IGW ou d’une passerelle NAT, aucun agent n’est nécessaire sur la ressource à laquelle vous souhaitez vous connecter, ce qui facilite le management notamment pour les architectures hybrides. Et enfin, ils préservent les flux de travail existants, ce qui vous permet de continuer à utiliser votre logiciel client préféré sur votre poste de travail local pour vous connecter et gérer vos ressources. En termes de sécurité, IAM et les groupes de sécurité peuvent être utilisés pour contrôler l’accès, et l’authentification et l’autorisation sont évaluées avant que le trafic n’atteigne le VPC.

Les étapes pour utiliser EIC Endpoint

Depuis la console
Créer/éditer le groupe de sécurité (security group) qui sera associé au EIC Endpoint

Règle entrante: aucune règle n’est nécessaire.

Règle sortante: ouvrir le port de connexion (ex: 22 pour SSH (linux) – 3389 pour RDP (windows) etc…) avec pour destination le groupe de sécurité de la/des instance(s), afin de permettre la connexion.

Créer/éditer le groupe de sécurité (security group) de la/des instance(s)

Règle entrante: ouvrir le port de connexion (ex: 22 pour SSH (linux) – 3389 pour RDP (windows) etc…) avec pour destination le groupe de sécurité du EIC Endpoint.

Règle sortante: aucune règle n’est nécessaire.

 

Créer l’EIC Endpoint

VPC -> Endpoint -> Create Endpoint

Instance EC2 -> Connect -> EC2 Instance Connect -> Connect using EC2 Inctance Connect Endpoint -> EC2 Instance Connect Endpoint -> create an endpoint.

La création est très simple, il suffit de sélectionner le VPC, Secuity group et le subnet.

Connexion à l’instance

Pour toutes les Instance du VPC, ayant le groupe de sécurité bien configuré:

Connect -> Connect using EC2 Instance Connect Endpoint laisser les valeurs par défauts et sélectionner le EIC Endpoint.

En CLI

Création de l’EIC Endpoint

Une fois les groupes de sécurité configuré, créer l’EIC Endpoint:

aws ec2 create-instance-connect-endpoint \

–subnet-id [SUBNET] \

–security-group-id [SG – ID]

Connexion à l’instance

aws ec2-instance-connect ssh –instance-id [INSTANCE]

Dans l’exemple ci-dessous, nous utilisons l’EIC Endpoint en combinaison avec EC2 Instance Connect pour la gestion des clés SSH. Il est bien sûr tout à fait possible d’utiliser des clés SSH que l’on a générées préalablement.

Ces informations sont correctes au moment de la rédaction de l’article, cependant, il est important de noter que les services AWS évoluent constamment. Il est possible que certaines fonctionnalités, noms, etc. soient différents ou aient changé depuis lors.

AWS Connexion à une instance EC2 – Partie 3: SSM Session Manager

AWS Connexion à une instance EC2 – Partie 3: SSM Session Manager

AWS Connexion à une instance EC2 – Partie 3: SSM Session Manager

On continue dans la série des différentes méthodes pour se connecter à une instance EC2 grâce au service AWS Systems Manager (SSM) – Session Manager. À l’image de EC2 Instance Connect, cette méthode nous dispense l’utilisation, et donc la gestion, de clés SSH et rend encore plus accessible la gestion de flotte d’instances.

Qu’est-ce que AWS SSM – Session Manager ?

Session Manager est un service d’AWS System manager qui permet une gestion sécurisée et traçable des instances sans nécessiter l’ouverture de ports entrants, la gestion d’hôtes bastion ou l’utilisation de clés SSH. Il permet de se conformer aux politiques d’entreprise en assurant un accès contrôlé aux instances gérées, en appliquant des pratiques de sécurité strictes et en fournissant des journaux d’audit détaillés pour chaque session. De plus, il offre aux utilisateurs finaux un accès multiplateforme en un seul clic à ces instances gérées, via le console AWS ou en CLI. Enfin, il peut tout à fait être utilisé dans un environnement hybride ou multi-cloud et offrir une gestion centralisée de toutes les machines en un seul point.

Les étapes pour utiliser AWS SSM – Session Manager

Configurer un rôle IAM

Configurer un rôle IAM pour le service EC2 avec la politique “AmazonSSMManagedInstanceCore”. Cela permet à SSM Session Manager d’établir une communication sécurisée avec l’instance EC2 via l’API SSM (utilisant des websockets). L’instance doit donc être autorisée à échanger des données avec le service.

Appliquer le rôle IAM à l’instance EC2

Que ce soit lors de sa création ou sur une instance déjà en cours d’exécution. Il est possible d’utiliser SSM Session Manager sur des instances existantes en ajoutant simplement les autorisations via le rôle IAM et en suivant les étapes nécessaires.

Si vous travaillez déjà avec une flotte d’instance et que vous souhaitez les configurer pour l’utilisation de session manager, le plus simple est d’utiliser le service “Quick Setup” de SSM.

Pour ce faire, rendez-vous dans SSM – Quick Setup et créez une nouvelle configuration de type “Host Management”.

Sélectionnez les options souhaitées comme la mise à jour de l’agent SSM automatiquement ou la configuration de l’agent CloudWatch.

Puis sélectionnez la région et la liste d’instances via tag, resource group, manuel…

Le service se chargera, entre autres, de créer le rôle IAM adéquat et de paramétrer toutes les instances voulues. À noter que la configuration peut prendre plusieurs minutes avant de se finaliser et que l’on puisse utiliser Session manager.

S’assurer que l’AMI utilisée a l’agent SSM installé

La plupart des AMIs courantes incluent l’agent SSM par défaut.

Liste des instances compatibles:

  • Amazon Linux Base AMIs dated 2017.09 and later
  • Amazon Linux 2
  • Amazon Linux 2 ECS-Optimized Base AMIs
  • Amazon Linux 2023 (AL2023)
  • Amazon EKS-Optimized Amazon Linux 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

Si vous utilisez d’autres AMI ou pour les clouds hybrides, voici quelques liens pour pouvoir installer l’agent manuellement:

Configurer le réseau

Il n’est pas nécessaire d’ouvrir des flux entrants spécifiques dans les groupes de sécurité, ce qui est toujours une bonne chose en termes de sécurité. Étant donné que la connexion se fait à partir de SSM, il suffit de configurer les flux sortants appropriés pour permettre la communication.

Au minimum:

  • ec2messages.<region-ID>.amazonaws.com
  • ssm.<region-ID>.amazonaws.com
  • ssmmessages.<region-ID>.amazonaws.com

À noter qu’il n’est pas obligatoire d’avoir une IP publique, à condition que le sous-réseau (subnet) privé passe par une NAT gateway, afin que l’instance puisse sortir sur internet.

Se connecter à l’instance EC2

Avec les autorisations appropriées et une fois que tout est configuré, les utilisateurs peuvent facilement se connecter à leurs instances gérées via la console AWS ou en utilisant les commandes CLI.

AWS Console – EC2 connect

CLI

aws ssm start-session –region <region> –target <instance-id>

Pour conclure, ce service mérite d’être exploré car il est simple d’utilisation et fait partie d’une suite  plus large: System Manager, offrant ainsi une multitude de fonctionnalités d’automatisation pour les flottes d’instances EC2. Vous pourrez lancer des commandes en simultané, gérer les mises à jour, contrôler l’accès en fonction de l’heure ou pour une période spécifique, et bien plus encore.

Ces informations sont correctes au moment de la rédaction de l’article, cependant, il est important de noter que les services AWS évoluent constamment. Il est possible que certaines fonctionnalités, noms, etc. soient différents ou aient changé depuis lors.

AWS Connexion à une instance EC2 – Partie 2: EC2 Instance Connect

AWS Connexion à une instance EC2 – Partie 2: EC2 Instance Connect

AWS Connexion à une instance EC2 – Partie 2: EC2 Instance Connect

Deuxième partie de la série AWS : Connexion à une instance EC2 avec EC2 Instance Connect

Je suis ravi de vous présenter la deuxième partie de notre série sur la connexion à une instance EC2, où nous allons explorer la méthode utilisant “EC2 Instance Connect”. Dans cet article, nous découvrirons comment se connecter à une instance sans avoir besoin de stocker des clés SSH.

Qu’est-ce que EC2 Instance Connect ?

Dans le précédent article nous avons vu comment se connecter à une instance de manière classique en SSH. Pratique et rapide pour se connecter à une instance, mais dans le cloud il n’est pas rare d’avoir tout une flotte d’instances à gouverner et la gestion du cycle de vie des clés SSH peut devenir un réel casse-tête.

Instance Connect est un service proposé par AWS qui permet de se connecter à une instance EC2 sans avoir à gérer des clés SSH. AWS génère et manage automatiquement des clés SSH temporaires pour vous, simplifiant ainsi le processus de connexion sécurisée à vos instances.

Comment EC2 Instance Connect fonctionne

Lorsque la fonction EC2 Instance Connect est activée sur une instance, le démon SSH (sshd) de cette instance est configuré avec un script AuthorizedKeysCommand personnalisé. Ce script met à jour AuthorizedKeysCommand pour lire les clés publiques SSH à partir des métadonnées de l’instance pendant le processus d’authentification SSH, et vous connecte à l’instance.

Les clés publiques SSH ne peuvent être utilisées qu’une seule fois pendant 60 secondes dans les métadonnées de l’instance. Pour vous connecter à l’instance avec succès, vous devez vous connecter à l’aide de SSH pendant cette période. Comme les clés expirent, il n’est pas nécessaire de suivre ou de gérer ces clés directement, comme vous le faisiez auparavant.

Comment utiliser EC2 Instance Connect

Créer une instance sans clés SSH

Le fait de ne pas associer de clés SSH n’est pas obligatoire, Instance Connect fonctionnera tout aussi bien. Mais dans le but de ne plus avoir à se soucier du cycle de vie des clés SSH, dans cet exemple nous n’utilisons pas de clés.

Assurez-vous de lui associer une IP publique !

Instance Connect est installé par défaut sur les AMI suivante:

  • Amazon Linux 2 2.0.20190618 or later
  • Ubuntu 20.04 or later

Si votre AMI ne fait pas partie de cette liste, voici un article qui explique comment l’installer sur tous types d’instances.

Ouvrir le port SSH sur le range AWS

Assurez-vous d’ouvrir le port SSH (par défaut, le port 22) dans le groupe de sécurité associé à votre instance, avec comme source le range d’IPs d’AWS, pour le trafic entrant (inbound).

Vous trouverez la liste des ranges IPs d’AWS ici. Elles sont classées par région et par service.

Pour vous aider à déterminer celle qui vous sied, vous pouvez télécharger cette liste et lancer la commande suivante:

Windows

Get-AWSPublicIpAddressRange -Region us-east-1 -ServiceKey EC2_INSTANCE_CONNECT | select IpPrefix

Linux

jq -r ‘.prefixes[] | select(.region==”us-east-1″) | select(.service==”EC2_INSTANCE_CONNECT”) | .ip_prefix’ < ip-ranges.json

Assurez-vous de modifier la région en lien avec la région sur laquelle est déployé votre instance.

Pour plus de détails voir cet article.

Configurer les droits IAM

Pour utiliser Instance Connect, vous devez configurer les autorisations IAM appropriées.

L’utilisateur IAM doit être en mesure de pouvoir transmettre ses clés SSH à EC2 Instance Connect.

Exemple de policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2-instance-connect:SendSSHPublicKey"
            ],
            "Resource": [
                "arn:aws:ec2:$REGION:$ACCOUNTID:instance/*"
            ],
            "Condition": {
                "StringEquals": {
                    "ec2:osuser": "ec2-user"
                }
            }
        }
    ]
}

Une fois cette policy créé, vous pouvez directement l’assigner à un utilisateur, un group ou un rôle qui sera assumé pour l’utilisateur IAM.

Se connecter depuis la console ou un terminal

Une fois les étapes précédentes terminées, vous êtes prêt à vous connecter à votre instance EC2 à l’aide d’Instance Connect. Vous pouvez le faire

Directement depuis la console AWS en sélectionnant l’instance puis “Connect” puis “EC2 Instance Connect”

  • En utilisant un terminal SSH avec la commande
aws ec2-instance-connect send-ssh-public-key

Concernant le username, je vous renvoie sur le précédent article de cette série où je liste les username par défaut en fonction des AMI utilisées.

AWS Connexion à une instance EC2 – Partie 1: Les Clés SSH

Avec EC2 Instance Connect, la gestion des clés SSH devient plus simple et plus sécurisée, puisque celles-ci sont générées et gérées par AWS de manière éphémère. Vous pouvez ainsi vous concentrer sur votre travail et éviter les tracas liés à la gestion des clés SSH.

Ces informations sont correctes au moment de la rédaction de l’article, cependant, il est important de noter que les services AWS évoluent constamment. Il est possible que certaines fonctionnalités, noms, etc. soient différents ou aient changé depuis lors.

AWS Connexion à une instance EC2 – Partie 1: Les Clés SSH

AWS Connexion à une instance EC2 – Partie 1: Les Clés SSH

AWS Connexion à une instance EC2 – Partie 1: Les Clés SSH

Étape 1 : Créer une instance EC2

Pour cette méthode, la première chose à faire consiste bien souvent à générer la paire de clés SSH qui va nous servir pour la connexion. Mais dans notre cas, AWS s’occupe de tout, donc nous pouvons tout de suite passer à la création de l’instance.

Lors de cette étape, il faudra sélectionner une paire de clés SSH, soit en choisissant une nouvelle paire générée par AWS, soit en utilisant une paire déjà existante, hébergée sur AWS.

Je porte votre attention sur le fait que se sera votre seule et unique chance que configurer une paire de clés SSH via la console de management AWS. Cela sous-entend que si vous oubliez ou que vous vous trompez, il faudra utiliser une autre méthode pour vous connecter à votre instance ou détruire l’instance et la recréer… Mais pas de panique, si aucune clé n’est renseignée au moment de créer l’instance, par sécurité un pop-up vous demandera d’en sélectionner une ou de volontairement choisir l’option de ne pas en utiliser.

Petit aparté : même si depuis la console de management il n’est plus possible d’ajouter des clés SSH, en vous connectant sur votre instance vous pourrez toujours en ajouter/retirer en allant voir dans le dossier “~/.ssh/authorized_keys”, comme vous le feriez sur n’importe quelle machine. Mais ce n’est pas le sujet d’aujourd’hui.

Étape 2 : IP publique

Afin de pouvoir atteindre votre instance depuis le réseau internet, il vous faudra déployer votre instance dans un subnet (sous-réseau) publique et lui associer une IP publique.

Étape 3 : Autoriser la connexion SSH

Avant toute chose revenons sur la notion de “security group”. Ces derniers sont en quelque sorte des firewalls logiciel qui par défaut bloque tout le trafic. Pour le configurer il faut choisir le port ou protocole que l’on souhaite ouvrir, la source (plage d’IPs) et ça pour le trafic entrant “inbound” et sortant “outbound” de votre instance.

Sachant que lorsque rien n’est spécifier, le trafic est bloqué, il faut ouvrir le port 22 – SSH – pour le trafic entrant (inbound). Concernant la source, les bonnes pratiques sont de limiter la plage d’IPs au maximum. Nous vous conseillons donc de mettre votre IP, ou le range de votre entreprise.

Étape 4 : Connexion

Une dernière étape est nécessaire si vous utilisez une paire de clés fraîchement générée, il faut changer les permissions sur votre clé locale afin de s’assurer qu’elle ne soit pas publiquement visible. Pour se faire lancer la commande :

chmod 400 <path/to/key.pem>

Enfin, récupérer l’IP publique ou le DNS de la machine depuis la console de management, et lancer la connexion depuis votre client SSH préféré.

ssh -i “<path/to/key.pem>” @ip

Le “user” dépend de l’AMI utilisé pour lancer l’instance. Voici un tableau des principaux utilisateurs par défaut:

 

AMI  Utilisateur par défaut
Amazon Linux 2023

Amazon Linux 2

Amazon Linux

ec2-user
CentOS centos or ec2-user
Debian admin
Fedora fedora or ec2-user
RHEL ec2-user or root
SUSE ec2-user or root
Ubuntu ubuntu
Oracle ec2-user
Bitnami bitnami
Autre Voir le fournisseur de l’AMI

 

Bonus tip

Tout ça s’est bien joli mais si la machine n’est pas exposée sur internet, elle est sur un réseau privé et n’a donc pas d’adresse IP, est-il quand-même possible de se connecter en SSH dessus ?

Bien entendu !

Une des techniques est d’utiliser une instance relai, généralement appelée “Bastion”. Cette dernière doit être déployée sur le même VPC que le machine que l’on souhaite atteindre, mais dans un subnet publique (configuré avec une internet gateway), afin de pouvoir lui attribuer une IP publique.

D’une part, créez votre bastion en suivant les étapes décrites ci-dessus.

Une fois lancé, téléchargez la clé SSH de votre instance privée, sur le bastion, en utilisant scp par exemple.

D’autre part, modifiez le security group de votre instance privée, en ouvrant le trafic entrant sur le port 22 au security group de l’instance publique. En effet sur AWS, il est possible de configurer un autre security group en source, à la place d’une IP. Cela signifie que le security group “privée” laissera passer les messages sur le port 22, en provenance des instances du security group “publique”. Cela a pour avantage de pouvoir supprimer le bastion lorsque l’on en a plus besoin, et lorsque l’on en recrée un nouveau, même si l’IP change, la connexion est toujours possible sans avoir besoin de tout reconfigurer.

Vous pouvez maintenant vous connecter à votre instance privée, en passant par le bastion. Cette technique est souvent utilisée pour se connecter aux bases de données, qui sont souvent hébergé sur des instances privées.

Ces informations sont correctes au moment de la rédaction de l’article, cependant, il est important de noter que les services AWS évoluent constamment. Il est possible que certaines fonctionnalités, noms, etc. soient différents ou aient changé depuis lors.

fr_FR