Préparer le déploiement de la charge de travail d’application web Amazon Web Services (AWS) sur Azure

Cet article fournit un guide complet sur le déploiement d’une infrastructure robuste et prête pour la production afin de faciliter l’hébergement, la protection, la mise à l’échelle et la surveillance d’une application web sur la plateforme Azure.

Déploiement Yelb sur AWS

L’exemple d’application web Yelb sur AWS est déployé à l’aide de Bash, AWS CLI, eksctl, kubectl et Helm. Le complément sample contient des scripts Bash et des manifestes YAML que vous pouvez utiliser pour automatiser le déploiement de l’application Yelb sur AWS Elastic Kubernetes Service (EKS). Cette solution montre comment implémenter un pare-feu d’applications web à l’aide du WAF AWS pour protéger une application web s’exécutant sur Amazon Elastic Kubernetes Service (EKS). Vous pouvez utiliser les scripts Bash pour créer un cluster EKS et déployer l’application Yelb . L’application web Yelb est exposée à l’Internet public à l’aide d’une Amazon Application Load Balancer (ALB) et protégée à l’aide de AWS WAF web access control list (web ACL). Pour obtenir des instructions détaillées, consultez Porting a Web Application from AWS Elastic Kubernetes Service (EKS) to Azure Kubernetes Service (AKS).

Capture d’écran de l’interface de service Yelb.

Déploiement Yelb sur Azure

Dans les sections suivantes, vous allez apprendre à déployer l’exemple d’application web Yelb sur un cluster Azure Kubernetes Service (AKS) et l’exposer via un contrôleur d’entrée comme le contrôleur d’entrée NGINX. Le service de contrôleur d’entrée est accessible via un équilibreur de charge interne (ou privé), qui équilibre le trafic au sein du réseau virtuel hébergeant le cluster AKS. Dans un scénario hybride, le serveur frontal de l’équilibreur de charge est accessible à partir d’un réseau local. Pour en savoir plus sur l’équilibrage de charge interne, consultez Utilisez un équilibreur de charge interne avec Azure Kubernetes Service (AKS).

L’exemple associé prend en charge l’installation d’un contrôleur d’entrée NGINX géré avec le module complémentaire de routage des applications ou d’un contrôleur d’entrée NGINX non géré à l’aide du chart Helm. Le module complémentaire de routage des applications avec le contrôleur d’entrée NGINX fournit les fonctionnalités suivantes :

Pour d’autres configurations,

Pour améliorer la sécurité, l’application Yelb est protégée par une ressource Azure Application Gateway. Cette ressource est déployée dans un sous-réseau dédié du même réseau virtuel que le cluster AKS ou dans un réseau virtuel jumelé. Le Azure Web Application Firewall (WAF) sécurise l’accès à l’application web hébergée sur Azure Kubernetes Service (AKS) et exposée via le Azure Application Gateway contre les données courantes attaques et vulnérabilités.

Prerequisites

Architecture

Cet exemple fournit une collection de modèles Bicep, de scripts Bash, et les manifestes YAML pour la création d’un cluster AKS, le déploiement du contrôleur d’entrée Yelb, l’exposition du service d’interface utilisateur à l’aide du contrôleur d’entrée NGINX et la protection avec le Azure Application Gateway et Azure Web Application Firewall (WAF).

Cet exemple inclut également deux fichiers de paramètres de Bicep distincts et deux ensembles de scripts Bash et de manifestes YAML, chacun destiné au déploiement de deux options de solution différentes. Pour plus d’informations sur Bicep, consultez Qu’est-ce que Bicep ?

Terminaison TLS au niveau de l’Application Gateway et appel de Yelb via HTTP

Dans cette solution, le Azure Web Application Firewall (WAF) garantit la sécurité du système en bloquant les attaques malveillantes. Le Azure Application Gateway reçoit les appels entrants des applications clientes, effectue une terminaison TLS et transfère les requêtes au service yelb-ui hébergé par AKS. Cette communication est obtenue via l’équilibreur de charge interne et le contrôleur d’entrée NGINX à l’aide du protocole de transport HTTP. Le diagramme suivant illustre l’architecture :

Diagramme de la solution basée sur le contrôleur d’entrée WAFv2 et NGINX Application Gateway via HTTP.

Le flux de messages est le suivant :

Diagramme du flux de messages de la solution basé sur le contrôleur d’entrée WAFv2 et NGINX Application Gateway via HTTP.

  1. Le Azure Application Gateway gère l’arrêt TLS et envoie des appels entrants au service yelb-ui hébergé par AKS via HTTP.
  2. L’écouteur Application Gateway utilise un certificat SSL obtenu à partir de Azure Key Vault pour garantir la communication sécurisée.
  3. La stratégie WAF Azure associée à l’écouteur applique des règles OWASP et des règles personnalisées aux requêtes entrantes, empêchant ainsi de nombreux types d’attaques malveillantes.
  4. Les paramètres HTTP principaux d’Application Gateway appellent l’application Yelb via HTTP à l’aide du port 80.
  5. Le pool principal Application Gateway et la sonde d’intégrité appellent le contrôleur d’entrée NGINX via l’équilibreur de charge interne AKS à l’aide du protocole HTTP pour la gestion du trafic.
  6. Le contrôleur d’entrée NGINX utilise l’équilibreur de charge interne AKS pour garantir une communication sécurisée au sein du cluster.
  7. Un objet d’entrée Kubernetes utilise le contrôleur d’entrée NGINX pour exposer l’application via HTTP via l’équilibreur de charge interne.
  8. Le yelb-ui service avec le ClusterIP type limite son appel au sein du cluster ou via le contrôleur d’entrée NGINX.

Implémentation de TLS de bout en bout à l’aide de Azure Application Gateway

Termination TLS

Azure Application Gateway prend en charge l’arrêt TLS au niveau de la passerelle, ce qui signifie que le trafic est déchiffré au niveau de la passerelle avant d’être envoyé aux serveurs principaux. Pour configurer l’arrêt TLS, vous devez ajouter un certificat TLS/SSL à l’écouteur. Le certificat doit être au format Personal Information Exchange (PFX), qui contient à la fois la clé privée et la clé publique. Vous pouvez importer le certificat à partir de Azure Key Vault dans Application Gateway. Pour plus d'informations, consultez Arrêt de TLS avec des certificats Key Vault.

Modèle de sécurité Confiance Zéro

Si vous adoptez un modèle de sécurité Confiance nulle, vous devez empêcher toute communication non chiffrée entre un proxy de service comme Azure Application Gateway et les serveurs principaux. Avec le modèle de sécurité Confiance nulle, l'approbation n'est pas automatiquement accordée à un utilisateur ou un appareil qui tente d'accéder aux ressources au sein d'un réseau. Au lieu de cela, il nécessite une vérification continue de l’identité et de l’autorisation pour chaque demande, quel que soit l’emplacement ou le réseau de l’utilisateur. Dans notre scénario, l’implémentation du modèle de sécurité Confiance nulle implique l’utilisation du Azure Application Gateway en tant que proxy de service, qui agit comme un serveur frontal pour les requêtes entrantes. Ces requêtes se déplacent ensuite vers le contrôleur d’entrée NGINX sur Azure Kubernetes Service (AKS) dans un format chiffré.

TLS de bout en bout avec Application Gateway

Vous pouvez implémenter une approche Confiance nulle en configurant Azure Application Gateway pour le chiffrement TLS de bout en bout avec les serveurs principaux. Le chiffrement TLS de bout en bout vous permet de transmettre en toute sécurité des données sensibles au back-end tout en tirant parti des fonctionnalités d’équilibrage de charge de couche 7 d’Application Gateway, notamment l’affinité de session basée sur les cookies, le routage basé sur l’URL, le routage basé sur les sites et la possibilité de réécrire ou d’injecter des en-têtes X-Forwarded-*.

Quand Application Gateway est configuré avec le mode de communication TLS de bout en bout, il met fin aux sessions TLS à la passerelle et déchiffre le trafic utilisateur. Il applique ensuite les règles configurées pour sélectionner l’instance de pool principal appropriée pour acheminer le trafic vers. Ensuite, Application Gateway lance une nouvelle connexion TLS au serveur principal et déchiffre les données à l’aide du certificat de clé publique du serveur principal avant de transmettre la requête au serveur principal. La réponse du serveur web suit le même processus avant d’atteindre l’utilisateur final. Pour activer le protocole TLS de bout en bout, vous devez définir le paramètre de protocole dans le paramètre HTTP principal sur HTTPS et l’appliquer à un pool principal. Cette approche garantit que votre communication avec les serveurs principaux est sécurisée et conforme à vos exigences.

Pour plus d’informations, consultez chiffrement TLS de bout en bout d’Application Gateway et meilleures pratiques pour sécuriser votre application Gateway.

Dans cette solution, le Azure Web Application Firewall (WAF) garantit la sécurité du système en bloquant les attaques malveillantes. Le Azure Application Gateway gère les appels entrants à partir d’applications clientes, effectue l’arrêt TLS et implémente TLS de bout en bout en appelant le service yelb-ui hébergé par AKS sous-jacent à l’aide du protocole de transport HTTPS via l’équilibreur de charge interne et le contrôleur d’entrée NGINX. Le diagramme suivant illustre l’architecture :

Diagramme de la solution basée sur le contrôleur d’entrée WAFv2 et NGINX Application Gateway via HTTPS.

Le flux de messages est le suivant :

  1. Le Azure Application Gateway gère l’arrêt TLS et communique avec l’application principale via HTTPS.
  2. L’écouteur Application Gateway utilise un certificat SSL obtenu à partir d’Azure Key Vault.
  3. La Azure stratégie WAF associée à l’écouteur exécute des règles OWASP et des règles personnalisées sur les requêtes entrantes pour bloquer les attaques malveillantes.
  4. Les paramètres HTTP principaux d’Application Gateway sont configurés pour appeler le service hébergé yelb-ui par AKS via HTTPS sur le port 443.
  5. Le pool principal Application Gateway et la sonde d’intégrité appellent le contrôleur d’entrée NGINX via l’équilibreur de charge interne AKS à l’aide du protocole HTTPS.
  6. Le contrôleur d’entrée NGINX est déployé pour utiliser l’équilibreur de charge interne AKS.
  7. Le cluster SAKS est configuré avec le module complémentaire fournisseur Azure Key Vault pour le pilote CSI du magasin de secrets afin de récupérer des secrets, des certificats et des clés d’Azure Key Vault via un volume CSI.
  8. Une SecretProviderClass est utilisée pour récupérer le certificat utilisé par Application Gateway à partir de Key Vault.
  9. Un objet d’entrée Kubernetes utilise le contrôleur d’entrée NGINX pour exposer l’application via HTTPS via l’équilibreur de charge interne AKS.
  10. Le yelb-ui service a un ClusterIP type, qui limite son appel au sein du cluster ou via le contrôleur d’entrée NGINX.

Pour garantir la sécurité et la stabilité du système, tenez compte des recommandations suivantes :

  • Mettez régulièrement à jour la stratégie waf Azure avec les dernières règles pour garantir une sécurité optimale.
  • Implémentez des mécanismes de surveillance et de journalisation pour suivre et analyser les requêtes entrantes et les attaques potentielles.
  • Effectuez régulièrement la maintenance et les mises à jour du cluster AKS, du contrôleur d’entrée NGINX et d’Application Gateway pour résoudre les vulnérabilités de sécurité et maintenir une infrastructure sécurisée.
  • Implémentez des mécanismes de surveillance et de journalisation pour suivre et analyser les requêtes entrantes et les attaques potentielles.
  • Effectuez régulièrement la maintenance et les mises à jour du cluster AKS, du contrôleur d’entrée NGINX et d’Application Gateway pour résoudre les vulnérabilités de sécurité et maintenir une infrastructure sécurisée.

Nom d’hôte

Le listener Application Gateway et l’ingress Kubernetes sont configurés pour utiliser le même nom d’hôte. Il est important d’utiliser le même nom d’hôte pour un proxy de service et une application web principale pour les raisons suivantes :

  • Conservation de l’état de session : lorsque vous utilisez un autre nom d’hôte pour le proxy et l’application back-end, l’état de session peut être perdu. Cela signifie que les sessions utilisateur peuvent ne pas être conservées correctement, ce qui entraîne une mauvaise expérience utilisateur et une perte potentielle de données.
  • Échec de l’authentification : si le nom d’hôte diffère entre le proxy et l’application back-end, les mécanismes d’authentification peuvent échouer. Cette approche peut entraîner l’impossibilité pour les utilisateurs de se connecter ou d’accéder à des ressources sécurisées au sein de l’application.
  • Exposition accidentelle des URL : si le nom d’hôte n’est pas conservé, il existe un risque que les URL principales puissent être exposées aux utilisateurs finaux. Cela peut entraîner des vulnérabilités de sécurité potentielles et un accès non autorisé aux informations sensibles.
  • Problèmes de cookie : les cookies jouent un rôle crucial dans la gestion des sessions utilisateur et la transmission d’informations entre le client et le serveur. Lorsque le nom d’hôte diffère, les cookies peuvent ne pas fonctionner comme prévu, ce qui entraîne des problèmes tels que l’authentification ayant échoué, la gestion incorrecte des sessions et la redirection incorrecte.
  • Exigences TLS/SSL de bout en bout : si TLS/SSL de bout en bout est requis pour la communication sécurisée entre le proxy et le service principal, un certificat TLS correspondant pour le nom d’hôte d’origine est nécessaire. L’utilisation du même nom d’hôte simplifie le processus de gestion des certificats et garantit que la communication sécurisée est établie en toute transparence.

Vous pouvez éviter ces problèmes en utilisant le même nom d’hôte pour le proxy de service et l’application web principale. L’application back-end voit le même domaine que le navigateur web, ce qui garantit que l’état de session, l’authentification et la gestion des URL fonctionnent correctement.

Flux de messages

Le diagramme suivant montre les étapes du flux de messages lors du déploiement et de l’exécution.

Diagramme du flux de message de la solution basé sur le contrôleur d’entrée WAFv2 et NGINX Application Gateway via HTTPS.

Workflow du déploiement

Les étapes suivantes décrivent le processus de déploiement. Ce flux de travail correspond aux nombres verts dans le diagramme précédent.

  1. Un ingénieur de sécurité génère un certificat pour le domaine personnalisé que la charge de travail utilise et l’enregistre dans un coffre de clés Azure. Vous pouvez obtenir un certificat valide auprès d’une autorité de certification connue (CA).
  2. Un ingénieur de plateforme spécifie les informations nécessaires dans le fichier de paramètres main.bicepparams Bicep et déploie les modèles Bicep pour créer les ressources Azure. Les informations nécessaires sont les suivantes :
    • Préfixe pour les ressources Azure.
    • Le nom et le groupe de ressources de l’Azure Key Vault existant qui contient le certificat TLS pour le nom d’hôte de la charge de travail et le domaine personnalisé de l’écouteur Application Gateway.
  3. Vous pouvez configurer le script de déploiement pour installer les packages suivants sur votre cluster AKS. Pour plus d’informations, consultez la section paramètres du module Bicep.
  4. L’écouteur Application Gateway récupère le certificat TLS à partir de Azure Key Vault.
  5. L’objet ingress Kubernetes utilise le certificat obtenu auprès du fournisseur Azure Key Vault pour le pilote CSI du magasin de secrets pour exposer le service d’interface utilisateur Yelb via HTTPS.
  6. L’écouteur Application Gateway récupère le certificat TLS à partir de Azure coffre de clés.
  7. L’objet Ingress Kubernetes utilise le certificat obtenu auprès du fournisseur Azure Key Vault provider for Secrets Store CSI Driver pour exposer le service d’interface utilisateur de Yelb via HTTPS.

Flux de travail en temps réel

  1. L’application cliente appelle l’exemple d’application web à l’aide de son nom d’hôte. La zone DNS associée au domaine personnalisé de l’écouteur Application Gateway utilise un enregistrement A pour résoudre la requête DNS avec l’adresse ip publique Azure utilisée par la configuration IP frontale de l’Application Gateway.
  2. La requête est envoyée à l’adresse IP publique Azure utilisée par la configuration IP frontale de l’Application Gateway.
  3. Application Gateway effectue les actions suivantes :
    1. Application Gateway gère l’arrêt TLS et communique avec l’application principale via HTTPS.
    2. L’écouteur Application Gateway utilise un certificat SSL obtenu à partir d’Azure Key Vault.
    3. La stratégie WAF Azure associée à l’écouteur exécute des règles OWASP et des règles personnalisées sur la requête entrante et bloque les attaques malveillantes.
    4. Les paramètres HTTP principaux d’Application Gateway sont configurés pour appeler l’exemple d’application web via HTTPS sur le port 443.
  4. Le pool principal Application Gateway appelle le contrôleur d’entrée NGINX via l’équilibreur de charge interne AKS à l’aide du protocole HTTPS.
  5. La requête est envoyée à l’un des nœuds de l’agent qui héberge un pod du contrôleur d’entrée NGINX.
  6. L’un des réplicas du contrôleur d’entrée NGINX traite la requête et l’envoie à l’un des points de terminaison du service yelb-ui.
  7. Le yelb-ui appelle le service yelb-appserver.
  8. Le yelb-appserver appelle les services yelb-db et yelb-cache.
  9. Le yelb-ui appelle le service yelb-appserver.
  10. Le yelb-appserver appelle les services yelb-db et yelb-cache.

Deployment

Par défaut, les modèles Bicep installent le cluster AKS avec le plugin réseau Azure CNI Overlay et le plan de données Cilium. Vous pouvez utiliser un plug-in réseau de remplacement. En outre, le projet montre comment déployer un cluster AKS avec les extensions et fonctionnalités suivantes :

Dans un environnement de production, nous vous recommandons vivement de déployer un cluster AKS privé avec un contrat SLA de temps d’activité. Pour plus d’informations, consultez le cluster AKS privé avec une adresse DNS publique.

Vous pouvez également déployer un cluster AKS public et sécuriser l’accès au serveur d’API à l’aide de plages d’adresses IP autorisées. Pour obtenir des informations détaillées et des instructions sur le déploiement de l’infrastructure sur Azure à l’aide de modèles Bicep, consultez l’exemple de code companion Azure.

Dans un environnement de production, nous vous recommandons vivement de déployer un cluster AKS privé avec un contrat SLA de temps d’activité. Pour plus d’informations, consultez le cluster AKS privé avec une adresse DNS publique. Vous pouvez également déployer un cluster AKS public et sécuriser l’accès au serveur d’API à l’aide de plages d’adresses IP autorisées. Pour obtenir des informations détaillées et des instructions sur le déploiement de l’infrastructure sur Azure à l’aide de modèles Bicep, reportez-vous à l’exemple de code companion Azure.

Étape suivante

Déployer une charge de travail d’application web AWS sur Azure

Contributeurs

Microsoft conserve cet article. Les contributeurs suivants ont rédigé sa version d’origine:

Auteur principal :

Autres contributeurs :

  • Last updated on