AWS Terraform Snitcher

Snitch (chivato en espagnol, « dedo-duro » en argot portugais), si vous regardez habituellement CNN, principalement des sujets politiques, c’est un mot que vous entendez probablement beaucoup. Le sens du dictionnaire est : « dire secrètement à quelqu’un d’autorité que quelqu’un d’autre a fait quelque chose de mal, souvent dans le but de semer le trouble« . D’accord, cela semble peut-être trop fort pour notre cas, mais ce que nous voulons, c’est une sorte de chose similaire : attraper (et qui a causé) les dérives dans l’état Terraform.

Dérive Terraform

Terraform Drift, c’est lorsque l’état réel de votre infrastructure n’est pas égal à l’état défini par votre configuration (Infrastructure-as-Code), alors – ils diffèrent déjà.

Il existe de nombreux outils (tiers, open-source, etc.) qui peuvent vous aider, comme toujours chacun avec ses avantages et ses inconvénients (gratuit, coûteux, complexe, trop simple, etc.). Gardez à l’esprit que l’objectif ici n’est pas de montrer une manière définitive de gérer cela, ni une comparaison entre les alternatives, en fait c’est juste une excuse pour pratiquer et affiner nos compétences dans une solution d’architecture événementielle AWS.

Par conséquent, l’intention ici est de créer une architecture de solution, en utilisant les ressources AWS, pour découvrir ces dérives et prendre des mesures pour les résoudre. Nous pouvons profiter de l’une de nos architectures événementielles actuellement implémentées (si nous en avons une), ou si nous n’en avons pas encore, c’est un exemple simple (et une excuse) pour commencer.

Architecture événementielle chez AWS

Les événements sont émis par les services dans l’ensemble d’AWS et peuvent être détectés à l’aide du bus d’événements par défaut d’AWS EventBridge. Il est même possible de capturer des événements d’autres fournisseurs de services (SaaS), ainsi que de créer vos propres événements et bus d’application personnalisés. Cependant, dans cet exemple, le bus d’événements par défaut est suffisant pour nos besoins.

Événements AWS EventBridge et AWS CloudWatch

EventBridge utilise la même API de service et la même infrastructure de service sous-jacente d’AWS CloudWatch Events. Comme AWS a appris avec ses clients qu’AWS CloudWatch Events était idéal pour créer des architectures événementielles, ils ont décidé d’ajouter de nouvelles fonctionnalités pour aider à créer ce type d’architecture. Mais plutôt que de garder cela sous AWS CloudWatch, ils ont publié ces fonctionnalités sous un nouveau nom, AWS EventBridge, pour clarifier cette expansion par rapport à CloudWatch Events.

Architecture de la solution

Vérifions l’architecture que nous allons mettre en œuvre, nous utiliserons les services AWS EventBridge (Bus d’événement par défaut) afin de réaliser une architecture événementielle :

1. Pour capturer les événements des changements de configuration des ressources, nous devons activer l’enregistreur AWS Config, de cette façon nous pouvons être informés (par un événement) lorsque quelque chose a changé, et si cet événement nous intéresse, faire quelque chose.
2. AWS EventBridge va commencer à recevoir des événements d’AWS Config concernant les modifications de configuration des ressources.
3. Chez AWS EventBridge, nous devons créer une règle dans le bus d’événements par défaut, indiquant essentiellement le type d’événements que nous voulons intercepter et gérer par cette règle. Dans notre cas, les événements de Service de configuration AWS du genre Modification de l’élément de configuration. C’est la Règle :
   
4. Lorsque l’événement correspond à la règle, cela signifie que nous avons trouvé quelque chose qui nous intéresse. Ensuite, une cible de la règle sera déclenchée, dans ce cas, une fonction AWS Lambda.
5. C’est le « cœur » de notre architecture, où il pose la règle de décision concernant notre objectif principal, c’est-à-dire répondre à la question : Ce changement de configuration a-t-il été effectué par Terraform ou autre chose ? et si la réponse est un « oui », envoyez une notification à un sujet SNS.
6. Récupérez la configuration de l’application pour le comportement de notre fonction Lambda à partir d’AWS AppConfig, par exemple : activer/désactiver la journalisation des messages de débogage sur AWS CloudWatch.
7. À cette étape, nous recherchons dans AWS CloudTrail l’événement qui est corrélé à la configuration AWS Modification de l’élément de configuration. De cette façon, nous pouvons trouver plus d’informations sur l’événement d’occurrence (non seulement quelle ressource a été modifiée, mais qui et comment l’a fait).
8. Enfin, si le Modification de l’élément de configuration lancé par AWS Config, fini par être confirmé par notre fonction Lambda comme non effectuée par Terraform, nous envoyons une notification (nous snitch) à un sujet SNS (ou/et tout ce que nous voulons).

Afin d’élaborer une règle qui décide si la configuration des ressources AWS modifiée a été effectuée par Terraform (étape 5), nous pouvons utiliser toutes les informations disponibles fournies par l’événement AWS Config, ainsi que l’événement AWS CloudTrail corrélé. Dans cette implémentation, nous allons utiliser les informations contenues dans le champ userAgent.

Vous pouvez vérifier tous les détails, déployer et exécuter cette solution en utilisant le code du référentiel fourni à la fin de cet article. Déployons et voyons cette solution fonctionner.

Déployez et exécutez !

Tout d’abord, avant de plonger dans le code de la solution principale, préparons le « terrain » Terraform en créant un S3 Bucket et une table DynamoDB pour sauvegarder à distance l’état et le contrôle des verrouillages.

Pour simplifier les choses, le code va utiliser votre environnement de connexion AWS actuel, alors assurez-vous que vous disposez de la configuration appropriée des informations d’identification AWS et que vous pointez vers le compte souhaité. Vérifiez qu’en utilisant AWSCLI en appelant la fonction obtenir l’identité de l’appelant, et/ou répertorier les compartiments S3, pour voir si la liste vous est familière.

Changer de répertoire utils/terraform-backend et en utilisant l’outil d’automatisation Make (script déjà disponible) lancer la cible créer:

Cette cible vérifiera certaines dépendances et déclenchera toutes les commandes Terraform nécessaires dans l’ordre (vérifiez les détails sur utils/terraform-backend/Makefile déposer). Une fois que le backend Terraform est prêt, nous pouvons continuer et commencer à déployer notre solution.

Revenez au répertoire racine du projet, lancez la commande d’initialisation Terraform, puis créez/sélectionnez un espace de travail Terraform appelé développeur. Avant de commencer le déploiement, vous devez vérifier certains paramètres dans le fichier de configuration de l’espace de travail de développement Terraform. Là, il doit être informé de certains paramètres pour le contexte d’exécution, comme le numéro de compte AWS, la région AWS, etc. Vérifiez le fichier sur workspace-config/dev.yml, et aussi jeter un oeil à la default.yml, pour certains paramètres universels.

Avec le développeur Espace de travail Terraform sélectionné, en utilisant Fabriquer commande, nous pouvons exécuter la cible appelée appliquer.Cette cible lancera les commandes plan de terraforme et appliquer, consécutivement. Nous devrions nous retrouver avec 28 ressources ajoutées représentant l’architecture que nous avons vue ici dans le diagramme de solution d’architecture.

Comme nous l’avons mentionné précédemment, à propos des paramètres de configuration de l’espace de travail, dans le fichier workspace-config/dev.yml vous pouvez trouver la valeur pour sns_notification_email. C’est l’e-mail qui recevra les alertes de SNS Topic concernant les modifications non apportées par Terraform. Quelques instants après que Terraform ait terminé la commande d’application, cet e-mail devrait recevoir la confirmation d’abonnement, vérifier et confirmer l’abonnement.

Essai

Testons d’abord si la notification fonctionne, pour cela à l’aide de la console AWS, créez un compartiment S3 (dans ce test spécifique, nous avons nommé comme créé-avec-aws-console), cela devrait entraîner une alerte et l’e-mail configuré devrait recevoir une notification.

Prouvons maintenant que nous n’avons aucune notification lors de la création de certaines ressources AWS à l’aide de Terraform. Pour cela, à la racine du répertoire principal, renommez le fichier test_drift_tf à test_drift.tf. Ce simple script Terraform HCL ne créera qu’un nouveau groupe de sécurité sur le VPC par défaut. Ensuite, exécutez la commande faire appliquer.

Conclusion

Comme mentionné précédemment, il existe déjà de nombreux outils pour prendre en charge les dérives Terraform. Nous utilisons uniquement ce sujet comme excuse pour proposer une architecture de solution pour montrer comment nous tirons parti d’une architecture événementielle, en utilisant les ressources AWS. Sur la base de cette norme, nous pouvons avoir cette architecture comme modèle de référence pour réaliser des implémentations concrètes d’architecture de solution pour correspondre et répondre à des exigences similaires.

Code source