Utiliser Azure Front Door pour sécuriser les charges de travail AKS

Azure Front Door

Azure Key Vault

Azure Private Link

Azure Container Registry

Azure Kubernetes Service (AKS)

Cet article explique comment exposer et protéger une charge de travail qui s’exécute dans Azure Kubernetes Service (AKS) à l’aide d’Azure Front Door, d’Azure Web Application Firewall et d’un service Azure Private Link de manière plus sécurisée. Cette architecture utilise le contrôleur d’entrée NGINX pour exposer une application web. Le contrôleur d’entrée NGINX est configuré pour utiliser une adresse IP privée comme configuration d’IP de front-end du load balancer interne AKS. Le déploiement fournit un chiffrement Transport Layer Security (TLS) de bout en bout.

Architecture

L’image est un diagramme architectural complexe d’une infrastructure réseau basée sur Microsoft Azure. Il est divisé en plusieurs sections qui ont différents composants connectés par des flèches qui indiquent le flux de données ou les connexions. Une section contient une icône qui représente les administrateurs, les ingénieurs de plateforme et les développeurs qui se connectent à une icône qui représente une adresse IP publique. Cette icône se connecte ensuite à l’hôte Azure Bastion. Icône qui représente les utilisateurs de l’application se connecte via HTTPS à Azure Front Door, au service Private Link, à l’icône d’équilibreur de charge interne, à l’icône Entrée-basic, et enfin à httpbin-tls. Cette section contient également des icônes qui représentent la zone Azure DNS et la stratégie de pare-feu d’applications web. Une autre section contient une clé cartographique des icônes pour la surveillance, le trafic Secure Socket Shell, le trafic HTTP/S, le trafic sortant, les connexions privées et la liaison de réseau virtuel. Une section intitulée Zones DNS privées contient des icônes pour les zones DNS privées liées à des noms de domaine spécifiques et possède une ligne en pointillés qui se connecte à partir d’un réseau virtuel étiqueté box 10.0.0.0/8. Les icônes qui représentent la supervision Kubernetes, Azure Managed Grafana et l’espace de travail Monitor pointent vers une grande zone en pointillés étiquetée Réseau virtuel 10.0.0.0/8. Cette zone contient six boîtes en pointillés plus petits. La première zone, intitulée Hôte Azure Bastion 10.243.2.0/24, contient une icône qui représente le service Azure Bastion. La deuxième zone, intitulée ApiServerSubnet10.243.0.0/27, contient une icône qui représente le serveur d’API. La troisième zone, intitulée UserSubnet10.241.0.0/16, contient une icône qui représente le pool d’agents utilisateur. L’icône du pool d’agents utilisateur pointe vers une icône qui représente la passerelle NAT Azure. La quatrième zone, intitulée Service Private Link, contient des icônes qui représentent la machine virtuelle de la zone de rebond et les points de terminaison privés. L’icône points de terminaison privés pointe vers des icônes représentant le compte de stockage, Key Vault et Azure Container Registry. La cinquième zone, intitulée SystemSubnet10.240.0.0/16, contient des icônes qui représentent l’équilibreur de charge interne et le pool d’agents système. L’équilibreur de charge interne pointe vers une icône qui représente la passerelle NAT Azure. Une flèche en pointillé pointe vers une icône qui représente une adresse IP publique qui pointe ensuite vers une icône qui représente Internet. La sixième zone, étiquetée PodSubnet10.242.0.0/16, contient des icônes qui représentent l’entrée, httpbin-tls et kube-system. Une ligne en pointillé connecte cette zone à la zone UserSubnet et à l’icône de passerelle NAT Azure.

Le logo Grafana est une marque déposée de son entreprise respective. L’utilisation de cette marque n’implique aucune approbation de sa part.

Téléchargez un fichier Visio de cette architecture.

Flux de travail

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

Le diagramme comporte cinq sections principales. La section supérieure n’est pas entourée. Les quatre sections inférieures sont placées dans des rectangles en pointillés. Ces quatre rectangles sont placés dans un rectangle en pointillés intitulé AksVnet 10.0.0.0.0/8. La section supérieure a un logo qui représente les administrateurs et les ingénieurs de plateforme. Une flèche pointe de ce logo vers le logo qui représente Azure Key Vault pour indiquer qu’un certificat pour le domaine personnalisé store.test.com est généré et enregistré dans un coffre de clés Azure. À l’étape 2, une flèche pointe du logo de l’administrateur et de l’ingénieur de plateforme vers la section AksVnet 10.0.0.0/8 pour indiquer qu’un ingénieur de plateforme spécifie les informations nécessaires dans le fichier de paramètres main.bicepparams Bicep et déploie les modules Bicep pour créer les ressources Azure. À l’étape 3, une flèche intitulée SecretProviderClass et secrets Store CSI Driver pointe vers le logo qui représente le secret TLS. À l’étape quatre, cette section affiche une flèche du certificat numérique vers Azure Front Door store.test.com pour indiquer qu’elle a atteint sa destination.

Workflow du déploiement

Vous pouvez utiliser l’une des méthodes suivantes pour déployer le contrôleur d’entrée NGINX :

• Contrôleur d’entrée NGINX managé : Déployez un contrôleur d’entrée NGINX managé à l’aide du module complémentaire de routage d’application pour AKS. Le déploiement configure le contrôleur d’entrée NGINX managé pour utiliser une adresse IP privée comme configuration d’adresse IP frontale de l’équilibreur kubernetes-internal de charge interne. Pour plus d’informations, consultez Configurer le contrôleur d’entrée NGINX pour prendre en charge la zone DNS privée Azure avec le module complémentaire de routage des applications.

• Contrôleur d’entrée NGINX non managé : Installez un contrôleur d’entrée NGINX non managé via Helm. Le script de déploiement configure le contrôleur d’entrée NGINX non managé pour utiliser une adresse IP privée comme configuration d’adresse IP frontale de l’équilibreur kubernetes-internal de charge interne. Pour plus d’informations, consultez Créer un contrôleur d’entrée en utilisant une adresse IP interne.

Le workflow suivant correspond au 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.

2. Un ingénieur de plateforme spécifie les informations nécessaires dans le main.bicepparams fichier de paramètres Bicep et déploie les modules Bicep pour créer les ressources Azure. Les informations nécessaires incluent :

   • Un préfixe pour les ressources Azure.

   • Nom et groupe de ressources du coffre de clés existant qui contient le certificat TLS pour le nom d’hôte de la charge de travail et le domaine personnalisé Azure Front Door.

   • Le nom du certificat dans le Key Vault.

   • Le nom et le groupe de ressources de la zone DNS utilisée pour résoudre le domaine personnalisé Azure Front Door.

3. Le script de déploiement crée les objets suivants dans le cluster AKS :

   • Contrôleur d’entrée NGINX via Helm si vous utilisez un contrôleur d’entrée NGINX non managé.

   • Un déploiement et un service Kubernetes pour l’exemple d’application web httpbin .

   • Objet d’entrée Kubernetes pour exposer l’application web via le contrôleur d’entrée NGINX.

   • Ressource personnalisée SecretProviderClass qui récupère le certificat TLS à partir du coffre de clés spécifié à l’aide de l’identité managée définie par l’utilisateur du fournisseur Key Vault pour le pilote CSI du magasin de secrets. Ce composant crée un secret Kubernetes qui contient le certificat TLS référencé par l’objet d’entrée.

4. Une ressource secrète Azure Front Door est utilisée pour gérer et stocker le certificat TLS qui se trouve dans le coffre de clés. Ce certificat est utilisé par le domaine personnalisé associé au point de terminaison Azure Front Door. Le profil Azure Front Door utilise une identité managée affectée par l’utilisateur avec l’attribution de rôle Administrateur Key Vault pour récupérer le certificat TLS à partir de Key Vault.

Remarque

À la fin du déploiement, vous devez approuver la connexion au point de terminaison privé avant que le trafic ne puisse passer à l’origine de manière privée. Pour plus d’informations, veuillez consulter la section Sécuriser votre origine avec Private Link dans Azure Front Door Premium. Pour approuver les connexions aux points de terminaison privés, utilisez le portail Azure, Azure CLI ou Azure PowerShell. Pour plus d’informations, consultez Gérer une connexion au point de terminaison privé.

Flux de travail en temps réel

Les étapes suivantes décrivent le flux de messages pour une requête initiée par une application cliente externe en temps réel. Ce flux de travail correspond aux nombres oranges du diagramme précédent.

1. L’application cliente utilise son domaine personnalisé pour envoyer une requête à l’application web. La zone DNS associée au domaine personnalisé utilise un enregistrement CNAME pour rediriger la requête DNS du domaine personnalisé vers le nom d’hôte original du point de terminaison Azure Front Door.

2. Le routage du trafic Azure Front Door se déroule en plusieurs étapes. Initialement, la requête est envoyée à l’un des points de présence Azure Front Door. Ensuite, Azure Front Door utilise la configuration pour déterminer la destination appropriée pour le trafic. Différents facteurs peuvent influencer le processus de routage, comme la mise en cache Azure Front Door, le pare-feu d’applications web (WAF), les règles de routage, le moteur de règles et la configuration de la mise en cache. Pour plus d’informations, consultez Vue d’ensemble de l’architecture de routage.

3. Azure Front Door transfère la requête entrante au point de terminaison privé Azure connecté au service Private Link qui expose la charge de travail hébergée sur AKS.

4. La requête est envoyée au service Private Link.

5. La requête est transférée au load balancer interne kubernetes-internal AKS.

6. 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 managé ou non managé.

7. L’une des répliques du contrôleur d’entrée NGINX gère la requête.

8. Le contrôleur d’entrée NGINX transfère la requête à l’un des pods de la charge de travail.

Composants

• Un cluster AKS public ou privé est composé des pools de nœuds suivants :

  • Un pool de nœuds système dans un sous-réseau dédié. Le pool de nœuds par défaut héberge uniquement des pods et des services système critiques. Les nœuds système ont une teinte de nœud. Les pods d’application ne peuvent donc pas être planifiés sur ce pool de nœuds.

  • Un pool de nœuds utilisateur qui héberge les charges de travail et les artefacts des utilisateurs dans un sous-réseau dédié.

• Le déploiement nécessite des attributions de rôles de contrôle d’accès en fonction du rôle (RBAC), notamment :

  • Une attribution de rôle Grafana Admin sur Azure Managed Grafana pour l’utilisateur Microsoft Entra dont le objectID est défini dans le paramètre userId. Le rôle d’administrateur Grafana accorde un contrôle total sur l’instance. Ce contrôle inclut la gestion des attributions de rôles et l’affichage, la modification et la configuration des sources de données. Pour plus d’informations, consultez Comment partager l’accès à Azure Managed Grafana.

  • Une attribution de rôle Administrateur Key Vault sur la ressource Key Vault existante qui contient le certificat TLS pour l’identité managée définie par l’utilisateur que le fournisseur Key Vault pour Secrets Store CSI Driver utilise. Cette attribution donne accès au pilote CSI afin qu’il puisse lire le certificat depuis le Key Vault source.

• Azure Front Door Premium est un équilibre de charge global de couche 7 et un réseau de diffusion de contenu cloud moderne. Il fournit un accès de sécurité rapide, fiable et amélioré entre le contenu web statique et dynamique de vos applications dans le monde entier. Vous pouvez utiliser Azure Front Door pour fournir votre contenu à l’aide du réseau de périphérie global Microsoft. Le réseau possède des centaines de points de présence mondiaux et locaux répartis dans le monde entier. Vous pouvez donc utiliser des points de présence proches de vos clients d’entreprise et consommateurs.

  Dans cette solution, Azure Front Door est utilisé pour exposer une application web d’exemple hébergée sur AKS via un service Private Link et le contrôleur d’entrée NGINX. Azure Front Door est configuré pour exposer un domaine personnalisé pour le point de terminaison Azure Front Door. Le domaine personnalisé est configuré pour utiliser le secret Azure Front Door qui contient un certificat TLS lu depuis Key Vault.

• Azure Web Application Firewall protège les applications hébergées sur AKS exposées via Azure Front Door contre les attaques web courantes, telles que les vulnérabilités Open Web Application Security Project (OWASP), les injections SQL et les scripts intersites. Cette technologie cloud native, à la demande, ne nécessite pas de licence. Azure Web Application Firewall protège vos applications web et défend vos services web contre les exploits et vulnérabilités courants.

• Une zone DNS Azure est utilisée pour la résolution de noms du domaine personnalisé Azure Front Door. Vous pouvez utiliser Azure DNS pour héberger vos domaines DNS et gérer vos enregistrements DNS.

  • L’enregistrement CNAME est utilisé pour créer un alias ou un pointeur d’un nom de domaine à un autre. Vous pouvez configurer un enregistrement CNAME pour rediriger les requêtes DNS du domaine personnalisé vers le nom d’hôte original du point de terminaison Azure Front Door.

  • L’enregistrement Text (TXT) contient le jeton de validation pour le domaine personnalisé. Vous pouvez utiliser un enregistrement TXT dans une zone DNS pour stocker des informations textuelles arbitraires associées à un domaine.

• Un service Private Link est configuré pour référencer le load balancer interne kubernetes-internal du cluster AKS. Lorsque vous activez Private Link pour votre origine dans Azure Front Door Premium, Azure Front Door crée un point de terminaison privé depuis un réseau privé régional géré par Azure Front Door. Vous recevez une demande de point de terminaison privé Azure Front Door à l’origine pour votre approbation. Pour plus d’informations, veuillez consulter la section Sécuriser votre origine avec Private Link dans Azure Front Door Premium.

• Azure Virtual Network est utilisé pour créer un réseau virtuel unique avec six sous-réseaux :

  • SystemSubnet est utilisé pour les nœuds agents du pool de nœuds système.

  • UserSubnet est utilisé pour les nœuds agents du pool de nœuds utilisateur.

  • PodSubnet est utilisé pour allouer dynamiquement des adresses IP privées aux pods lorsque le cluster AKS est configuré pour utiliser l’interface réseau de contenu Azure avec l’allocation d’adresses IP dynamiques.

  • ApiServerSubnet utilise l’intégration du réseau virtuel du serveur API pour projeter le point de terminaison du serveur API directement dans ce sous-réseau délégué où le cluster AKS est déployé.

  • AzureBastionSubnet est utilisé pour l’hôte Azure Bastion.

  • VmSubnet est utilisé pour la machine virtuelle jump box qui se connecte au cluster AKS privé et aux points de terminaison privés.

• Une identité managée assignée par l’utilisateur est utilisée par le cluster AKS pour créer plus de ressources comme les load balancers et les disques managés dans Azure.

• Les machines virtuelles Azure sont utilisées pour créer une machine virtuelle de jump box facultative dans le sous-réseau de machine virtuelle.

• Un hôte Azure Bastion est déployé dans le réseau virtuel du cluster AKS pour fournir une connectivité Secure Socket Shell aux nœuds et machines virtuelles de l’agent AKS.

• Un compte de stockage Azure est utilisé pour stocker les journaux de diagnostics de démarrage des VMs du fournisseur de services et du consommateur de services. Les diagnostics de démarrage sont une fonctionnalité de débogage que vous pouvez utiliser pour afficher la sortie de la console et les captures d’écran afin de diagnostiquer l’état de la VM.

• Azure Container Registry est utilisé pour créer, stocker et gérer des images et artefacts de conteneurs.

• Key Vault est utilisé pour stocker les secrets, les certificats et le clés. Les pods peuvent utiliser le fournisseur Key Vault pour Secrets Store CSI Driver pour monter des secrets, des certificats et des clés en tant que fichiers.

  Pour plus d’informations, consultez Utiliser le fournisseur Key Vault pour Secrets Store CSI Driver dans un cluster AKS et Fournir une identité pour accéder au fournisseur Key Vault pour Secrets Store CSI Driver.

  Dans ce projet, une ressource Key Vault existante contient le certificat TLS utilisé par l’objet Kubernetes ingress et le domaine personnalisé du point de terminaison Azure Front Door.

• Un point de terminaison privé Azure et une zone DNS privée Azure sont créés pour chacune des ressources suivantes :

  • Container Registry
  • Key Vault
  • Un compte de stockage

• Les groupes de sécurité réseau Azure sont utilisés pour filtrer le trafic entrant et sortant pour les sous-réseaux qui hébergent des machines virtuelles et des hôtes Azure Bastion.

• Un espace de travail Azure Monitor est un environnement unique pour les données collectées par Monitor. Chaque espace de travail a ses propres référentiel de données, configuration et autorisations. Les espaces de travail des journaux Azure Monitor contiennent des journaux et des données de métriques provenant de plusieurs ressources Azure, tandis que les espaces de travail Monitor contiennent des métriques liées uniquement à Prometheus.

  Vous pouvez utiliser le service géré pour Prometheus pour collecter et analyser les métriques à grande échelle en utilisant une solution de surveillance compatible avec Prometheus basée sur Prometheus. Vous pouvez utiliser le Prometheus query language (PromQL) pour analyser et alerter sur les performances de l’infrastructure et des charges de travail surveillées sans avoir à gérer l’infrastructure sous-jacente.

• Une instance Azure Managed Grafana est utilisée pour visualiser les métriques Prometheus générées par le cluster AKS déployé par le module Bicep. Vous pouvez connecter votre espace de travail Monitor à Azure Managed Grafana et utiliser un ensemble de tableaux de bord Grafana intégrés et personnalisés pour visualiser les métriques Prometheus. Grafana Enterprise prend en charge Azure Managed Grafana, qui fournit des visualisations de données extensibles. Vous pouvez déployer rapidement et facilement des tableaux de bord Grafana avec une haute disponibilité intégrée. Vous pouvez également utiliser les mesures de sécurité Azure pour contrôler l’accès aux tableaux de bord.

• Un espace de travail Journaux Azure Monitor est utilisé pour collecter les journaux de diagnostic et les métriques à partir de ressources Azure, notamment :

  • Clusters AKS
  • Key Vault
  • Groupes de sécurité réseau Azure
  • Container Registry
  • Comptes de stockage

• Un script de déploiement Bicep est utilisé pour exécuter un script Bash qui crée les objets suivants dans le cluster AKS :

  • Un déploiement et un service Kubernetes pour l’exemple d’application web httpbin .

  • Objet d’entrée Kubernetes pour exposer l’application web via le contrôleur d’entrée NGINX.

  • Ressource personnalisée SecretProviderClass qui récupère le certificat TLS à partir du coffre de clés spécifié à l’aide de l’identité managée définie par l’utilisateur du fournisseur Key Vault pour le pilote CSI du magasin de secrets. Ce composant crée un secret Kubernetes qui contient le certificat TLS référencé par l’objet d’entrée.

  • (Facultatif) Contrôleur d’entrée NGINX via Helm si vous avez choisi d’utiliser un contrôleur d’entrée NGINX non managé.

  • (Facultatif) Gestionnaire de certificats

  • (Facultatif) Prometheus et Grafana

Autres solutions

Pour créer automatiquement un service Private Link géré pour le load balancer du cluster AKS, vous pouvez utiliser la fonctionnalité service Private Link. Pour fournir une connectivité privée, vous devez créer des connexions de points de terminaison privés à votre service. Vous pouvez utiliser des annotations pour exposer un service Kubernetes via un service Private Link. L’architecture de cet article crée manuellement un service Private Link pour référencer le cluster Azure Load Balancer.

Détails du scénario

Ce scénario utilise Azure Front Door Premium, le chiffrement TLS de bout en bout, Azure Web Application Firewall et un service Private Link pour exposer et protéger de manière sécurisée une charge de travail exécutée dans AKS.

Cette architecture utilise la fonctionnalité de déchargement TLS et SSL (Secure Sockets Layer) Azure Front Door pour mettre fin à la connexion TLS et déchiffrer le trafic entrant à l’adresse Front Door. Le trafic est ré-encrypté avant d’être transféré à l’origine, qui est une application web hébergée dans un cluster AKS. HTTPS est configuré comme le protocole de transfert sur Azure Front Door lorsque celui-ci se connecte à la charge de travail hébergée sur AKS qui est configurée comme une origine. Cette pratique impose un chiffrement TLS de bout en bout pour l’ensemble du processus de requête, du client à l’origine. Pour plus d’informations, veuillez consulter la section Sécuriser votre origine avec Private Link dans Azure Front Door Premium.

Le contrôleur d’entrée NGINX expose l’application web hébergée sur AKS. Le contrôleur d’entrée NGINX est configuré pour utiliser une adresse IP privée comme configuration d’IP de front-end du load balancer interne kubernetes-internal. Le contrôleur d’entrée NGINX utilise HTTPS comme protocole de transport pour exposer l’application web. Pour plus d’informations, consultez Créer un contrôleur d’entrée en utilisant une adresse IP interne.

Le cluster AKS est configuré pour utiliser les fonctionnalités suivantes :

• Intégration du réseau virtuel du serveur API fournit une communication réseau entre le serveur API et les nœuds du cluster. Cette fonctionnalité ne nécessite pas de lien privé ou de tunnel. Le serveur API est disponible derrière un VIP de load balancer interne dans le sous-réseau délégué. Les nœuds du cluster sont configurés pour utiliser le sous-réseau délégué. Vous pouvez utiliser l’intégration du réseau virtuel du serveur d’API pour vous assurer que le trafic réseau entre votre serveur d’API et vos pools de nœuds reste sur le réseau privé uniquement. Les clusters AKS qui ont l’intégration du réseau virtuel du serveur API offrent de nombreux avantages. Par exemple, vous pouvez activer ou désactiver l’accès au réseau public ou le mode cluster privé sans redéployer le cluster. Pour plus d’informations, consultez Créer un cluster AKS avec l’intégration du réseau virtuel du serveur API.

• Azure NAT Gateway gère les connexions sortantes initiées par les charges de travail hébergées sur AKS. Pour plus d’informations, consultez Créer une passerelle NAT gérée ou assignée par l’utilisateur pour votre cluster AKS.

Cas d’usage potentiels

Ce scénario fournit une solution pour répondre aux exigences de sécurité et de conformité pour une application web ou une API REST exécutée dans AKS.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Certaines des considérations suivantes ne sont pas spécifiquement liées à l’utilisation de Azure Front Door, Azure Web Application Firewall et d’un service Private Link pour améliorer la sécurité d’un cluster AKS. Mais les considérations de sécurité, de performance, de disponibilité, de fiabilité, de stockage et de surveillance sont des exigences essentielles de cette solution.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

Ces recommandations sont essentielles pour les solutions AKS monolocataires et ne sont pas spécifiques aux solutions AKS mutualisées, où les cibles de fiabilité sont plus élevées en raison du nombre d’utilisateurs et de charges de travail qui s’appuient sur le système. Considérez les recommandations suivantes pour optimiser la disponibilité de votre cluster AKS et de vos charges de travail.

Résilience entre les régions

• Déployez les pools de nœuds de votre cluster AKS dans toutes les zones de disponibilité d’une région.

• Activez la redondance de zone dans Container Registry à des fins de résilience et de haute disponibilité intrarégionale.

• Utilisez des contraintes de répartition topologique pour contrôler comment vous répartissez les pods dans votre cluster AKS parmi les domaines de défaillance tels que les régions, les zones de disponibilité et les nœuds.

• Utilisez les niveaux Standard ou Premium pour vos clusters AKS de production. Ces niveaux incluent la fonctionnalité accord de niveau de service (SLA) de disponibilité, qui garantit une disponibilité de 99,95 % du point de terminaison du serveur API Kubernetes pour les clusters qui utilisent des zones de disponibilité et 99,9 % de disponibilité pour les clusters qui n’utilisent pas de zones de disponibilité. Pour plus d’informations, consultez l’article Niveaux tarifaires Gratuit, Standard et Premium pour la gestion des clusters AKS.

• Activez la redondance de zone si vous utilisez Container Registry pour stocker des images de conteneurs et des artefacts Oracle Cloud Infrastructure (OCI). Container Registry prend en charge la redondance de zone optionnelle et la réplication géographique. La redondance de zone assure la résilience et la haute disponibilité d’un registre ou d’une ressource de réplication (réplica) dans une région spécifique. La géoréplication réplique les données du registre dans une ou plusieurs régions Azure pour offrir une disponibilité et réduire la latence des opérations régionales.

Récupération d'urgence et continuité d’activité

• Envisagez de déployer votre solution dans deux régions. Utilisez la région jumelée Azure comme deuxième région.

• Script, documentez et testez périodiquement les processus de basculement régional dans un environnement d’assurance qualité (QA).

• Testez les procédures de retour arrière pour valider leur bon fonctionnement.

• Stockez vos images conteneur dans Container Registry. Répliquez géographiquement le registre dans chaque région où vous déployez votre solution AKS.

• Si possible, ne stockez pas l’état du service dans un conteneur. Au lieu de cela, stockez l’état du service dans une solution de stockage de plateforme en tant que service (PaaS) Azure qui prend en charge la réplication multirégionale. Cette approche améliore la résilience et simplifie la reprise après sinistre car vous pouvez préserver les données critiques de chaque service dans les régions.

• Si vous utilisez le stockage, préparez et testez les processus pour migrer votre stockage de la région primaire vers la région de sauvegarde.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

• Utilisez un WAF pour protéger les applications web et les services hébergés sur AKS qui exposent un point de terminaison HTTPS public. Vous devez assurer une protection contre les menaces courantes telles que l’injection SQL, le scripting inter-site et d’autres codes malveillants exploitant une faille de sécurité sur le web. Suivez les règles OWASP et vos propres règles personnalisées. Azure Web Application Firewall offre une protection centralisée améliorée de vos applications web contre les vulnérabilités et les codes malveillants exploitant une faille de sécurité courants. Vous pouvez déployer un pare-feu d’applications Azure à l’aide d’Azure Application Gateway, d’Azure Front Door ou d’Azure Content Delivery Network.

• Utilisez Azure DDoS Protection et les bonnes pratiques de conception d’applications pour vous défendre contre les attaques par déni de service distribué (DDoS) sur les charges de travail. Azure protège son infrastructure et ses services contre les attaques DDoS. Cette protection permet de garantir la disponibilité des régions, des zones de disponibilité et des services. Vous devez également protéger les points de terminaison publics de vos charges de travail contre les attaques DDoS de couche 4 et de couche 7. Vous pouvez activer Azure DDOS Protection sur les réseaux virtuels de périmètre.

• Utilisez la règle de limitation de débit du pare-feu d’application web (WAF) pour Azure Front Door pour gérer et contrôler le nombre de requêtes que vous autorisez d’une adresse IP source spécifique à votre application dans une durée de limitation de débit définie. Utilisez cette fonctionnalité pour vous aider à appliquer des stratégies de limitation de débit et à vous assurer que vous protégez votre application contre un trafic excessif ou un abus potentiel. Configurez la règle de limitation de débit pour maintenir des performances et une sécurité optimales de l’application et fournir un contrôle granulaire des limites de requêtes.

• Configurez la politique WAF associée à Azure Front Door en mode prévention. En mode prévention, la politique WAF analyse les requêtes entrantes et les compare aux règles configurées. Si une requête correspond à une ou plusieurs règles définies pour refuser le trafic lorsqu’elles sont satisfaites, la politique WAF bloque le trafic malveillant avant qu’il n’atteigne vos applications web. Cette mesure aide à garantir que vous protégez vos applications contre les vulnérabilités potentielles et les tentatives d’accès non autorisées. Pour plus d’informations, consultez l’article Azure Web Application Firewall sur Azure Front Door.

• Créez un point de terminaison privé Azure pour tout service PaaS utilisé par les charges de travail AKS, comme Key Vault, Azure Service Bus et Azure SQL Database. Le trafic entre les applications et ces services n’est pas exposé à l’Internet public. Le trafic entre le réseau virtuel du cluster AKS et une instance de service PaaS via un point de terminaison privé traverse le réseau principal Microsoft mais ne passe pas par le pare-feu Azure. Un point de terminaison privé offre une sécurité et une protection contre les fuites de données. Pour plus d’informations, consultez Qu’est-ce que Private Link ?.

• Utilisez une politique WAF pour aider à protéger les charges de travail hébergées sur AKS exposées au public contre les attaques lorsque vous utilisez Application Gateway devant le cluster AKS.

• Utilisez des stratégies réseau Kubernetes pour contrôler les composants qui peuvent communiquer entre eux. Ce contrôle sépare et aide à sécuriser les communications intraservice. Par défaut, tous les pods d’un cluster Kubernetes peuvent envoyer et recevoir du trafic sans aucune limite. Pour améliorer la sécurité, vous pouvez utiliser les politiques réseau Azure ou les politiques réseau Calico pour définir des règles qui contrôlent le flux de trafic entre divers microservices. Utilisez des stratégies réseau Azure pour vous aider à appliquer le contrôle d’accès au niveau du réseau. Utilisez les politiques réseau Calico pour mettre en œuvre une segmentation réseau fine et des politiques de sécurité dans votre cluster AKS. Pour plus d’informations, consultez Sécuriser le trafic entre les pods en utilisant des politiques réseau dans AKS.

• N'exposez pas de connectivité à distance sur vos nœuds AKS. Créez un hôte Azure Bastion ou une zone de rebond dans un réseau virtuel de gestion. Utilisez l’hôte Azure Bastion pour acheminer le trafic vers votre cluster AKS.

• Envisagez d’utiliser un cluster AKS privé dans votre environnement de production. Ou, au minimum, utilisez des plages d’adresses IP autorisées dans AKS pour sécuriser l’accès au serveur API. Lorsque vous utilisez des plages d’adresses IP autorisées sur un cluster public, autorisez toutes les adresses IP de sortie dans la collection de règles de réseau de Pare-feu Azure. Les opérations au sein du cluster consomment le serveur d’API Kubernetes.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

• Utilisez la mise à l’échelle automatique du cluster, la mise à l’échelle automatique basée sur les événements Kubernetes et l’autoscaler de pod horizontal pour mettre à l’échelle le nombre de pods et de nœuds en fonction des conditions de trafic.

• Définissez des requêtes et limites de ressources appropriées pour les pods afin d’optimiser l’allocation des ressources et d’améliorer la densité des applications. Pour plus d’informations, consultez Bonnes pratiques pour la gestion des ressources dans AKS.

• Utilisez des objets ResourceQuota pour définir des quotas d’utilisation de la mémoire et du processeur dans les espaces de noms. Cette configuration aide à prévenir les problèmes de voisins bruyants et à améliorer la densité des applications. Pour plus d’informations, consultez Définir une plage limite dans un espaces de noms.

• Implémentez l’autoscaler vertical de pods pour analyser et définir les ressources CPU et mémoire nécessaires aux pods. Cette approche optimise l’allocation des ressources.

• Choisissez la taille de VM appropriée pour les pools de nœuds en fonction des besoins de la charge de travail.

• Créez plusieurs pools de nœuds avec différentes tailles de VM pour des charges de travail spécifiques. Utilisez des étiquettes de nœuds, des sélecteurs de nœuds et des règles d’affinité pour optimiser l’allocation des ressources.

• Arrêtez les pools de nœuds ou réduisez la taille des clusters AKS lorsque vous ne les utilisez pas.

• Tirez parti des outils de gestion des coûts, tels qu’Azure Advisor, les réservations Azure et lesplans d’économies Azure pour surveiller et optimiser les coûts.

• Envisagez d’utiliser des pools de nœuds spot pour bénéficier de la capacité inutilisée d’Azure et réduire les coûts.

• Utilisez des outils comme Kubecost pour surveiller et gérer les coûts AKS.

• Utilisez des balises Azure pour associer les ressources AKS à des charges de travail ou des locataires spécifiques afin d’améliorer le suivi et la gestion des coûts.

Pour plus d’informations, consultez Optimisation des coûts et Optimiser les coûts dans AKS.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

DevOps

• Utilisez un graphique Helm dans un pipeline d’intégration continue et de livraison continue pour déployer vos charges de travail sur AKS.

• Utilisez les tests A/B et les déploiements canari dans la gestion du cycle de vie de votre application pour tester correctement une application avant de la rendre disponible aux utilisateurs.

• Utilisez Container Registry ou un registre non-Microsoft, tel que Harbor ou Docker Hub, pour stocker des images conteneur privées déployées sur le cluster.

• Testez l’ingress et l’egress de vos charges de travail dans un environnement de préproduction distinct qui reflète la topologie réseau et les règles de pare-feu de votre environnement de production.

Surveillance

• Utilisez container insights pour surveiller l’état de santé du cluster AKS et des charges de travail.

• Utilisez le service géré pour Prometheus pour collecter et analyser les métriques à grande échelle en utilisant une solution de surveillance compatible avec Prometheus basée sur le projet Prometheus de la Cloud Native Computing Foundation.

• Connectez votre service géré pour Prometheus à une instance Azure Managed Grafana pour l’utiliser comme source de données dans un tableau de bord Grafana. Vous avez alors accès à plusieurs tableaux de bord préintégrés utilisant les métriques Prometheus, et vous pouvez créer des tableaux de bord personnalisés.

• Configurez tous les services PaaS, tels que Container Registry et Key Vault, pour collecter des journaux de diagnostics et des métriques dans un espace de travail Azure Monitor Logs.

Déployer ce scénario

Le code source de ce scénario est disponible sur GitHub. Cette solution open-source est sous licence MIT License.

Prérequis

• Un abonnement Azure actif. Si vous n’en avez pas, créez un compte Azure gratuit avant de commencer.

• Visual Studio Code et l’extension Bicep sur l’une des plateformes prises en charge.

• Azure CLI, version 2.58.0 ou ultérieure. Pour plus d’informations, consultez Installer Azure CLI.

• Une ressource Key Vault existante avec un certificat TLS valide pour l’application web d’exemple.

• Une zone DNS Azure existante pour la résolution de noms du domaine personnalisé Azure Front Door via un enregistrement CNAME.

Déploiement vers Azure

1. Clonez le référentiel GitHub de la plateforme.

   git clone https://github.com/Azure-Samples/aks-front-door-end-to-end-tls.git
   

2. Suivez les instructions dans le fichier README. Vous aurez besoin des informations de votre abonnement Azure pour cette étape.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• Paolo Salvatori | Ingénieur des services principaux

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Bonnes pratiques relatives aux clusters AKS
• Pare-feu d’applications web Azure sur Azure Front Door
• Meilleures pratiques relatives aux fonctionnalités avancées du planificateur
• Meilleures pratiques relatives à l’authentification et l’autorisation
• Bonnes pratiques relatives aux fonctionnalités basiques du planificateur dans AKS
• Meilleures pratiques relatives à la continuité d’activité et reprise d’activité dans AKS
• Bonnes pratiques relatives à la sécurité et aux mises à niveau du cluster dans AKS
• Bonnes pratiques relatives à la gestion et à la sécurité des images de conteneur
• Meilleures pratiques relatives à la connectivité réseau et à la sécurité dans AKS
• Meilleures pratiques relatives au stockage et aux sauvegardes dans AKS
• Bonnes pratiques pour Azure Front Door
• Créer un cluster AKS privé
• Origins et groupes d’origin dans Azure Front Door
• Vue d’ensemble de l’architecture de routage
• Sécuriser votre origine avec Private Link dans Azure Front Door Premium
• Accélération du trafic
• Comprendre la facturation d’Azure Front Door
• Qu’est-ce qu’un ensemble de règles dans Azure Front Door ?
• Qu’est-ce qu’Azure Front Door ?

Ressources associées

• Architecture de microservices avancée sur AKS
• Guide des opérations AKS (2e journée)
• Parcours d’une solution AKS
• Architecture de référence pour un cluster AKS
• Meilleures pratiques relatives à l’isolement multi-locataire et de cluster
• Architecture de microservices sur AKS

Cet article explique comment exposer et protéger une charge de travail qui s’exécute dans Azure Kubernetes Service (AKS) à l’aide d’Azure Front Door, d’Azure Web Application Firewall et d’un service Azure Private Link de manière plus sécurisée. Cette architecture utilise le contrôleur d’entrée NGINX pour exposer une application web. Le contrôleur d’entrée NGINX est configuré pour utiliser une adresse IP privée comme configuration d’IP de front-end du load balancer interne AKS. Le déploiement fournit un chiffrement Transport Layer Security (TLS) de bout en bout.

Architecture

L’image est un diagramme architectural complexe d’une infrastructure réseau basée sur Microsoft Azure. Il est divisé en plusieurs sections qui ont différents composants connectés par des flèches qui indiquent le flux de données ou les connexions. Une section contient une icône qui représente les administrateurs, les ingénieurs de plateforme et les développeurs qui se connectent à une icône qui représente une adresse IP publique. Cette icône se connecte ensuite à l’hôte Azure Bastion. Icône qui représente les utilisateurs de l’application se connecte via HTTPS à Azure Front Door, au service Private Link, à l’icône d’équilibreur de charge interne, à l’icône Entrée-basic, et enfin à httpbin-tls. Cette section contient également des icônes qui représentent la zone Azure DNS et la stratégie de pare-feu d’applications web. Une autre section contient une clé cartographique des icônes pour la surveillance, le trafic Secure Socket Shell, le trafic HTTP/S, le trafic sortant, les connexions privées et la liaison de réseau virtuel. Une section intitulée Zones DNS privées contient des icônes pour les zones DNS privées liées à des noms de domaine spécifiques et possède une ligne en pointillés qui se connecte à partir d’un réseau virtuel étiqueté box 10.0.0.0/8. Les icônes qui représentent la supervision Kubernetes, Azure Managed Grafana et l’espace de travail Monitor pointent vers une grande zone en pointillés étiquetée Réseau virtuel 10.0.0.0/8. Cette zone contient six boîtes en pointillés plus petits. La première zone, intitulée Hôte Azure Bastion 10.243.2.0/24, contient une icône qui représente le service Azure Bastion. La deuxième zone, intitulée ApiServerSubnet10.243.0.0/27, contient une icône qui représente le serveur d’API. La troisième zone, intitulée UserSubnet10.241.0.0/16, contient une icône qui représente le pool d’agents utilisateur. L’icône du pool d’agents utilisateur pointe vers une icône qui représente la passerelle NAT Azure. La quatrième zone, intitulée Service Private Link, contient des icônes qui représentent la machine virtuelle de la zone de rebond et les points de terminaison privés. L’icône points de terminaison privés pointe vers des icônes représentant le compte de stockage, Key Vault et Azure Container Registry. La cinquième zone, intitulée SystemSubnet10.240.0.0/16, contient des icônes qui représentent l’équilibreur de charge interne et le pool d’agents système. L’équilibreur de charge interne pointe vers une icône qui représente la passerelle NAT Azure. Une flèche en pointillé pointe vers une icône qui représente une adresse IP publique qui pointe ensuite vers une icône qui représente Internet. La sixième zone, étiquetée PodSubnet10.242.0.0/16, contient des icônes qui représentent l’entrée, httpbin-tls et kube-system. Une ligne en pointillé connecte cette zone à la zone UserSubnet et à l’icône de passerelle NAT Azure.

Le logo Grafana est une marque déposée de son entreprise respective. L’utilisation de cette marque n’implique aucune approbation de sa part.

Téléchargez un fichier Visio de cette architecture.

Flux de travail

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

Le diagramme comporte cinq sections principales. La section supérieure n’est pas entourée. Les quatre sections inférieures sont placées dans des rectangles en pointillés. Ces quatre rectangles sont placés dans un rectangle en pointillés intitulé AksVnet 10.0.0.0.0/8. La section supérieure a un logo qui représente les administrateurs et les ingénieurs de plateforme. Une flèche pointe de ce logo vers le logo qui représente Azure Key Vault pour indiquer qu’un certificat pour le domaine personnalisé store.test.com est généré et enregistré dans un coffre de clés Azure. À l’étape 2, une flèche pointe du logo de l’administrateur et de l’ingénieur de plateforme vers la section AksVnet 10.0.0.0/8 pour indiquer qu’un ingénieur de plateforme spécifie les informations nécessaires dans le fichier de paramètres main.bicepparams Bicep et déploie les modules Bicep pour créer les ressources Azure. À l’étape 3, une flèche intitulée SecretProviderClass et secrets Store CSI Driver pointe vers le logo qui représente le secret TLS. À l’étape quatre, cette section affiche une flèche du certificat numérique vers Azure Front Door store.test.com pour indiquer qu’elle a atteint sa destination.

Workflow du déploiement

Vous pouvez utiliser l’une des méthodes suivantes pour déployer le contrôleur d’entrée NGINX :

• Contrôleur d’entrée NGINX managé : Déployez un contrôleur d’entrée NGINX managé à l’aide du module complémentaire de routage d’application pour AKS. Le déploiement configure le contrôleur d’entrée NGINX managé pour utiliser une adresse IP privée comme configuration d’adresse IP frontale de l’équilibreur kubernetes-internal de charge interne. Pour plus d’informations, consultez Configurer le contrôleur d’entrée NGINX pour prendre en charge la zone DNS privée Azure avec le module complémentaire de routage des applications.

• Contrôleur d’entrée NGINX non managé : Installez un contrôleur d’entrée NGINX non managé via Helm. Le script de déploiement configure le contrôleur d’entrée NGINX non managé pour utiliser une adresse IP privée comme configuration d’adresse IP frontale de l’équilibreur kubernetes-internal de charge interne. Pour plus d’informations, consultez Créer un contrôleur d’entrée en utilisant une adresse IP interne.

Le workflow suivant correspond au 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.

2. Un ingénieur de plateforme spécifie les informations nécessaires dans le main.bicepparams fichier de paramètres Bicep et déploie les modules Bicep pour créer les ressources Azure. Les informations nécessaires incluent :

   • Un préfixe pour les ressources Azure.

   • Nom et groupe de ressources du coffre de clés existant qui contient le certificat TLS pour le nom d’hôte de la charge de travail et le domaine personnalisé Azure Front Door.

   • Le nom du certificat dans le Key Vault.

   • Le nom et le groupe de ressources de la zone DNS utilisée pour résoudre le domaine personnalisé Azure Front Door.

3. Le script de déploiement crée les objets suivants dans le cluster AKS :

   • Contrôleur d’entrée NGINX via Helm si vous utilisez un contrôleur d’entrée NGINX non managé.

   • Un déploiement et un service Kubernetes pour l’exemple d’application web httpbin .

   • Objet d’entrée Kubernetes pour exposer l’application web via le contrôleur d’entrée NGINX.

   • Ressource personnalisée SecretProviderClass qui récupère le certificat TLS à partir du coffre de clés spécifié à l’aide de l’identité managée définie par l’utilisateur du fournisseur Key Vault pour le pilote CSI du magasin de secrets. Ce composant crée un secret Kubernetes qui contient le certificat TLS référencé par l’objet d’entrée.

4. Une ressource secrète Azure Front Door est utilisée pour gérer et stocker le certificat TLS qui se trouve dans le coffre de clés. Ce certificat est utilisé par le domaine personnalisé associé au point de terminaison Azure Front Door. Le profil Azure Front Door utilise une identité managée affectée par l’utilisateur avec l’attribution de rôle Administrateur Key Vault pour récupérer le certificat TLS à partir de Key Vault.

Remarque

À la fin du déploiement, vous devez approuver la connexion au point de terminaison privé avant que le trafic ne puisse passer à l’origine de manière privée. Pour plus d’informations, veuillez consulter la section Sécuriser votre origine avec Private Link dans Azure Front Door Premium. Pour approuver les connexions aux points de terminaison privés, utilisez le portail Azure, Azure CLI ou Azure PowerShell. Pour plus d’informations, consultez Gérer une connexion au point de terminaison privé.

Flux de travail en temps réel

Les étapes suivantes décrivent le flux de messages pour une requête initiée par une application cliente externe en temps réel. Ce flux de travail correspond aux nombres oranges du diagramme précédent.

1. L’application cliente utilise son domaine personnalisé pour envoyer une requête à l’application web. La zone DNS associée au domaine personnalisé utilise un enregistrement CNAME pour rediriger la requête DNS du domaine personnalisé vers le nom d’hôte original du point de terminaison Azure Front Door.

2. Le routage du trafic Azure Front Door se déroule en plusieurs étapes. Initialement, la requête est envoyée à l’un des points de présence Azure Front Door. Ensuite, Azure Front Door utilise la configuration pour déterminer la destination appropriée pour le trafic. Différents facteurs peuvent influencer le processus de routage, comme la mise en cache Azure Front Door, le pare-feu d’applications web (WAF), les règles de routage, le moteur de règles et la configuration de la mise en cache. Pour plus d’informations, consultez Vue d’ensemble de l’architecture de routage.

3. Azure Front Door transfère la requête entrante au point de terminaison privé Azure connecté au service Private Link qui expose la charge de travail hébergée sur AKS.

4. La requête est envoyée au service Private Link.

5. La requête est transférée au load balancer interne kubernetes-internal AKS.

6. 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 managé ou non managé.

7. L’une des répliques du contrôleur d’entrée NGINX gère la requête.

8. Le contrôleur d’entrée NGINX transfère la requête à l’un des pods de la charge de travail.

Composants

• Un cluster AKS public ou privé est composé des pools de nœuds suivants :

  • Un pool de nœuds système dans un sous-réseau dédié. Le pool de nœuds par défaut héberge uniquement des pods et des services système critiques. Les nœuds système ont une teinte de nœud. Les pods d’application ne peuvent donc pas être planifiés sur ce pool de nœuds.

  • Un pool de nœuds utilisateur qui héberge les charges de travail et les artefacts des utilisateurs dans un sous-réseau dédié.

• Le déploiement nécessite des attributions de rôles de contrôle d’accès en fonction du rôle (RBAC), notamment :

  • Une attribution de rôle Grafana Admin sur Azure Managed Grafana pour l’utilisateur Microsoft Entra dont le objectID est défini dans le paramètre userId. Le rôle d’administrateur Grafana accorde un contrôle total sur l’instance. Ce contrôle inclut la gestion des attributions de rôles et l’affichage, la modification et la configuration des sources de données. Pour plus d’informations, consultez Comment partager l’accès à Azure Managed Grafana.

  • Une attribution de rôle Administrateur Key Vault sur la ressource Key Vault existante qui contient le certificat TLS pour l’identité managée définie par l’utilisateur que le fournisseur Key Vault pour Secrets Store CSI Driver utilise. Cette attribution donne accès au pilote CSI afin qu’il puisse lire le certificat depuis le Key Vault source.

• Azure Front Door Premium est un équilibre de charge global de couche 7 et un réseau de diffusion de contenu cloud moderne. Il fournit un accès de sécurité rapide, fiable et amélioré entre le contenu web statique et dynamique de vos applications dans le monde entier. Vous pouvez utiliser Azure Front Door pour fournir votre contenu à l’aide du réseau de périphérie global Microsoft. Le réseau possède des centaines de points de présence mondiaux et locaux répartis dans le monde entier. Vous pouvez donc utiliser des points de présence proches de vos clients d’entreprise et consommateurs.

  Dans cette solution, Azure Front Door est utilisé pour exposer une application web d’exemple hébergée sur AKS via un service Private Link et le contrôleur d’entrée NGINX. Azure Front Door est configuré pour exposer un domaine personnalisé pour le point de terminaison Azure Front Door. Le domaine personnalisé est configuré pour utiliser le secret Azure Front Door qui contient un certificat TLS lu depuis Key Vault.

• Azure Web Application Firewall protège les applications hébergées sur AKS exposées via Azure Front Door contre les attaques web courantes, telles que les vulnérabilités Open Web Application Security Project (OWASP), les injections SQL et les scripts intersites. Cette technologie cloud native, à la demande, ne nécessite pas de licence. Azure Web Application Firewall protège vos applications web et défend vos services web contre les exploits et vulnérabilités courants.

• Une zone DNS Azure est utilisée pour la résolution de noms du domaine personnalisé Azure Front Door. Vous pouvez utiliser Azure DNS pour héberger vos domaines DNS et gérer vos enregistrements DNS.

  • L’enregistrement CNAME est utilisé pour créer un alias ou un pointeur d’un nom de domaine à un autre. Vous pouvez configurer un enregistrement CNAME pour rediriger les requêtes DNS du domaine personnalisé vers le nom d’hôte original du point de terminaison Azure Front Door.

  • L’enregistrement Text (TXT) contient le jeton de validation pour le domaine personnalisé. Vous pouvez utiliser un enregistrement TXT dans une zone DNS pour stocker des informations textuelles arbitraires associées à un domaine.

• Un service Private Link est configuré pour référencer le load balancer interne kubernetes-internal du cluster AKS. Lorsque vous activez Private Link pour votre origine dans Azure Front Door Premium, Azure Front Door crée un point de terminaison privé depuis un réseau privé régional géré par Azure Front Door. Vous recevez une demande de point de terminaison privé Azure Front Door à l’origine pour votre approbation. Pour plus d’informations, veuillez consulter la section Sécuriser votre origine avec Private Link dans Azure Front Door Premium.

• Azure Virtual Network est utilisé pour créer un réseau virtuel unique avec six sous-réseaux :

  • SystemSubnet est utilisé pour les nœuds agents du pool de nœuds système.

  • UserSubnet est utilisé pour les nœuds agents du pool de nœuds utilisateur.

  • PodSubnet est utilisé pour allouer dynamiquement des adresses IP privées aux pods lorsque le cluster AKS est configuré pour utiliser l’interface réseau de contenu Azure avec l’allocation d’adresses IP dynamiques.

  • ApiServerSubnet utilise l’intégration du réseau virtuel du serveur API pour projeter le point de terminaison du serveur API directement dans ce sous-réseau délégué où le cluster AKS est déployé.

  • AzureBastionSubnet est utilisé pour l’hôte Azure Bastion.

  • VmSubnet est utilisé pour la machine virtuelle jump box qui se connecte au cluster AKS privé et aux points de terminaison privés.

• Une identité managée assignée par l’utilisateur est utilisée par le cluster AKS pour créer plus de ressources comme les load balancers et les disques managés dans Azure.

• Les machines virtuelles Azure sont utilisées pour créer une machine virtuelle de jump box facultative dans le sous-réseau de machine virtuelle.

• Un hôte Azure Bastion est déployé dans le réseau virtuel du cluster AKS pour fournir une connectivité Secure Socket Shell aux nœuds et machines virtuelles de l’agent AKS.

• Un compte de stockage Azure est utilisé pour stocker les journaux de diagnostics de démarrage des VMs du fournisseur de services et du consommateur de services. Les diagnostics de démarrage sont une fonctionnalité de débogage que vous pouvez utiliser pour afficher la sortie de la console et les captures d’écran afin de diagnostiquer l’état de la VM.

• Azure Container Registry est utilisé pour créer, stocker et gérer des images et artefacts de conteneurs.

• Key Vault est utilisé pour stocker les secrets, les certificats et le clés. Les pods peuvent utiliser le fournisseur Key Vault pour Secrets Store CSI Driver pour monter des secrets, des certificats et des clés en tant que fichiers.

  Pour plus d’informations, consultez Utiliser le fournisseur Key Vault pour Secrets Store CSI Driver dans un cluster AKS et Fournir une identité pour accéder au fournisseur Key Vault pour Secrets Store CSI Driver.

  Dans ce projet, une ressource Key Vault existante contient le certificat TLS utilisé par l’objet Kubernetes ingress et le domaine personnalisé du point de terminaison Azure Front Door.

• Un point de terminaison privé Azure et une zone DNS privée Azure sont créés pour chacune des ressources suivantes :

  • Container Registry
  • Key Vault
  • Un compte de stockage

• Les groupes de sécurité réseau Azure sont utilisés pour filtrer le trafic entrant et sortant pour les sous-réseaux qui hébergent des machines virtuelles et des hôtes Azure Bastion.

• Un espace de travail Azure Monitor est un environnement unique pour les données collectées par Monitor. Chaque espace de travail a ses propres référentiel de données, configuration et autorisations. Les espaces de travail des journaux Azure Monitor contiennent des journaux et des données de métriques provenant de plusieurs ressources Azure, tandis que les espaces de travail Monitor contiennent des métriques liées uniquement à Prometheus.

  Vous pouvez utiliser le service géré pour Prometheus pour collecter et analyser les métriques à grande échelle en utilisant une solution de surveillance compatible avec Prometheus basée sur Prometheus. Vous pouvez utiliser le Prometheus query language (PromQL) pour analyser et alerter sur les performances de l’infrastructure et des charges de travail surveillées sans avoir à gérer l’infrastructure sous-jacente.

• Une instance Azure Managed Grafana est utilisée pour visualiser les métriques Prometheus générées par le cluster AKS déployé par le module Bicep. Vous pouvez connecter votre espace de travail Monitor à Azure Managed Grafana et utiliser un ensemble de tableaux de bord Grafana intégrés et personnalisés pour visualiser les métriques Prometheus. Grafana Enterprise prend en charge Azure Managed Grafana, qui fournit des visualisations de données extensibles. Vous pouvez déployer rapidement et facilement des tableaux de bord Grafana avec une haute disponibilité intégrée. Vous pouvez également utiliser les mesures de sécurité Azure pour contrôler l’accès aux tableaux de bord.

• Un espace de travail Journaux Azure Monitor est utilisé pour collecter les journaux de diagnostic et les métriques à partir de ressources Azure, notamment :

  • Clusters AKS
  • Key Vault
  • Groupes de sécurité réseau Azure
  • Container Registry
  • Comptes de stockage

• Un script de déploiement Bicep est utilisé pour exécuter un script Bash qui crée les objets suivants dans le cluster AKS :

  • Un déploiement et un service Kubernetes pour l’exemple d’application web httpbin .

  • Objet d’entrée Kubernetes pour exposer l’application web via le contrôleur d’entrée NGINX.

  • Ressource personnalisée SecretProviderClass qui récupère le certificat TLS à partir du coffre de clés spécifié à l’aide de l’identité managée définie par l’utilisateur du fournisseur Key Vault pour le pilote CSI du magasin de secrets. Ce composant crée un secret Kubernetes qui contient le certificat TLS référencé par l’objet d’entrée.

  • (Facultatif) Contrôleur d’entrée NGINX via Helm si vous avez choisi d’utiliser un contrôleur d’entrée NGINX non managé.

  • (Facultatif) Gestionnaire de certificats

  • (Facultatif) Prometheus et Grafana

Autres solutions

Pour créer automatiquement un service Private Link géré pour le load balancer du cluster AKS, vous pouvez utiliser la fonctionnalité service Private Link. Pour fournir une connectivité privée, vous devez créer des connexions de points de terminaison privés à votre service. Vous pouvez utiliser des annotations pour exposer un service Kubernetes via un service Private Link. L’architecture de cet article crée manuellement un service Private Link pour référencer le cluster Azure Load Balancer.

Détails du scénario

Ce scénario utilise Azure Front Door Premium, le chiffrement TLS de bout en bout, Azure Web Application Firewall et un service Private Link pour exposer et protéger de manière sécurisée une charge de travail exécutée dans AKS.

Cette architecture utilise la fonctionnalité de déchargement TLS et SSL (Secure Sockets Layer) Azure Front Door pour mettre fin à la connexion TLS et déchiffrer le trafic entrant à l’adresse Front Door. Le trafic est ré-encrypté avant d’être transféré à l’origine, qui est une application web hébergée dans un cluster AKS. HTTPS est configuré comme le protocole de transfert sur Azure Front Door lorsque celui-ci se connecte à la charge de travail hébergée sur AKS qui est configurée comme une origine. Cette pratique impose un chiffrement TLS de bout en bout pour l’ensemble du processus de requête, du client à l’origine. Pour plus d’informations, veuillez consulter la section Sécuriser votre origine avec Private Link dans Azure Front Door Premium.

Le contrôleur d’entrée NGINX expose l’application web hébergée sur AKS. Le contrôleur d’entrée NGINX est configuré pour utiliser une adresse IP privée comme configuration d’IP de front-end du load balancer interne kubernetes-internal. Le contrôleur d’entrée NGINX utilise HTTPS comme protocole de transport pour exposer l’application web. Pour plus d’informations, consultez Créer un contrôleur d’entrée en utilisant une adresse IP interne.

Le cluster AKS est configuré pour utiliser les fonctionnalités suivantes :

• Intégration du réseau virtuel du serveur API fournit une communication réseau entre le serveur API et les nœuds du cluster. Cette fonctionnalité ne nécessite pas de lien privé ou de tunnel. Le serveur API est disponible derrière un VIP de load balancer interne dans le sous-réseau délégué. Les nœuds du cluster sont configurés pour utiliser le sous-réseau délégué. Vous pouvez utiliser l’intégration du réseau virtuel du serveur d’API pour vous assurer que le trafic réseau entre votre serveur d’API et vos pools de nœuds reste sur le réseau privé uniquement. Les clusters AKS qui ont l’intégration du réseau virtuel du serveur API offrent de nombreux avantages. Par exemple, vous pouvez activer ou désactiver l’accès au réseau public ou le mode cluster privé sans redéployer le cluster. Pour plus d’informations, consultez Créer un cluster AKS avec l’intégration du réseau virtuel du serveur API.

• Azure NAT Gateway gère les connexions sortantes initiées par les charges de travail hébergées sur AKS. Pour plus d’informations, consultez Créer une passerelle NAT gérée ou assignée par l’utilisateur pour votre cluster AKS.

Cas d’usage potentiels

Ce scénario fournit une solution pour répondre aux exigences de sécurité et de conformité pour une application web ou une API REST exécutée dans AKS.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Certaines des considérations suivantes ne sont pas spécifiquement liées à l’utilisation de Azure Front Door, Azure Web Application Firewall et d’un service Private Link pour améliorer la sécurité d’un cluster AKS. Mais les considérations de sécurité, de performance, de disponibilité, de fiabilité, de stockage et de surveillance sont des exigences essentielles de cette solution.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

Ces recommandations sont essentielles pour les solutions AKS monolocataires et ne sont pas spécifiques aux solutions AKS mutualisées, où les cibles de fiabilité sont plus élevées en raison du nombre d’utilisateurs et de charges de travail qui s’appuient sur le système. Considérez les recommandations suivantes pour optimiser la disponibilité de votre cluster AKS et de vos charges de travail.

Résilience entre les régions

• Déployez les pools de nœuds de votre cluster AKS dans toutes les zones de disponibilité d’une région.

• Activez la redondance de zone dans Container Registry à des fins de résilience et de haute disponibilité intrarégionale.

• Utilisez des contraintes de répartition topologique pour contrôler comment vous répartissez les pods dans votre cluster AKS parmi les domaines de défaillance tels que les régions, les zones de disponibilité et les nœuds.

• Utilisez les niveaux Standard ou Premium pour vos clusters AKS de production. Ces niveaux incluent la fonctionnalité accord de niveau de service (SLA) de disponibilité, qui garantit une disponibilité de 99,95 % du point de terminaison du serveur API Kubernetes pour les clusters qui utilisent des zones de disponibilité et 99,9 % de disponibilité pour les clusters qui n’utilisent pas de zones de disponibilité. Pour plus d’informations, consultez l’article Niveaux tarifaires Gratuit, Standard et Premium pour la gestion des clusters AKS.

• Activez la redondance de zone si vous utilisez Container Registry pour stocker des images de conteneurs et des artefacts Oracle Cloud Infrastructure (OCI). Container Registry prend en charge la redondance de zone optionnelle et la réplication géographique. La redondance de zone assure la résilience et la haute disponibilité d’un registre ou d’une ressource de réplication (réplica) dans une région spécifique. La géoréplication réplique les données du registre dans une ou plusieurs régions Azure pour offrir une disponibilité et réduire la latence des opérations régionales.

Récupération d'urgence et continuité d’activité

• Envisagez de déployer votre solution dans deux régions. Utilisez la région jumelée Azure comme deuxième région.

• Script, documentez et testez périodiquement les processus de basculement régional dans un environnement d’assurance qualité (QA).

• Testez les procédures de retour arrière pour valider leur bon fonctionnement.

• Stockez vos images conteneur dans Container Registry. Répliquez géographiquement le registre dans chaque région où vous déployez votre solution AKS.

• Si possible, ne stockez pas l’état du service dans un conteneur. Au lieu de cela, stockez l’état du service dans une solution de stockage de plateforme en tant que service (PaaS) Azure qui prend en charge la réplication multirégionale. Cette approche améliore la résilience et simplifie la reprise après sinistre car vous pouvez préserver les données critiques de chaque service dans les régions.

• Si vous utilisez le stockage, préparez et testez les processus pour migrer votre stockage de la région primaire vers la région de sauvegarde.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

• Utilisez un WAF pour protéger les applications web et les services hébergés sur AKS qui exposent un point de terminaison HTTPS public. Vous devez assurer une protection contre les menaces courantes telles que l’injection SQL, le scripting inter-site et d’autres codes malveillants exploitant une faille de sécurité sur le web. Suivez les règles OWASP et vos propres règles personnalisées. Azure Web Application Firewall offre une protection centralisée améliorée de vos applications web contre les vulnérabilités et les codes malveillants exploitant une faille de sécurité courants. Vous pouvez déployer un pare-feu d’applications Azure à l’aide d’Azure Application Gateway, d’Azure Front Door ou d’Azure Content Delivery Network.

• Utilisez Azure DDoS Protection et les bonnes pratiques de conception d’applications pour vous défendre contre les attaques par déni de service distribué (DDoS) sur les charges de travail. Azure protège son infrastructure et ses services contre les attaques DDoS. Cette protection permet de garantir la disponibilité des régions, des zones de disponibilité et des services. Vous devez également protéger les points de terminaison publics de vos charges de travail contre les attaques DDoS de couche 4 et de couche 7. Vous pouvez activer Azure DDOS Protection sur les réseaux virtuels de périmètre.

• Utilisez la règle de limitation de débit du pare-feu d’application web (WAF) pour Azure Front Door pour gérer et contrôler le nombre de requêtes que vous autorisez d’une adresse IP source spécifique à votre application dans une durée de limitation de débit définie. Utilisez cette fonctionnalité pour vous aider à appliquer des stratégies de limitation de débit et à vous assurer que vous protégez votre application contre un trafic excessif ou un abus potentiel. Configurez la règle de limitation de débit pour maintenir des performances et une sécurité optimales de l’application et fournir un contrôle granulaire des limites de requêtes.

• Configurez la politique WAF associée à Azure Front Door en mode prévention. En mode prévention, la politique WAF analyse les requêtes entrantes et les compare aux règles configurées. Si une requête correspond à une ou plusieurs règles définies pour refuser le trafic lorsqu’elles sont satisfaites, la politique WAF bloque le trafic malveillant avant qu’il n’atteigne vos applications web. Cette mesure aide à garantir que vous protégez vos applications contre les vulnérabilités potentielles et les tentatives d’accès non autorisées. Pour plus d’informations, consultez l’article Azure Web Application Firewall sur Azure Front Door.

• Créez un point de terminaison privé Azure pour tout service PaaS utilisé par les charges de travail AKS, comme Key Vault, Azure Service Bus et Azure SQL Database. Le trafic entre les applications et ces services n’est pas exposé à l’Internet public. Le trafic entre le réseau virtuel du cluster AKS et une instance de service PaaS via un point de terminaison privé traverse le réseau principal Microsoft mais ne passe pas par le pare-feu Azure. Un point de terminaison privé offre une sécurité et une protection contre les fuites de données. Pour plus d’informations, consultez Qu’est-ce que Private Link ?.

• Utilisez une politique WAF pour aider à protéger les charges de travail hébergées sur AKS exposées au public contre les attaques lorsque vous utilisez Application Gateway devant le cluster AKS.

• Utilisez des stratégies réseau Kubernetes pour contrôler les composants qui peuvent communiquer entre eux. Ce contrôle sépare et aide à sécuriser les communications intraservice. Par défaut, tous les pods d’un cluster Kubernetes peuvent envoyer et recevoir du trafic sans aucune limite. Pour améliorer la sécurité, vous pouvez utiliser les politiques réseau Azure ou les politiques réseau Calico pour définir des règles qui contrôlent le flux de trafic entre divers microservices. Utilisez des stratégies réseau Azure pour vous aider à appliquer le contrôle d’accès au niveau du réseau. Utilisez les politiques réseau Calico pour mettre en œuvre une segmentation réseau fine et des politiques de sécurité dans votre cluster AKS. Pour plus d’informations, consultez Sécuriser le trafic entre les pods en utilisant des politiques réseau dans AKS.

• N'exposez pas de connectivité à distance sur vos nœuds AKS. Créez un hôte Azure Bastion ou une zone de rebond dans un réseau virtuel de gestion. Utilisez l’hôte Azure Bastion pour acheminer le trafic vers votre cluster AKS.

• Envisagez d’utiliser un cluster AKS privé dans votre environnement de production. Ou, au minimum, utilisez des plages d’adresses IP autorisées dans AKS pour sécuriser l’accès au serveur API. Lorsque vous utilisez des plages d’adresses IP autorisées sur un cluster public, autorisez toutes les adresses IP de sortie dans la collection de règles de réseau de Pare-feu Azure. Les opérations au sein du cluster consomment le serveur d’API Kubernetes.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

• Utilisez la mise à l’échelle automatique du cluster, la mise à l’échelle automatique basée sur les événements Kubernetes et l’autoscaler de pod horizontal pour mettre à l’échelle le nombre de pods et de nœuds en fonction des conditions de trafic.

• Définissez des requêtes et limites de ressources appropriées pour les pods afin d’optimiser l’allocation des ressources et d’améliorer la densité des applications. Pour plus d’informations, consultez Bonnes pratiques pour la gestion des ressources dans AKS.

• Utilisez des objets ResourceQuota pour définir des quotas d’utilisation de la mémoire et du processeur dans les espaces de noms. Cette configuration aide à prévenir les problèmes de voisins bruyants et à améliorer la densité des applications. Pour plus d’informations, consultez Définir une plage limite dans un espaces de noms.

• Implémentez l’autoscaler vertical de pods pour analyser et définir les ressources CPU et mémoire nécessaires aux pods. Cette approche optimise l’allocation des ressources.

• Choisissez la taille de VM appropriée pour les pools de nœuds en fonction des besoins de la charge de travail.

• Créez plusieurs pools de nœuds avec différentes tailles de VM pour des charges de travail spécifiques. Utilisez des étiquettes de nœuds, des sélecteurs de nœuds et des règles d’affinité pour optimiser l’allocation des ressources.

• Arrêtez les pools de nœuds ou réduisez la taille des clusters AKS lorsque vous ne les utilisez pas.

• Tirez parti des outils de gestion des coûts, tels qu’Azure Advisor, les réservations Azure et lesplans d’économies Azure pour surveiller et optimiser les coûts.

• Envisagez d’utiliser des pools de nœuds spot pour bénéficier de la capacité inutilisée d’Azure et réduire les coûts.

• Utilisez des outils comme Kubecost pour surveiller et gérer les coûts AKS.

• Utilisez des balises Azure pour associer les ressources AKS à des charges de travail ou des locataires spécifiques afin d’améliorer le suivi et la gestion des coûts.

Pour plus d’informations, consultez Optimisation des coûts et Optimiser les coûts dans AKS.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

DevOps

• Utilisez un graphique Helm dans un pipeline d’intégration continue et de livraison continue pour déployer vos charges de travail sur AKS.

• Utilisez les tests A/B et les déploiements canari dans la gestion du cycle de vie de votre application pour tester correctement une application avant de la rendre disponible aux utilisateurs.

• Utilisez Container Registry ou un registre non-Microsoft, tel que Harbor ou Docker Hub, pour stocker des images conteneur privées déployées sur le cluster.

• Testez l’ingress et l’egress de vos charges de travail dans un environnement de préproduction distinct qui reflète la topologie réseau et les règles de pare-feu de votre environnement de production.

Surveillance

• Utilisez container insights pour surveiller l’état de santé du cluster AKS et des charges de travail.

• Utilisez le service géré pour Prometheus pour collecter et analyser les métriques à grande échelle en utilisant une solution de surveillance compatible avec Prometheus basée sur le projet Prometheus de la Cloud Native Computing Foundation.

• Connectez votre service géré pour Prometheus à une instance Azure Managed Grafana pour l’utiliser comme source de données dans un tableau de bord Grafana. Vous avez alors accès à plusieurs tableaux de bord préintégrés utilisant les métriques Prometheus, et vous pouvez créer des tableaux de bord personnalisés.

• Configurez tous les services PaaS, tels que Container Registry et Key Vault, pour collecter des journaux de diagnostics et des métriques dans un espace de travail Azure Monitor Logs.

Déployer ce scénario

Le code source de ce scénario est disponible sur GitHub. Cette solution open-source est sous licence MIT License.

Prérequis

• Un abonnement Azure actif. Si vous n’en avez pas, créez un compte Azure gratuit avant de commencer.

• Visual Studio Code et l’extension Bicep sur l’une des plateformes prises en charge.

• Azure CLI, version 2.58.0 ou ultérieure. Pour plus d’informations, consultez Installer Azure CLI.

• Une ressource Key Vault existante avec un certificat TLS valide pour l’application web d’exemple.

• Une zone DNS Azure existante pour la résolution de noms du domaine personnalisé Azure Front Door via un enregistrement CNAME.

Déploiement vers Azure

1. Clonez le référentiel GitHub de la plateforme.

   git clone https://github.com/Azure-Samples/aks-front-door-end-to-end-tls.git
   

2. Suivez les instructions dans le fichier README. Vous aurez besoin des informations de votre abonnement Azure pour cette étape.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• Paolo Salvatori | Ingénieur des services principaux

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Bonnes pratiques relatives aux clusters AKS
• Pare-feu d’applications web Azure sur Azure Front Door
• Meilleures pratiques relatives aux fonctionnalités avancées du planificateur
• Meilleures pratiques relatives à l’authentification et l’autorisation
• Bonnes pratiques relatives aux fonctionnalités basiques du planificateur dans AKS
• Meilleures pratiques relatives à la continuité d’activité et reprise d’activité dans AKS
• Bonnes pratiques relatives à la sécurité et aux mises à niveau du cluster dans AKS
• Bonnes pratiques relatives à la gestion et à la sécurité des images de conteneur
• Meilleures pratiques relatives à la connectivité réseau et à la sécurité dans AKS
• Meilleures pratiques relatives au stockage et aux sauvegardes dans AKS
• Bonnes pratiques pour Azure Front Door
• Créer un cluster AKS privé
• Origins et groupes d’origin dans Azure Front Door
• Vue d’ensemble de l’architecture de routage
• Sécuriser votre origine avec Private Link dans Azure Front Door Premium
• Accélération du trafic
• Comprendre la facturation d’Azure Front Door
• Qu’est-ce qu’un ensemble de règles dans Azure Front Door ?
• Qu’est-ce qu’Azure Front Door ?

Ressources associées

• Architecture de microservices avancée sur AKS
• Guide des opérations AKS (2e journée)
• Parcours d’une solution AKS
• Architecture de référence pour un cluster AKS
• Meilleures pratiques relatives à l’isolement multi-locataire et de cluster
• Architecture de microservices sur AKS