Vers un monde sans bastion

La mise en place de serveurs bastion est une pratique commune pour donner accès à des ressources sécurisées dans votre virtual private cloud (VPC). Nous utilisons cette technique dans certains Quick Starts (https://thinkwithwp.com/quickstart/?quickstart-all.sort-by=item.additionalFields.updateDate&quickstart-all.sort-order=desc). Deux fonctionnalités Amazon Web Services (AWS) vous permettent néanmoins de vous connecter à votre infrastructure de manière sécurisée sans avoir à mettre en œuvre de bastion.

Ne pas déployer de bastion vous permet d’améliorer la sécurité et les possibilités d’audit de vos solutions en gérant le contrôle d’accès de manière centrale et en limitant les connections entrantes. Session Manager ne nécessite pas l’ouverture des port SSH ou Microsoft Windows PowerShell vers vos instances. Pour aller plus loin sur l’usage et les bénéfices d’AWS Systems manager Session Manager, vous pouvez consulter la documentation.

Dans cet article, nous allons nous concentrer sur une description générale de l’implémentation et de la configuration vous permettant d’utiliser Session Manager pour vous connecter en SSH à une instance. Une autre possibilité consiste à utiliser Amazon Elastic Compute Cloud (Amazon EC2) Instance Connect.

Avant de commencer

N’hésitez pas à consulter la documentation détaillée : Premiers pas avec Session manager qui vous donne plus de détails sur le service.
Pour suivre cet article, si vous souhaitez tester la connexion en utilisant un client SSH (troisième étape), vous aurez besoin d’une paire de clés publique/privée pour vous connecter à votre instance. Vous pouvez la créer ici. Cette paire de clé ne sera pas nécessaire pour les 2 premières étapes (AWS CLI et console AWS).
Pour effectuer une connection avec l’Interface de Ligne de Commande (CLI) AWS, vous devez l’avoir installée sur votre poste de travail en suivant les instructions de ce lien.

Mise en place

L’utilisation de Session Manager nécessite l’installation de l’agent AWS Systems Manager (SSM Agent) sur l’instance EC2 cible. En outre, vous devez ajouter un rôle Identity and Access Management (IAM) qui autorise l’instance à accéder au service Systems Manager. Voici une description du rôle minimal nécessaire (extrait d’un template CloudFormation) :

EC2SSMRole:
  Type: "AWS::IAM::Role"
  Properties:
    AssumeRolePolicyDocument:
      Version: "2012-10-17"
      Statement:
        - Effect: "Allow"
          Principal:
            Service: ["ec2.amazonaws.com"]
          Action: "sts:AssumeRole"
    Path: "/"
    ManagedPolicyArns:
      - 'arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore'
      - 'arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy'

(Vous pouvez également définir une bucket policy S3 spécifique pour la gestion des logs voir détails ici).

Les instances EC2 cibles doivent disposer de l’agent SSM à jour pour autoriser la connexion SSH. Il est préinstallé sur Amazon Linux 2 (voir documentation concernant la liste des AMIs pour lesquelles l’agent SSM est préconfiguré). Dans le cas où il n’est pas pré-configuré, vous pouvez l’installer avec la commande suivante :

sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm

Tests

Le modèle (template) CloudFormation disponible ici déploie les éléments nécessaires à un test :

un VPC, sur le modèle de l’AWS VPC Quick Start, disposant de deux sous-réseaux publics et deux sous-réseaux privés situés dans deux Zones de Disponibilités différentes,
Le rôle IAM décrit plus haut,
Dans l’un des sous-réseaux privés, une instance Amazon Linux 2 avec le dernier agent SSM. Cette instance n’a pas d’accès à internet mais vous pourrez y accéder sans serveur bastion en utilisant Session Manager.

Déploiement

Déployez le modèle (template) CloudFormation par exemple dans la région Paris (eu-west-3):
1. Option 1 : Pour tester la connection en utilisant uniquement l’Interface de Ligne de commande AWS (CLI) ou la console AWS, déployez ce modèle de template CloudFormation sans la paire de clés.
2. Option 2 : Pour tester également la connection via ssh, Déployez ce modèle,
Quand le statut de la pile (stack) CloudFormation passe à CREATE_COMPLETE, allez vers l’onglet Sorties (Output) et copiez la valeur de la clé MyEC2Instance.

Ouvrez une session

Option 1 – Ouvrir une session en utilisant l’Interface de Ligne de commande AWS (CLI)

Pour ouvrir une session vers l’instance depuis votre poste de travail, entrez la commande suivante
Attention : remplacez MyEC2InstanceValue par l’identification de l’instance que vous avez copié à l’étape précédente (Au format i-xxxxx).

aws ssm start-session --target MyEC2InstanceValue --region eu-west-3

Comme vous le remarquez, il n’est pas nécessaire d’avoir ouvert de ports ni d’utiliser de paire de clés pour ouvrir cette session.

Option 2 – Ouvrir une session en utilisant la Console AWS Systems Manager

Allez dans la console AWS, naviguez dans le service Systems manager, cliquez sur Gestionnaire de session (Session manager) dans le bandeau de gauche. Cliquez sur Démarrer une session.

Sur la page Démarrer une session, dans l’encart Instances cibles (Target instances), choisissez l’instance que vous venez de créer et cliquez sur Démarrer une session.

Votre navigateur ouvre un nouvel onglet contenant un terminal sur votre instance.

Option 3 – Démarrer une session depuis votre client SSH

Cette option nécessite l’installation de la dernière version du plugin Session Manager sur votre poste de travail ainsi qu’une version de l’interface de ligne de commande (CLI) AWS égale ou supérieure à 1.16.12. Il est aussi nécessaire de disposer d’une paire de clés dans la région de déploiement de la pile (Stack) CloudFormation et d’avoir déployé le second modèle (template).

1. Sur votre poste de travail, modifiez votre fichier de configuration SSH pour utiliser une commande proxy. Sur système d’exploitation Linux ou Mac, modifiez le fichier ~/.ssh/config

# SSH over Session Manager
host i-* mi-*
    ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

Pour plus de détails vous pouvez consulter la documentation.

2. Ouvrez une fenêtre de terminal, assurez-vous que la variable SHELL a été correctement assignée. Vous pouvez vérifier ce point en lançant la commande echo $SHELL, si vous n’obtenez aucun résultat ou la valeur /bin/false, lancez la commande suivante:

export SHELL=$(which bash)

3. Assurez-vous que votre variable AWS_DEFAULT-REGION pointe sur la région de déploiement de votre instance. (par example eu-west-3)

export AWS_DEFAULT_REGION=eu-west-3

4. Démarrez une session vers votre instance en utilisant la commande suivante :

Attention : remplacez MyEC2InstanceValue par l’identification de l’instance que vous avez copié à l’étape précédente (Au format i-xxxxx), et chemin/paire.pem par le chemin d’accès et le nom de votre fichier comprenant la paire de clé utilisée au démarrage de l’instance.

ssh -i chemin/paire.pem ec2-user@MyEC2InstanceValue

Nettoyage des ressources

Une fois vos tests terminés, allez dans CloudFormation et supprimez la pile (Stack) ssm-ssh-demo pour éviter des coûts supplémentaires liés aux ressources crées.

Conclusion

En suivant cet article, vous avez déployé un rôle IAM pour vos instances EC2 situées dans un sous-réseau privé leur permettant de recevoir des connexions sécurisées en utilisant le service AWS Systems Manager Session Manager, et ce sans avoir besoin de déployer de serveur bastion. Grâce à ce service, il n’est plus nécessaire d’ouvrir les ports d’administration entrants vers vos instances et seuls les utilisateurs disposant des autorisations nécessaires à l’exécution des commandes SSM peuvent ouvrir des sessions. Cette architecture vous permet d’améliorer votre posture de sécurité et l’audit d’accès de votre infrastructure. Merci d’avoir suivi cet article et n’hésitez pas à laisser un commentaire.

Article contribué par Vinod Shukla et traduit en français par Jean Malha, Architecte de Solutions AWS, LinkedIn.

Article original en anglais : https://thinkwithwp.com/blogs/infrastructure-and-automation/toward-a-bastion-less-world/

Le Blog Amazon Web Services