Utiliser Pare-feu Azure pour aider à protéger un cluster Azure Kubernetes Service (AKS)

Pare-feu Azure

Azure Kubernetes Service (AKS)

Azure Private Link

Réseau virtuel Azure

Azure DevOps

Cet guide explique comment créer un cluster AKS privé dans une topologie de réseau hub-and-spoke à l’aide de Terraform et d’Azure DevOps. Pare-feu Azure est utilisé pour inspecter le trafic vers et depuis le cluster Azure Kubernetes Service (AKS). Le cluster est hébergé par un ou plusieurs réseaux virtuels spoke appariés au réseau virtuel hub.

Architecture

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

Workflow

Les modules Terraform sont utilisés pour déployer un nouveau réseau virtuel qui a quatre sous-réseaux qui hébergent :

Le cluster AKS (AksSubnet).
Une machine virtuelle de serveur de rebond et des points de terminaison privés (VmSubnet).
Application Gateway WAF2 (AppGatewaySubnet).
Azure Bastion (AzureBastionSubnet).

Le cluster AKS utilise une identité managée définie par l’utilisateur pour créer des ressources supplémentaires, telles que des équilibreurs de charge et des disques managés, dans Azure. Les modules Terraform vous permettent de déployer de manière facultative un cluster AKS doté des fonctionnalités suivantes :

Le cluster AKS est composé des pools suivants :

Un pool de nœuds système qui héberge uniquement des services et des pods système critiques
Un pool de nœuds utilisateur qui héberge des charges de travail et des artefacts d’utilisateurs

Une machine virtuelle est déployée dans le réseau virtuel qui héberge le cluster AKS. Lorsque vous déployez AKS en tant que cluster privé, les administrateurs système peuvent utiliser cette machine virtuelle pour gérer le cluster via l’outil de ligne de commande Kubernetes. Les journaux de diagnostics de démarrage de la machine virtuelle sont stockés dans un compte Stockage Azure.

Un hôte Azure Bastion offre une connectivité SSH à sécurité renforcée à la machine virtuelle de serveur de rebond via SSL. Azure Container Registry permet de créer, stocker et gérer des images conteneur et des artefacts (comme les charts Helm).

AKS ne fournit pas de solution intégrée pour sécuriser le trafic d’entrée et de sortie entre le cluster et les réseaux externes.

C’est pourquoi l’architecture présentée dans cet article inclut un pare-feu Azure qui contrôle le trafic entrant et sortant à l’aide de règles DNAT, de règles réseau et de règles d’application. Le pare-feu protège également les charges de travail grâce à un filtrage basé sur le renseignement sur les menaces. Le Pare-feu Azure et Bastion sont déployés sur un réseau virtuel hub qui est appairé au réseau virtuel qui héberge le cluster AKS privé. Une table de routage et des routes définies par l’utilisateur acheminent le trafic sortant du cluster AKS vers le Pare-feu Azure.

Remarque

Nous vous recommandons vivement d’utiliser le niveau tarifaire Premium de Pare-feu Azure, car il offre une protection avancée contre les menaces.

Un coffre de clés est utilisé comme magasin de secrets par les charges de travail qui s’exécutent sur AKS afin de récupérer des clés, des certificats et des secrets par le biais de l’identité de charge de travail Microsoft Entra, le pilote CSI du magasin de secrets ou Dapr. Azure Private Link permet aux charges de travail AKS d’accéder aux services PaaS Azure, comme Azure Key Vault, via un point de terminaison privé dans le réseau virtuel.

La topologie comprend des points de terminaison privés et des zones DNS privées pour ces services :

Il existe une liaison de réseau virtuel entre le réseau virtuel qui héberge le cluster AKS et les zones DNS privées décrites précédemment.

Un espace de travail Log Analytics permet de collecter les journaux de diagnostic et les métriques des services Azure.

Composants

Pare-feu Azure est un service de sécurité de pare-feu réseau intelligent, natif Cloud, qui assure la protection contre les menaces des charges de travail cloud exécutées dans Azure. Il s’agit d’un service de pare-feu avec état intégral, doté d’une haute disponibilité intégrée et d’une scalabilité illimitée dans le cloud. Il fournit l’inspection du trafic Est-Ouest et Nord-Sud.
Container Registry est un service de registre Docker managé et privé qui est basé sur le registre open source Docker 2.0. Vous pouvez utiliser des registres de conteneurs Azure avec vos pipelines de développement et de déploiement de conteneurs existants ou utiliser Container Registry Tasks pour créer des images conteneur dans Azure.
Azure Kubernetes Service simplifie le déploiement de clusters Kubernetes managés dans Azure en déchargeant la surcharge opérationnelle sur Azure. En tant que service Kubernetes hébergé, Azure gère des tâches critiques telles que le monitoring de l’intégrité et la maintenance. Les maîtres Kubernetes étant gérés par Azure, vous ne gérez et ne maintenez que les nœuds agents.
Key Vault stocke des secrets tels que des clés API, des mots de passe, des certificats et des clés de chiffrement et en contrôle l’accès avec une sécurité accrue. Key Vault vous permet également d’approvisionner, de gérer et de déployer facilement des certificats TLS/SSL publics et privés, à utiliser avec Azure et vos ressources connectées internes.
Azure Bastion est un service PaaS complètement managé que vous provisionnez au sein de votre réseau virtuel. Azure Bastion offre une connectivité RDP (Remote Desktop Protocol) et SSH (Secure Shell) plus sécurisée aux machines virtuelles de votre réseau virtuel, directement à partir du portail Azure via TLS.
Machines virtuelles Microsoft Azure fournit des ressources informatiques à la demande et évolutives qui vous offrent la flexibilité de la virtualisation.
Le réseau virtuel Azure est le bloc de construction fondamental pour vos réseaux privés Azure. Réseau virtuel Microsoft Azure permet aux ressources Azure (comme les machines virtuelles) de communiquer entre elles, avec Internet et avec les réseaux locaux, avec une sécurité renforcée. Un réseau virtuel Azure est comme un réseau traditionnel local, mais il inclut les avantages de l’infrastructure Azure tels que la scalabilité, la disponibilité et l’isolement.
Les interface de réseau virtuel permettent aux machines virtuelles Azure de communiquer avec des ressources sur Internet, sur Azure et locales. Vous pouvez ajouter plusieurs cartes d’interface réseau supplémentaires à une machine virtuelle Azure, de sorte que les machines virtuelles enfants puissent avoir leurs propres périphériques d’interface réseau et adresses IP dédiés.
Les disques managés Azure fournissent des volumes de stockage au niveau des blocs qu’Azure gère sur les machines virtuelles Azure. Des disques Ultra, des disques SSD Premium, des disques SSD standard et des disques durs (HDD) standard sont disponibles.
Stockage Blob est une solution de stockage d’objets pour le cloud. Stockage Blob est optimisé pour stocker des quantités massives de données non structurées.
Private Link vous permet d’accéder aux services PaaS Azure (par exemple, Stockage Blob et Key Vault) via un point de terminaison privé de votre réseau virtuel. Vous pouvez également l’utiliser pour accéder aux services hébergés par Azure dont vous êtes propriétaire ou qui sont fournis par un partenaire Microsoft.

Autres solutions

Vous pouvez utiliser un pare-feu tiers provenant de Place de marché Azure à la place de Pare-feu Azure. Dans ce cas, il vous incombe de configurer correctement le pare-feu pour inspecter et autoriser ou refuser le trafic entrant et sortant du cluster AKS.

Détails du scénario

Les clusters AKS sont déployés sur un réseau virtuel, qui peut être géré ou personnalisé. Dans les deux cas, le cluster a des dépendances sortantes sur des services en dehors du réseau virtuel. Pour la gestion et à des fins opérationnelles, les nœuds d’un cluster AKS doivent accéder à certains ports spécifiques et noms de domaine complet (FQDN) associés à ces dépendances sortantes. Cela inclut l’accès au serveur d’API Kubernetes de votre propre cluster, le téléchargement et l’installation des composants du cluster, ainsi que l’extraction d’images conteneur à partir de Microsoft Container Registry. Ces dépendances sortantes sont définies avec des noms de domaine complets et n’ont pas d’adresses statiques, ce qui rend impossible le verrouillage du trafic sortant à l’aide de groupes de sécurité réseau. Par conséquent, les clusters AKS disposent d’un accès Internet sortant illimité par défaut, ce qui permet aux nœuds et aux services d’accéder aux ressources externes en fonction des besoins.

Toutefois, dans un environnement de production, il est généralement souhaitable de protéger le cluster Kubernetes contre l’exfiltration des données et d’autres trafics réseau non souhaités. Tout le trafic réseau, qu’il soit entrant ou sortant, doit être contrôlé en fonction de règles de sécurité. Pour ce faire, le trafic de sortie doit être limité tout en autorisant l’accès aux ports et adresses nécessaires pour les tâches de maintenance de routine du cluster, les dépendances sortantes et les exigences de la charge de travail.

Une solution simple consiste à utiliser un appareil de type pare-feu qui peut contrôler le trafic sortant en fonction des noms de domaine. Un pare-feu crée une barrière entre un réseau approuvé et Internet. Utilisez le Pare-feu Azure pour restreindre le trafic sortant en fonction du nom de domaine complet, du protocole et du port de destination, en fournissant un contrôle de trafic de sortie précis. Il permet également de répertorier les noms de domaine complets associés aux dépendances sortantes d’un cluster AKS, ce qui n’est pas possible avec les groupes de sécurité réseau. De plus, vous pouvez contrôler le trafic d’entrée et améliorer la sécurité en activant le filtrage basé sur le renseignement sur les menaces sur un Pare-feu Azure déployé sur un réseau de périmètre partagé. Ce filtrage peut générer des alertes et refuser le trafic vers et depuis des adresses IP et des domaines malveillants connus.

Vous pouvez créer un cluster AKS dans une topologie de réseau hub-and-spoke en utilisant Terraform et Azure DevOps. Pare-feu Azure est utilisé pour inspecter le trafic vers et depuis le cluster Azure Kubernetes Service (AKS). Le cluster est hébergé par un ou plusieurs réseaux virtuels spoke appariés au réseau virtuel hub.

Pare-feu Azure prend en charge trois références SKU différentes pour répondre à un large éventail de cas d’usage et de préférences des clients :

Pare-feu Azure Premium est recommandé pour sécuriser les applications hautement sensibles, telles que le traitement des paiements. Il prend en charge des fonctionnalités avancées de protection contre les menaces telles que l’inspection des programmes malveillants et TLS.
Pare-feu Azure Standard est recommandé aux clients qui recherchent un pare-feu de couche 3 à couche 7 et qui ont besoin d’une mise à l’échelle automatique pour gérer les périodes de pointe de trafic allant jusqu’à 30 Gbits/s. Il prend en charge des fonctionnalités d’entreprise telles que le renseignement sur les menaces, le proxy DNS, le DNS personnalisé et les catégories web.
Pare-feu Azure De base est recommandé pour les clients dont les besoins en débit sont inférieurs à 250 Mbits/s.

Le tableau suivant présente les fonctionnalités des trois références SKU Pare-feu Azure. Pour plus d’informations, consultez Tarification Pare-feu Azure.

Capture d’écran montrant les fonctionnalités des trois références SKU Pare-feu Azure

Par défaut, les clusters AKS disposent d’un accès Internet sortant sans restriction. Ce niveau d’accès au réseau permet aux nœuds et aux services qui s’exécutent dans le cluster AKS d’accéder aux ressources externes selon les besoins. Si vous souhaitez restreindre le trafic de sortie, un nombre limité de ports et d’adresses doivent rester accessibles pour assurer des tâches de maintenance saines du cluster. Le moyen le plus simple d’assurer la sécurité du trafic sortant d’un cluster Kubernetes comme AKS est d’utiliser un pare-feu logiciel qui peut contrôler le trafic sortant en fonction des noms de domaine. Pare-feu Azure peut restreindre le trafic HTTP et HTTPS sortant en fonction du nom de domaine complet (FQDN) de la destination. Vous pouvez également configurer vos règles de pare-feu et de sécurité pour autoriser ces ports et adresses requis. Pour plus d’informations, consultez Contrôler le trafic de sortie pour les nœuds de cluster dans AKS.

De même, vous pouvez contrôler le trafic d’entrée et améliorer la sécurité en activant le filtrage basé sur le renseignement sur les menaces sur un Pare-feu Azure déployé sur un réseau de périmètre partagé. Ce filtrage peut fournir des alertes et refuser le trafic vers et depuis des adresses IP et des domaines malveillants connus.

Cas d’usage potentiels

Ce scénario répond à la nécessité d’améliorer la sécurité du trafic entrant et sortant vers et depuis un cluster Kubernetes.

Éviter le routage asymétrique

Dans cette solution, Pare-feu Azure est déployé sur un réseau virtuel hub et le cluster AKS privé est déployé sur un réseau virtuel spoke. Pare-feu Azure utilise des collections de règles de réseau et d’application pour contrôler le trafic de sortie. Dans cette situation, vous devez configurer le trafic d’entrée vers tout point de terminaison public exposé par un service s’exécutant sur AKS pour qu’il entre dans le système via l’une des IP publiques utilisées par le pare-feu Azure.

Les paquets arrivent sur l’IP publique du pare-feu, mais retournent au pare-feu par le biais de l’adresse IP privée (en utilisant l’itinéraire par défaut). Cela pose un problème. Pour l’éviter, créez un autre itinéraire défini par l’utilisateur pour l’IP publique du pare-feu, comme indiqué dans le schéma suivant. Les paquets destinés à l’IP publique du pare-feu sont acheminés via Internet. Cette configuration permet d’éviter l’itinéraire par défaut vers l’adresse IP privée du pare-feu.

Pour router le trafic de vos charges de travail AKS vers le Pare-feu Azure dans le réseau virtuel hub, vous devez :

Créer et associer une table de routage à chaque sous-réseau qui héberge les nœuds Worker de votre cluster.
Créer une route définie par l’utilisateur afin de transférer le trafic pour le routage CIDR (Classless InterDomain Routing) 0.0.0.0/0 vers l’adresse IP privée du Pare-feu Azure. Spécifiez Appliance virtuelle comme type de tronçon suivant.

Pour plus d’informations, consultez Didacticiel : Déployer et configurer un pare-feu Azure à l’aide du portail Azure

Pour plus d'informations, consultez les pages suivantes :

Déployer des charges de travail sur un cluster AKS privé lors de l’utilisation d’Azure DevOps

Si vous utilisez Azure DevOps, notez que vous ne pouvez pas utiliser les agents Azure DevOps hébergés par Microsoft pour déployer vos charges de travail sur un cluster AKS privé. Ils n’ont pas accès à son serveur API. Pour déployer des charges de travail sur votre cluster AKS privé, vous devez approvisionner et utiliser un agent autohébergé Azure DevOps dans le même réseau virtuel que votre cluster AKS privé ou dans un réseau virtuel appairé. Dans ce dernier cas, veillez à créer une liaison de réseau virtuel entre la zone DNS privée du cluster AKS dans le groupe de ressources de nœud et le réseau virtuel qui héberge l’agent autohébergé Azure DevOps.

Vous pouvez déployer un seul agent Azure DevOps Windows ou Linux sur une machine virtuelle, ou vous pouvez utiliser un groupe de machines virtuelles identiques. Pour plus d’informations, consultez Agents de groupes de machines virtuelles identiques Azure. Vous pouvez également configurer un agent autohébergé dans Azure Pipelines pour qu’il s’exécute dans un conteneur Windows Server Core (pour les hôtes Windows) ou Ubuntu (pour les hôtes Linux) avec Docker. Déployez-le en tant que pod avec un ou plusieurs réplicas dans votre cluster AKS privé. Pour plus d'informations, consultez les pages suivantes :

Si les sous-réseaux qui hébergent les pools de nœuds de votre cluster AKS privé sont configurés de façon à router le trafic de sortie vers un Pare-feu Azure via une table de routage et une route définie par l’utilisateur, veillez à créer les règles d’application et de réseau appropriées. Ces règles doivent permettre à l’agent d’accéder à des sites externes pour télécharger et installer des outils tels que Docker, Kubectl, Azure CLI et Helm sur la machine virtuelle de l’agent. Pour plus d’informations, consultez Exécuter un agent autohébergé dans Docker.

Vous pouvez également configurer un Pool DevOps managé (MDP) dans le réseau virtuel hébergeant votre cluster AKS ou dans un réseau virtuel appairé. Les pools DevOps managés permettent aux équipes de développement de créer des pools d’agents Azure DevOps adaptés à leurs besoins spécifiques. Ils mettent en œuvre les bonnes pratiques de sécurité, offrent des options pour équilibrer coût et performance, fournissent des solutions pour les scénarios les plus courants, et réduisent considérablement le temps consacré à la création et à la maintenance de pools personnalisés. Pour en savoir plus, consultez Vue d’ensemble de l’architecture des pools DevOps managés par Microsoft.

Vous pouvez ajouter des agents d’un pool DevOps managé dans votre réseau virtuel, ce qui permet aux pipelines CI/CD d’interagir avec le serveur d’API Kubernetes de votre cluster AKS privé et d’accéder aux ressources Azure, notamment Azure Container Registry, dont l’accès au réseau public est désactivé et qui sont uniquement accessibles via un point de terminaison privé défini dans le même réseau virtuel ou un réseau appairé. Pour en savoir plus, consultez Configurer la mise en réseau des pools DevOps managés.

Utiliser Pare-feu Azure devant un équilibreur de charge standard public

Les définitions de ressource dans les modules Terraform utilisent le méta-argument lifecycle pour personnaliser les actions lorsque les ressources Azure sont modifiées en dehors du contrôle de Terraform. L’argument ignore_changes est utilisé pour demander à Terraform d’ignorer les mises à jour de propriétés de ressources données, comme les balises. La définition de ressource Stratégie de pare-feu Azure contient un bloc lifecycle pour empêcher Terraform de mettre à jour la ressource lorsqu’une collection de règles ou une règle unique est créée, mise à jour ou supprimée. De même, la table de routage Azure contient un bloc lifecycle pour empêcher Terraform de mettre à jour la ressource lorsqu’un itinéraire défini par l’utilisateur est créé, supprimé ou mis à jour. Cela vous permet de gérer les règles DNAT, d’application et de réseau d’une stratégie de pare-feu Azure, ainsi que les itinéraires définis par l’utilisateur d’une table de routage Azure en dehors du contrôle de Terraform.

L’exemple associé à cet article contient un pipeline de déploiement continu Azure DevOps qui montre comment déployer une charge de travail sur un cluster AKS privé à l’aide d’un pipeline Azure DevOps qui s’exécute sur un agent autohébergé. L’exemple déploie l’application web de gestion de projet redmine de Bitnami à l’aide d’un chart Helm public. Ce diagramme illustre la topologie de réseau de l’exemple :

Voici le flux de messages :

Une demande pour l’application web hébergée par AKS est envoyée à une IP publique qui est exposée par Pare-feu Azure via une configuration d’IP publique. L’IP publique et la configuration d’IP publique sont toutes deux dédiées à cette charge de travail.
Une règle DNAT de Pare-feu Azure traduit l’IP publique et le port de Pare-feu Azure en l’IP publique et le port utilisés par la charge de travail dans l’équilibreur de charge standard public Kubernetes du cluster AKS dans le groupe de ressources de nœud.
L’équilibreur de charge envoie la demande à l’un des pods de service Kubernetes qui s’exécute sur l’un des nœuds agents du cluster AKS.
Le message de réponse est renvoyé à l’appelant d’origine via un itinéraire défini par l’utilisateur. L’IP publique de Pare-feu Azure est le préfixe de l’adresse, et Internet est le type de tronçon suivant.
Tout appel sortant lancé par la charge de travail est routé vers l’adresse IP privée du Pare-feu Azure par la route définie par l’utilisateur par défaut. 0.0.0.0/0 est le préfixe de l’adresse, et Appliance virtuelle est le type de tronçon suivant.

Pour plus d’informations, consultez Utiliser Pare-feu Azure devant l’équilibreur de charge standard public du cluster AKS.

Utiliser Pare-feu Azure devant un équilibreur de charge standard interne

Dans l’exemple associé à cet article, une application ASP.NET Core est hébergée en tant que service par un cluster AKS et placée derrière un contrôleur d’entrée NGINX. Le contrôleur d’entrée NGINX est exposé via un équilibreur de charge interne qui possède une adresse IP privée dans le réseau virtuel spoke qui héberge le cluster AKS. Pour plus d’informations, consultez Créer un contrôleur d’entrée pour un réseau virtuel interne dans AKS. Lorsque vous déployez un contrôleur d’entrée NGINX, ou plus généralement un service LoadBalancer ou ClusterIP, avec l’annotation service.beta.kubernetes.io/azure-load-balancer-internal: "true" dans la section des métadonnées, un équilibreur de charge standard interne appelé kubernetes-internal est créé sous le groupe de ressources de nœud. Pour plus d’informations, consultez Utiliser un équilibreur de charge interne avec AKS. Comme le montre le schéma suivant, l’application web de test est exposée par le Pare-feu Azure via une IP publique Azure dédiée.

Voici le flux de messages :

Une requête pour l’application web de test hébergée par AKS est envoyée à une IP publique qui est exposée par le Pare-feu Azure via une configuration d’IP publique. L’IP publique et la configuration d’IP publique sont toutes deux dédiées à cette charge de travail.
Une règle DNAT de Pare-feu Azure traduit l’IP publique et le port de Pare-feu Azure en l’IP publique et le port utilisés par le contrôleur d’entrée NGINX dans l’équilibreur de charge standard interne du cluster AKS dans le groupe de ressources de nœud.
La demande est envoyée par l’équilibreur de charge interne à l’un des pods de service Kubernetes qui s’exécute sur l’un des nœuds agents du cluster AKS.
Le message de réponse est renvoyé à l’appelant d’origine via un itinéraire défini par l’utilisateur. 0.0.0.0/0 est le préfixe de l’adresse, et Appliance virtuelle est le type de tronçon suivant.
Tout appel sortant initié par la charge de travail est acheminé vers l’adresse IP privée de l’itinéraire défini par l’utilisateur.

Pour plus d’informations, consultez Utiliser Pare-feu Azure devant un équilibreur de charge standard interne.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Certaines des considérations suivantes sont des recommandations générales qui ne sont pas spécifiques à l’utilisation de Pare-feu Azure pour améliorer la protection d’un cluster AKS. Nous pensons qu’il s’agit d’exigences essentielles de cette solution. Cela s’applique aux considérations relatives à la sécurité, aux performances, à la disponibilité et à la fiabilité, au stockage, au maillage des services et à la surveillance.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

La plateforme Azure offre une meilleure protection contre différentes menaces, par exemple les intrusions dans le réseau et les attaques par déni de service distribué (DDoS, Distributed Denial of Service). Vous devez utiliser un pare-feu d’applications web (WAF) pour protéger les applications et services web hébergés par 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. Pour ce faire, utilisez les règles de l’organisation Open Web Application Security Project (OWASP) et des 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 Azure Web Application Firewall avec Azure Application Gateway, Azure Front Door et Azure Content Delivery Network.

Les attaques DDoS font partie des principaux problèmes de disponibilité et de sécurité auxquels sont confrontées les organisations qui déplacent leurs applications vers le cloud. Une attaque DDoS tente d’épuiser les ressources d’une application afin de la rendre indisponible aux utilisateurs légitimes. Les attaques DDoS peuvent viser n’importe quel point de terminaison qui est publiquement accessible via l’Internet. Chaque propriété dans Azure comprend une protection par le biais de la protection DDoS Azure d’infrastructure sans coût supplémentaire. De par son échelle et sa capacité, le réseau Azure déployé à l’échelle mondiale permet d’améliorer la défense contre les attaques courantes de la couche réseau grâce au monitoring continu du trafic et à l’atténuation en temps réel. La protection d’infrastructure DDoS ne demande aucun changement dans la configuration utilisateur ni dans l’application. Il permet de protéger tous les services Azure, notamment les services PaaS comme Azure DNS.

La Protection réseau Azure DDoS, combiné aux bonnes pratiques de conception d’application, offre des fonctionnalités d’atténuation des attaques DDoS améliorées pour une meilleure défense contre les attaques DDoS. Vous devez activer la Protection réseau Azure DDOS sur tout réseau virtuel de périmètre.

Voici quelques considérations supplémentaires en matière de sécurité :

Créez un point de terminaison privé 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 d’un service PaaS via un point de terminaison privé passe par le réseau principal de Microsoft, mais la communication ne passe pas par le Pare-feu Azure. Ce mécanisme offre une meilleure sécurité et une meilleure protection contre les fuites de données. Pour plus d’informations, consultez Qu’est-ce qu’Azure Private Link ?.
Lorsque vous utilisez Application Gateway devant le cluster AKS, utilisez une stratégie de pare-feu d’applications web pour aider à protéger des attaques les charges de travail tournées vers le public qui s’exécutent sur AKS.
Utilisez des stratégies réseau pour séparer et sécuriser les communications intraservice en contrôlant les composants qui peuvent communiquer entre eux. 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 stratégies de réseau Azure ou les stratégies de réseau Calico pour définir des règles qui contrôlent le flux de trafic entre les différents microservices. Pour plus d’informations, consultez Stratégie de réseau.
N'exposez pas de connectivité à distance sur vos nœuds AKS. Créez un hôte bastion, ou une jumpbox, dans un réseau virtuel de gestion. Utilisez l’hôte bastion pour acheminer le trafic vers votre cluster AKS.
Envisagez d’utiliser un cluster AKS privé dans votre environnement de production, ou au moins de sécuriser l’accès au serveur d’API, en utilisant des plages d’adresses IP autorisées dans AKS. 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.
Si vous activez le proxy DNS dans Pare-feu Azure, Pare-feu Azure peut traiter et rediriger les requêtes DNS d’un ou plusieurs réseaux virtuels vers un serveur DNS de votre choix. Cette fonctionnalité est cruciale et nécessaire pour disposer d’un filtrage fiable des noms de domaine complets dans les règles de réseau. Vous pouvez activer le proxy DNS dans les paramètres du Pare-feu Azure et de la stratégie de pare-feu. Pour en savoir plus sur les journaux du proxy DNS, consultez Journal et métriques de Pare-feu Azure.
Lorsque vous utilisez Pare-feu Azure devant Application Gateway, vous pouvez configurer votre ressource d’entrée Kubernetes pour exposer les charges de travail via HTTPS et utiliser un sous-domaine et un certificat numérique distincts pour chaque locataire. Le contrôleur d’entrée d’Application Gateway (AGIC) configure automatiquement l’écouteur Application Gateway pour la terminaison SSL.
Vous pouvez utiliser Pare-feu Azure devant un proxy de service comme le contrôleur d’entrée NGINX. Ce contrôleur fournit un proxy inverse, un routage de trafic configurable et une terminaison TLS pour les services Kubernetes. Des ressources d’entrée Kubernetes sont utilisées pour configurer les règles d’entrée et les itinéraires des services Kubernetes individuels. En utilisant un contrôleur d’entrée et des règles d’entrée, vous pouvez utiliser une seule adresse IP pour acheminer le trafic vers plusieurs services dans un cluster Kubernetes. Vous pouvez générer les certificats TLS à l’aide d’une autorité de certification reconnue. Vous pouvez également utiliser Let’s Encrypt pour générer automatiquement des certificats TLS avec une IP publique dynamique ou avec une IP publique statique. Pour plus d’informations, consultez Créer un contrôleur d’entrée HTTPS et utiliser vos propres certificats TLS sur AKS.
Une coordination stricte entre l’opérateur de Pare-feu Azure et les équipes chargées des charges de travail et des clusters est nécessaire à la fois pour le déploiement initial des clusters et de manière continue, à mesure que les besoins en charge de travail et en cluster évoluent. Cela est particulièrement vrai lorsque vous configurez les mécanismes d’authentification, tels que OAuth 2.0 et OpenID Connect, qui sont utilisés par les charges de travail pour authentifier leurs clients.
Utilisez les instructions suivantes pour aider à sécuriser l’environnement décrit dans cet article :

Disponibilité et fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Les considérations relatives à la disponibilité et à la fiabilité présentées ici ne sont pas spécifiques à l’architecture mutualisée dans AKS. Nous pensons qu’il s’agit d’exigences essentielles pour cette solution. Envisagez les méthodes suivantes pour optimiser la disponibilité de votre cluster AKS et de vos charges de travail.

Résilience entre les régions

Pendant le déploiement, vous pouvez configurer Pare-feu Azure pour qu’il couvre plusieurs zones de disponibilité afin d’augmenter la disponibilité. Pour connaître les pourcentages de durée de bon fonctionnement, consultez le Contrat de niveau de service (SLA) de Pare-feu Azure. Vous pouvez également associer Pare-feu Azure à une zone spécifique pour des raisons de proximité, bien que cette configuration influe sur le contrat SLA. Le déploiement d'un pare-feu dans une zone de disponibilité n'entraîne aucun coût supplémentaire, y compris pour les transferts de données entre zones de disponibilité.
Envisagez de déployer les pools de nœuds de votre cluster AKS dans toutes les zones de disponibilité d’une région. Utilisez un équilibreur de charge standard Azure ou une passerelle applicative devant les pools de nœuds. Cette topologie offre une meilleure résilience en cas de panne d’un centre de donnée unique. Les nœuds de cluster sont répartis entre plusieurs centres de données, dans trois zones de disponibilité distinctes au sein d’une région.
Activez la redondance de zone dans Container Registry à des fins de résilience et de haute disponibilité intrarégionale.
Utilisez les contraintes de répartition de la topologie des pods pour contrôler la répartition des pods dans votre cluster AKS entre les domaines de défaillance tels que les régions, les zones de disponibilité et les nœuds.
Envisagez d’utiliser le contrat SLA de durée de fonctionnement pour les clusters AKS qui hébergent des charges de travail stratégiques. Le contrat SLA de durée de bon fonctionnement est une fonctionnalité facultative qui permet d’obtenir un SLA plus élevé, soutenu financièrement, pour un cluster. Le contrat SLA de durée de bon fonctionnement garantit la haute disponibilité du point de terminaison du serveur d’API Kubernetes pour les clusters qui utilisent des zones de disponibilité. Vous pouvez également l’utiliser pour les clusters qui n’utilisent pas de zones de disponibilité, mais le contrat SLA est inférieur. Pour plus d’informations sur les contrats SLA, consultez Contrat SLA de durée de bon fonctionnement. AKS utilise les réplicas de nœud principal entre les domaines de mise à jour et d’erreur pour garantir la satisfaction des exigences de contrat SLA.

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

Envisagez de déployer votre solution dans au moins deux régions Azure jumelées d’une zone géographique. Utilisez un équilibreur de charge global, comme Azure Traffic Manager ou Azure Front Door, avec une méthode de routage actif/actif ou actif/passif afin de garantir la continuité d’activité et la reprise d’activité (BCDR).
Pare-feu Azure est un service régional. Si vous déployez votre solution dans plusieurs régions, vous devez créer un Pare-feu Azure dans chaque région. Vous pouvez créer une stratégie de pare-feu Azure globale pour inclure les règles mandatées par l’organisation qui s’appliquent à tous les hubs régionaux. Vous pouvez utiliser cette stratégie comme stratégie parente pour les stratégies Azure régionales. Les stratégies qui sont créées à partir de stratégies parentes non vides héritent toutes les collections de règles de la stratégie parente. Les collections de règles de réseau héritées d’une stratégie parente sont toujours prioritaires par rapport aux collections de règles de réseau définies dans le cadre d’une nouvelle stratégie. La même logique s’applique aux collections de règles d’application. Cependant, les collections de règles de réseau sont toujours traitées avant les collections de règles d’application, quel que soit l’héritage. Pour plus d’informations sur les stratégies Standard et Premium, consultez Vue d’ensemble de la stratégie Azure Firewall Manager.
Veillez à générer un script, à documenter et à tester régulièrement tout processus de basculement régional dans un environnement d’assurance qualité. Cela permet d’éviter des problèmes imprévisibles si un service principal est victime d’une panne dans la région primaire. Ces tests permettent également de vérifier si l’approche de récupération d’urgence répond aux objectifs RPO/RTO, en association avec les éventuels processus et interventions manuels nécessaires à un basculement.
Veillez à tester les procédures de restauration pour vérifier qu’elles fonctionnent comme prévu.
Stockez vos images conteneur dans Container Registry. Géorépliquez le registre dans chaque région AKS. Pour plus d’informations, consultez Géoréplication dans Azure Container Registry.
Si possible, évitez de stocker l’état des services dans le conteneur. Utilisez plutôt un modèle PaaS Azure qui prend en charge la réplication multirégion.
Si vous utilisez Stockage Azure, préparez et testez un processus de migration de votre stockage de la région primaire vers la région de sauvegarde.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

DevOps

Déployez vos charges de travail sur AKS à l’aide d’un chart Helm dans un pipeline d’intégration continue et de livraison continue (CI/CD). Utilisez un système DevOps tel que GitHub Actions ou Azure DevOps. Pour plus d’informations, consultez Générer et déployer sur Azure Kubernetes Service.
Pour tester correctement une application avant de la mettre à la disposition des utilisateurs, utilisez des tests A/B et des déploiements de contrôle de validité dans votre gestion du cycle de vie des applications. Vous pouvez utiliser plusieurs techniques pour fractionner le trafic entre les différentes versions du même service. Vous pouvez également utiliser les fonctionnalités de fractionnement du trafic fournies par une implémentation de maillage de service. Pour plus d’informations, consultez Linkerd Traffic Split et Istio Traffic Management.
Utilisez Azure Container Registry ou un autre registre de conteneurs (comme Docker Hub) pour stocker les images Docker privées déployées sur le cluster. AKS peut s’authentifier auprès d’Azure Container Registry à l’aide de son identité Microsoft Entra.
Testez l’entrée et la sortie sur vos charges de travail dans un environnement de pré-production distinct qui reflète la topologie de réseau et les règles de pare-feu de votre environnement de production. Une stratégie de déploiement par étapes vous aidera à détecter tout problème de mise en réseau ou de sécurité avant de mettre en production une nouvelle fonctionnalité ou une nouvelle règle de réseau.

Supervision

Pare-feu Azure est entièrement intégré à Azure Monitor pour la journalisation du trafic entrant et sortant traité par le pare-feu. Pour plus d’informations, voir Fonctionnalité de filtrage basé sur la Threat Intelligence du Pare-feu Azure.

Les considérations suivantes relatives à la supervision ne sont pas spécifiques à l’architecture mutualisée dans AKS, mais nous pensons qu’il s’agit d’exigences essentielles pour cette solution.

Utilisez Container Insights pour surveiller l’état d’intégrité du cluster AKS et des charges de travail.
Configurez tous les services PaaS (comme Container Registry et Key Vault) pour collecter les journaux de diagnostic et les métriques.

Optimisation des coûts

Le coût de l’architecture obtenue dépend des détails suivants de la configuration :

Niveaux de service
Scalabilité (le nombre d’instances allouées dynamiquement par les services pour répondre à une demande donnée)
Scripts d’automatisation
votre niveau de récupération d’urgence.

Après avoir évalué ces détails de configuration, utilisez la calculatrice de prix Azure pour estimer vos coûts. Pour plus d’options d’optimisation de la tarification, consultez les principes d’optimisation des coûts dans Microsoft Azure Well-Architected Framework.

Déployer ce scénario

Le code source de ce scénario est disponible sur GitHub. Cette solution open source est fournie avec unelicence MIT.

Prérequis

Pour les déploiements en ligne, vous avez besoin d’un compte Azure. Si vous n’en avez pas, créez un compte Azure gratuit avant de commencer. Vous devez remplir les conditions suivantes avant de pouvoir déployer des modules Terraform en utilisant Azure DevOps :

Stockez le fichier d’état Terraform dans un compte de stockage Azure. Pour plus d’informations sur l’utilisation d’un compte de stockage pour stocker l’état Terraform distant, le verrouillage de l’état et le chiffrement au repos, consultez Stocker l’état de Terraform dans Stockage Azure.
Créez un projet Azure DevOps. Pour plus d’informations, consultez Créer un projet dans Azure DevOps.
Créez une connexion de service Azure DevOps à votre abonnement Azure. Vous pouvez utiliser l’authentification du principal de service ou une identité de service géré Azure lorsque vous créez la connexion de service. Dans les deux cas, assurez-vous que le principal de service ou l’identité managée utilisée par Azure DevOps pour se connecter à votre abonnement Azure se voit attribuer le rôle de propriétaire sur l’ensemble de l’abonnement.

Déploiement vers Azure

Ayez à portée de main les informations relatives à votre abonnement Azure.

Clonez le référentiel GitHub du workbench :

git clone https://github.com/Azure-Samples/private-aks-cluster-terraform-devops.git

Suivez les instructions fournies dans le fichier README.md.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Paolo Salvatori | Ingénieur des services principaux

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

Étapes suivantes

Consultez les recommandations et les meilleures pratiques pour AKS dans Microsoft Azure Well-Architected Framework :

Partager via

Utiliser Pare-feu Azure pour aider à protéger un cluster Azure Kubernetes Service (AKS)