Infrastructure immuable : réseaux
17 avril 2015
0 minutes de lectureNote de la rédaction
Cet article est paru à l’origine sur fugue.co. Fugue a rejoint Snyk en 2022 et constitue un élément clé de Snyk IaC.
Si vous travaillez sur des infrastructures réseau, vous savez qu’elles ont tendance à se dégrader, autrement dit à s’éloigner de leur configuration initiale. L’un de nos objectifs, en faisant de Fugue le système d’exploitation (OS) du cloud et la source unique de vérité et de confiance pour votre infrastructure, est d’empêcher cette dérive en préservant son état de référence. Après tout, « un système de confiance ne fait que ce que son auteur a prévu ».
Jusqu’à présent, nous nous sommes intéressés aux « imperfections » qui apparaissent sur les instances de calcul, mais le problème concerne également d’autres composants de l’infrastructure, comme les réseaux. La dérive de configuration des réseaux survient souvent lorsque leur déploiement et leur maintenance nécessitent des interventions manuelles. J’ai vu des configurations réseau occupant des centaines de lignes dans des feuilles de calcul et déployées à la main, ligne par ligne. Lorsque l’application ne fonctionne pas correctement, la solution de prédilection consiste généralement à intervenir manuellement pour ouvrir des ports et des plages d’adresses IP.
Cela signifie souvent que la nouvelle configuration n’est pas à jour dans la feuille de calcul d’origine. Les correctifs temporaires deviennent alors permanents, car on les oublie. Lorsqu’un nouveau service est ajouté à l’application, d’autres interventions manuelles sont nécessaires. Ces interventions exposent non seulement les applications à des risques de sécurité, par l’ouverture accidentelle de règles de groupes de sécurité, mais peuvent aussi entraîner d’importantes interruptions de service si des règles ou des routes sont supprimées par erreur.
Les outils et services DevOps, comme AWS CloudFormation, ont en partie résolu les difficultés liées à la configuration des réseaux en remplaçant les opérations manuelles par l’automatisation de l’infrastructure. Dans ce contexte, les configurations réseau peuvent être définies dans un langage spécifique à un domaine (DSL) ou un modèle contrôlé, reproductible, vérifiable et testable.
Cependant, bon nombre de ces outils ne vont pas assez loin. Ils se contentent de déployer les configurations réseau, sans appliquer l’état souhaité au-delà du déploiement initial. Cela devient évident lorsqu’une modification manuelle est apportée au réseau après son déploiement à l’aide de ces outils. Dans le pire des cas, les modifications sont laissées telles quelles. Dans le meilleur des cas, seules les règles déployées à l’origine sont appliquées.
Fugue va plus loin en matière d’automatisation et de contrôle des réseaux. Fugue s’efforce de toujours rétablir l’état souhaité du réseau défini lors de son déploiement. Si des règles définies dans une composition sont supprimées, Fugue les rétablit. Si de nouvelles règles non définies dans la composition sont ajoutées à votre réseau, Fugue les supprime.
Pour illustrer cela, examinons un exemple bref mais puissant faisant intervenir les groupes de sécurité AWS :
Dans le code Ludwig ci-dessus, nous avons défini le groupe de sécurité web-server-sg, qui autorise le trafic entrant sur le port 80 en provenance du groupe web-elb-sg. Une fois ce code compilé et exécuté, Fugue Conductor veille à ce que les groupes de sécurité et les règles définis dans votre composition soient déployés dans votre compte AWS.
Mais Conductor ne s’arrête pas là. Comme pour les instances EC2, Conductor vérifie régulièrement (actuellement toutes les 10 secondes) que votre composition en cours d’exécution correspond à sa définition et à sa compilation initiales. Si l’infrastructure réseau ne correspond pas à la composition observée par Conductor, celui-ci apporte les modifications nécessaires à votre infrastructure afin de rester fidèle à la configuration d’origine.
Mettons Fugue à l’épreuve en introduisant quelques imperfections dans notre réseau. Pour cela, je vais jouer le rôle d’un administrateur système bien intentionné, mais inexpérimenté, qui souhaite consulter des journaux de serveur alors que les serveurs Web sont en cours d’exécution (nous supposons qu’il ne sait pas que le système de gestion des journaux vient d’être mis en place).
En me connectant à la console de gestion AWS, j’ajoute une règle de groupe de sécurité qui autorise les connexions SSH depuis 0.0.0.0/0. Comme le montre la vidéo ci-dessous, la règle est supprimée quelques secondes après son ajout, et le groupe de sécurité retrouve sa configuration d’origine.

Examinons maintenant la situation sous un autre angle. Imaginons que nous soyons vendredi après-midi et que notre administrateur système bien intentionné veuille vérifier les règles de sécurité du compte AWS avant de partir pour le week-end. Dans ce cas, nous allons simuler une situation où il supprime par inadvertance la règle du groupe de sécurité qui autorise le trafic entrant sur le port 80 vers leurs serveurs Web. Sans se rendre compte de son erreur, il ferme aussitôt son ordinateur portable et part au pub.
Dans une situation classique, ce scénario pourrait entraîner une interruption importante du site. Or, dans ce cas, le site ne serait indisponible que pendant 10 secondes au maximum. Conductor effectue sa vérification et recrée rapidement la règle du groupe de sécurité, exactement comme elle était définie dans la composition Ludwig.

Cela ne concerne pas uniquement les groupes de sécurité et leurs règles. Conductor préserve également la configuration d’autres éléments réseau, notamment les routes VPC, les listes de contrôle d’accès réseau (ACL), les passerelles Internet et les sous-réseaux.
Mais que faire si je veux modifier un élément de ma composition ?
Il est simple de modifier une composition en cours d’exécution. Imaginons que vous souhaitiez ajouter une règle au groupe de sécurité ELB afin d’autoriser le trafic Internet sur le port 443. Commencez par modifier votre composition Ludwig pour tenir compte de ces changements.
Une fois les modifications terminées, ouvrez l’interface de ligne de commande Fugue et exécutez les commandes suivantes :
La commande load de Fugue compile la composition modifiée et la charge dans S3. La commande update de Fugue demande ensuite à Conductor de récupérer la version mise à jour depuis S3 et d’appliquer les modifications à la composition en cours d’exécution.
Pourquoi est-ce important ?
Vous pouvez passer des heures chaque semaine à maintenir et à modifier manuellement les configurations réseau, sans empêcher l’apparition de nouvelles imperfections. Ce n’est tout simplement pas une bonne façon d’utiliser les ressources de vos équipes. Fugue offre un moyen automatisé et déterministe de déployer, maintenir et mettre à jour les composants de l’infrastructure. Indiquez à Conductor ce que vous souhaitez, et il s’en chargera tout en veillant à ce que le résultat soit préservé.
Avec Fugue, vous pouvez préserver la conformité de vos réseaux tout en réduisant les délais de déploiement et la charge de maintenance continue. Le DSL Ludwig étant déclaratif, reproductible, applicable et vérifiable, vous pouvez exploiter vos applications en toute confiance, sachant que la configuration de votre réseau est constamment maintenue dans l’état souhaité.
Avec une infrastructure réseau immuable, quelques lignes de code suffisent pour répondre aux exigences strictes de sécurité et de conformité, internes comme externes, de vos applications.



