La configuration de SSL pour les microservices est difficile. Vous pouvez terminer la session TLS au niveau d’un équilibreur de charge à la périphérie de votre réseau, mais cela pourrait ne pas être suffisamment sécurisé. Vous pouvez configurer chacune de vos images Docker pour obtenir des certificats et des clés privées au moment de l’exécution. Mais cela devient délicat si vos services utilisent un grand nombre de langages et de cadres différents. Heureusement, il existe un moyen simple et unifié de configurer TLS pour tous vos microservices. Dans cet article, je vais vous guider à travers un exemple de projet qui configure Envoy pour chiffrer le trafic interne dans un service AWS ECS. Il suffit d’un fichier de configuration et de quelques lignes supplémentaires dans vos définitions de tâches.
Tout d’abord, considérons une approche différente : la terminaison SSL à la périphérie. De nombreuses architectures ne chiffrent pas le trafic interne. Ces systèmes terminent généralement les sessions SSL au niveau d’un équilibreur de charge à la périphérie du réseau. Ils transmettent ensuite les demandes en HTTP simple aux services dorsaux.
Cette approche assure la sécurité jusqu’à la périphérie du réseau, et pas au-delà. Pour certaines entreprises, c’est suffisant. Et cela rend le déploiement beaucoup plus facile. L’équilibreur de charge ayant déchiffré le trafic, vos applications n’ont pas à se soucier du SSL.
Mais que faire si vous ne pouvez pas envoyer vos données en clair, même à l’intérieur des murs de votre réseau privé ? Vous pouvez être amené à utiliser la sécurité de la couche de transport jusqu’aux hôtes sur lesquels vos conteneurs sont exécutés. C’est là qu’Envoy est utile. Envoy aide à la découverte de services, au traçage et au SSL. Il suffit de mettre un conteneur dans ECR et de mettre quelques lignes supplémentaires dans vos définitions de tâches.
Ce blog présentera Envoy et vous guidera ensuite à travers les étapes de sa configuration dans ECS. Ou si vous voulez passer directement au projet d’exemple.
Qu’est-ce qu’Envoy ?
Si vous ne connaissez pas bien Envoy, je vous recommande de consulter cet article sur le sujet avant de poursuivre votre lecture.
Vous connaissez probablement les proxies frontaux qui prennent le trafic entrant et l’envoient aux services de soutien en fonction du chemin ou du numéro de port. Envoy est différent. Il s’agit d’un proxy latéral, un processus léger qui s’exécute dans un conteneur à côté de votre application et qui achemine tout le trafic entrant et sortant.
Au lieu d’envoyer vos demandes à un équilibreur de charge fonctionnant ailleurs, vous pouvez les envoyer à un proxy fonctionnant sur localhost. En d’autres termes, Envoy abstrait le réseau de vos services. Outre l’abstraction du réseau, Envoy peut appliquer des filtres au trafic entrant et sortant pour ajouter un chiffrement ou un traçage.
Comment configurer Envoy pour gérer le trafic SSL ?
Envoy lit la configuration depuis un fichier yaml au moment de l’exécution. Dans ce fichier yaml, vous pouvez spécifier des listeners pour gérer le trafic. Dans notre démarche, nous allons demander à Envoy d’utiliser un filtre http_connection_manager pour gérer le trafic TLS et le proxyer vers un serveur Flask écoutant sur un port différent sur le même hôte.
Dans cet exemple, tout fonctionnera dans ECS avec des certificats auto-signés, mais en production, vous voudrez utiliser les certificats d’ACM.
Dans cet exercice, nous utiliserons Terraform pour :
- Créer des images Docker pour Envoy et un petit service Flask. L’image Envoy contient un script de démarrage qui récupère le nom DNS de l’instance à partir d’une variable environnementale et l’utilise pour créer un certificat SSL auto-signé.
- Créer une définition de cluster, de service et de tâche ECS, ainsi qu’un nom DNS route53 pointant vers celle-ci. En configurant un répertoire de service ECS lorsque nous créons notre service ECS, CloudMap crée automatiquement le nom DNS et le mappe aux instances Fargate où nos tâches sont exécutées.
Pour suivre cette procédure, vous aurez besoin d’un compte AWS avec accès à ECS. Les ressources créées au cours de ce didacticiel ne doivent pas coûter plus de 5 $. N’oubliez pas d’appeler « terraform destroy » lorsque vous avez terminé.
Conditions préalables
-
- Docker
- Awscli
- terraform 0.12
- Accès à la console AWS
Procédure
- Clonez l’exemple de répertoire depuis Github
- Provisionnez le cluster ECS, le service et la définition des tâches avec Terraform. Vous devez utiliser terraform v0.12. Il vous sera demandé un ID de VPC et de sous-réseau, ainsi qu’un rôle ARN pour la tâche ECS, gardez-les à portée de main. Le rôle est utilisé à la fois comme rôle de tâche et comme rôle d’exécution de tâche. Il a besoin (au moins) de l’autorisation de lire depuis ECR, de créer des flux de journaux et de placer des enregistrements dans les journaux de Cloudwatch.
$ terraform init $ terraform apply
- Accédez à la console ECS. Vous devriez voir un nouveau cluster appelé envoy-ssl-tutorial.
- Vous devrez vous connecter en SSH à une instance EC2 dans votre compte AWS pour tester la connexion HTTPS, puisque nous utilisons un espace de noms DNS privé. Depuis votre instance, exécutez la commande suivante : le drapeau « -k » indique à curl de fonctionner en « mode non sécurisé », de sorte qu’il accepte le certificat auto-signé.
$ curl -k https://envoy-ssl-tutorial.dev/service
- Si la connexion fonctionne, vous devriez voir un message qui commence par « Bonjour depuis le proxy SSL Envoy !” Si la connexionne fonctionne pas, vérifiez les ID de VPC et de sous-réseau que vous avez transmis à terraform et assurez-vous d’avoir transmis l’ARN de rôle correct.
- Appelez terraform destroy pour supprimer la pile
Lectures recommandées
J’espère que ce blog et l’exemple de répertoire connecté vous ont donné envie d’en savoir plus. Les articles suivants du blog de TurbineLabs constituent une excellente introduction.
