Gestion des modifications

Ce document décrit les meilleures pratiques pour apporter des modifications aux configurations des services AWS Edge, tels que CloudFront, Lambda@Edge et AWS WAF. Ces modifications peuvent inclure la mise à jour du code de la fonction CloudFront, la modification de l'exécution d'une fonction Lambda@Edge, l'ajout d'un nouveau comportement de cache dans CloudFront, la mise à jour des règles WAF ou l'activation de nouvelles fonctionnalités CloudFront telles que HTTP/3. Si vous avez des configurations relativement statiques et simples et que vous préférez une interface utilisateur pour la gestion manuelle, vous pouvez compter sur la console AWS. Toutefois, pour les configurations plus complexes, il est recommandé d’exploiter es pipelines CI/CD pour déployer les modifications de configuration et les mises à jour de code de manière contrôlée.

Les pipelines CI/CD améliorent les cycles de distribution des logiciels en augmentant la vitesse de développement, en fournissant une meilleure qualité de code et en réduisant les erreurs humaines grâce à l'automatisation. Les services de périphérie AWS tels que CloudFront et les fonctions de périphérie peuvent être gérés dans un pipeline CI/CD, en utilisant l’Infrastructure en tant que Code (IaC). Les ressources de périphérie peuvent être déployées via des API (par exemple, l'API de CloudFront), l'AWS CLI ou des outils d'abstraction de niveau supérieur tels que CloudFormation, Terraform et le Cloud Development Kit (CDK) de l’AWS .

Le CDK, basé sur CloudFormation, fournit le plus haut niveau d'abstraction en vous permettant de déployer des ressources AWS à l'aide d'un langage de programmation. Par exemple, les trois lignes de code JavaScript suivantes peuvent déployer un compartiment S3 avec CloudFront comme origine :

Consultez la bibliothèque de constructions CDK pour les constructions réutilisables à inclure dans votre code CDK.

Dans votre pipeline CI/CD, vous aurez besoin d'un référentiel tel qu'AWS CodeCommit pour stocker votre code (code CDK, code des fonctions de périphérie), d'un outil tel qu'AWS CodeDeploy pour déployer votre infrastructure et d'un outil d'orchestration tel qu'AWS CodePipeline pour gérer les étapes du pipeline. Ce billet de blog explique comment utiliser les outils de développement AWS pour implémenter un pipeline CI/CD pour CloudFront, mais vous pouvez également utiliser vos outils CI/CD préférés. Lorsque vous créez votre pipeline CI/CD pour les services AWS Edge, tenez compte des limites suivantes :

• CloudFront, Fonctions CloudFront et les WebACL AWS WAF régionales peuvent être déployés depuis n'importe quelle région AWS
• Les WebACL WAF WAF et Lambda@Edge pour CloudFront ne peuvent être déployées qu'à partir de la région us-east-1 en Virginie du Nord.
• Les politiques de Firewall Manager doivent être déployées dans le compte AWS de l'administrateur de Firewall Manager.

Votre configuration en périphérie peut être testée à différents niveaux. Tout d'abord, vous pouvez répliquer votre infrastructure, telle qu'une distribution CloudFront avec une WebACL AWS WAF dans les comptes de test. Cela peut être fait pendant la phase de développement ou pour exécuter des tests fonctionnels automatisés avant de passer à la production. Notez que vous ne pouvez pas utiliser deux distributions CloudFront avec le même CNAME. Par conséquent, vous devez différencier la configuration CNAME de votre ressource CloudFront en fonction de la phase CI/CD. Par exemple, vous pouvez utiliser le nom de domaine de CloudFront (par exemple, xyz.cloudfront.net) pour la phase de développement, un CNAME dédié pour le staging (par exemple, staging.www.example.com) et le CNAME public pour le déploiement en production (par exemple, www.example.com). Vous pouvez également différencier les contrôles de sécurité par étape, par exemple en limitant l'accès à des adresses IP spécifiques à l'aide d'AWS WAF pour la phase de mise en place.

Une fois que votre nouvelle configuration a passé les étapes de test, vous pouvez mettre en œuvre une approche de libération canary en utilisant la fonctionnalité de déploiement continu de CloudFront pour tester le changement en production sur une petite partie de votre trafic. Grâce à cette fonctionnalité, vous pouvez créer une configuration différente de votre distribution de production et n'y envoyer qu'une partie de votre trafic mondial. Vous avez deux possibilités pour acheminer le trafic vers la nouvelle configuration : en utilisant un en-tête de requête spécifique, (utile pour les tests synthétiques), ou en utilisant une politique pondérée pour acheminer un pourcentage configurable du trafic vers la nouvelle configuration, avec la possibilité d'activer l'adhérence. Dans la version actuelle de cette fonctionnalité, vous pouvez uniquement tester les modifications apportées à un sous-ensemble de paramètres de la configuration CloudFront. Consultez la documentation pour mieux comprendre ce que vous pouvez tester à l'aide de cette fonctionnalité.

Imaginons un scénario dans lequel plusieurs équipes apportent des modifications à la configuration CloudFront, mais une seule équipe gère le pipeline CI/CD pour toutes les équipes. Par exemple, différentes équipes peuvent gérer des microservices distincts, exposant ainsi toutes leurs API sur le domaine principal hébergé par une seule distribution CloudFront. Si vous autorisez chaque équipe à accéder à la configuration complète de la distribution CloudFront, vous augmentez le rayon d'action d'une seule modification toxique. À l'inverse, si vous autorisez uniquement l'équipe CI/CD à apporter des modifications à la distribution CloudFront, vous réduisez la vitesse de développement et vous introduisez un goulot d'étranglement dans le cycle de vie de vos versions. Au lieu de cela, vous pouvez générer dynamiquement une configuration en fonction de configurations partielles détenues par chaque équipe de microservices. Dans une implémentation simple, chaque équipe gère la configuration de sa propre route (mise en cache, fonctions de périphérie, etc.) dans un fichier texte hébergé dans un compartiment S3. Dans votre pipeline CI/CD, vous pouvez introduire une étape supplémentaire pour créer dynamiquement la configuration finale de CloudFront à l'aide des différents fichiers de configuration partiels.

Les services Shield et WAF peuvent être déployés à l'aide des mêmes outils que ceux décrits précédemment, dans un pipeline CI/CD.

Il est toutefois recommandé d'utiliser AWS Firewall Manager pour déployer les règles WAF et les protections Shield afin de bénéficier des avantages suivants :

• Il facilite la mise en œuvre d'une gouvernance de sécurité centrale (par exemple, déploiement de règles centrales en combinaison avec des règles gérées par les équipes d'application)
• Il permet un déploiement plus rapide, ce qui est essentiel pour corriger les vulnérabilités critiques à l'aide d'AWS WAF.
• Il simplifie le déploiement entre les comptes et les pipelines CI/CD hétérogènes (hérités d'acquisitions, par exemple). Cependant, avec cette approche, vous devez gérer la dérive si vous utilisez un pipeline CI/CD avec détection de dérive.

En outre, vous pouvez utiliser un pipeline CI/CD pour apporter des modifications à vos politiques Firewall Manager dans le compte administrateur, qui seront ensuite déployées au sein de votre organisation AWS par Firewall Manager, comme le montre OLX.

Le déploiement des règles WAF en toute sécurité dans votre environnement de production peut être effectué à l'aide de différentes stratégies. Vous pouvez ajouter de nouvelles règles à une WebACL existante en mode comptage, puis la modifier en mode bloc. Cependant, avec cette approche, vous devez faire attention à la valeur WCU maximale de votre WebACL. Une autre approche consiste à déployer les modifications apportées à une WebACL intermédiaire et à tester les modifications dans un environnement intermédiaire.