Utiliser le contrôleur d’entrée Application Gateway avec un cluster Azure Kubernetes Service mutualisé

Application Gateway Azure

Azure Key Vault

Azure Container Registry

Azure Kubernetes Service (AKS)

Azure Bastion

Cette solution utilise le pare-feu d’applications web Azure (WAF) pour fournir une protection centralisée pour les applications web que vous déployez sur un cluster Azure Kubernetes Service (AKS) mutualisé. WAF permet de protéger contre les attaques et les vulnérabilités courantes.

Vous pouvez utiliser une stratégie WAF sur Azure Application Gateway pour protéger les applications web contre les attaques malveillantes, telles que l’injection SQL et les scripts intersites. Cette méthode permet de protéger les applications web qui s’exécutent sur un cluster AKS et sont exposées via le contrôleur d’entrée Application Gateway (AGIC). La stratégie WAF sur Application Gateway est préconfigurée avec l’ensemble de règles OWASP (Open Worldwide Application Security Project) Core Rule Set (CRS) et prend en charge d’autres versions OWASP CRS. Vous pouvez également créer des règles personnalisées.

Architecture

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

Flux de travail

• Cette architecture utilise un modèle Azure Resource Manager complémentaire (modèle ARM) pour déployer un nouveau réseau virtuel avec quatre sous-réseaux :

  • AksSubnet héberge le cluster AKS.
  • VmSubnet héberge une machine virtuelle jumpbox et des points de terminaison privés.
  • AppGatewaySubnet héberge le niveau WAF2 Application Gateway.
  • AzureBastionSubnet héberge Azure Bastion.

• Le cluster AKS utilise une identité managée définie par l’utilisateur pour créer davantage de ressources, telles que des équilibreurs de charge et des disques managés, dans Azure. Vous pouvez utiliser le modèle ARM pour déployer un cluster AKS avec les fonctionnalités suivantes :

  • Pilotes CSI (Container Stockage Interface) pour les disques Azure et Azure Files
  • Intégration Microsoft Entra gérée par AKS
  • Contrôle d'accès Azure basé sur les rôles (RBAC) pour l'autorisation Kubernetes
  • Une identité managée à la place d’un principal de service
  • ID de charge de travail Microsoft Entra
  • Stratégies réseau Azure
  • Module complémentaire des insights de conteneur Azure Monitor
  • Module complémentaire AGIC
  • Allocation dynamique d’adresses IP et prise en charge améliorée du sous-réseau

• Le cluster AKS possède les pools de nœuds suivants :

  • Le pool de nœuds système héberge uniquement les pods et services système critiques. Les nœuds Worker ont une teinte de nœud qui empêche les pods d’application d’être planifiés sur ce pool de nœuds.
  • Le pool de nœuds utilisateur héberge les charges de travail et les artefacts des utilisateurs.

• Une machine virtuelle est déployée dans le même réseau virtuel que celui 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 fournit une connectivité SECURE Shell (SSH) sécurisée et transparente à la machine virtuelle jumpbox, directement dans le Portail Azure via SSL (Secure Sockets Layer). Cette solution utilise Azure Container Registry pour générer, stocker et gérer des images et artefacts conteneur, tels que des graphiques Helm.

• L’architecture inclut une passerelle d’application que le contrôleur d’entrée utilise. La passerelle d’application est déployée sur un sous-réseau dédié et exposée à l’Internet public via une adresse IP publique que partagent toutes les charges de travail de locataire. Une stratégie WAF permet de protéger les charges de travail des locataires contre les attaques malveillantes.

  La stratégie WAF est associée à la passerelle Application Gateway au niveau racine et au niveau de l’écouteur HTTP. La stratégie est configurée en mode de prévention et utilise OWASP 3.1 pour bloquer les intrusions et les attaques détectées par les règles. L’attaquant reçoit une exception d’accès non autorisé 403 et la connexion est fermée. Le mode de prévention enregistre ces attaques dans les journaux WAF.

• Les charges de travail qui s’exécutent sur AKS utilisent un coffre de clés comme magasin de clés pour récupérer des clés, des certificats et des secrets via une bibliothèque cliente, un pilote CSI du magasin de secrets ou Dapr. Azure Private Link permet aux charges de travail AKS d’accéder aux solutions PaaS (Platform as a Service) Azure, telles qu’Azure Key Vault, sur un point de terminaison privé dans le réseau virtuel.

• Cette architecture inclut des points de terminaison privés aux composants suivants :

  • Compte Stockage Blob Azure
  • Registre de conteneurs
  • Coffre-fort de clés
  • Serveur d’API du cluster Kubernetes, si vous utilisez un cluster AKS privé

• L’architecture inclut également des zones DNS privées pour résoudre le nom de domaine complet (FQDN) d’un service PaaS vers l’adresse IP privée de son point de terminaison privé associé. Cette architecture inclut des zones DNS privées pour résoudre les points de terminaison privés vers les composants suivants :

  • Compte de stockage d’objets blob
  • Registre de conteneurs
  • Coffre-fort de clés
  • L’API du serveur Kubernetes, si vous déployez le cluster en tant que privé

• Une liaison de réseau virtuel existe entre le réseau virtuel qui héberge le cluster AKS et les zones DNS privées précédentes. Un espace de travail Log Analytics collecte les journaux de diagnostic et les métriques à partir des sources suivantes :

  • Le cluster AKS
  • Machine virtuelle jumpbox
  • Application Gateway
  • Coffre-fort de clés
  • Groupes de sécurité réseau Azure

Composants

• 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. Vous pouvez également utiliser des tâches Container Registry pour générer des images conteneur dans Azure. Vous pouvez générer à la demande ou automatiser entièrement des builds avec des déclencheurs, tels que des validations de code source et des mises à jour d’images de base.

• AKS simplifie le déploiement d’un cluster Kubernetes managé 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 l’analyse de l’intégrité et la maintenance. Azure gère les nœuds du plan de contrôle Kubernetes, de sorte que vous gérez et gérez uniquement les nœuds de l’agent.

• Key Vault permet de stocker et de contrôler en toute sécurité l’accès aux secrets, tels que les clés API, les mots de passe, les certificats et les clés de chiffrement. Vous pouvez utiliser Key Vault pour provisionner, gérer et déployer facilement des certificats TLS ou SSL (Transport Layer Security) publics et privés, et les utiliser avec Azure et vos ressources connectées internes.

• Application Gateway est un équilibreur de charge de trafic web que vous pouvez utiliser pour gérer le trafic entrant qui passe aux applications web en aval et aux API REST. Les équilibreurs de charge traditionnels fonctionnent au niveau de la couche de transport, qui est open Systems Interconnexion (OSI) couche 4, pour gérer le trafic qui utilise tcp (Transmission Control Protocol) et UDP (User Datagram Protocol). Ils acheminent le trafic en fonction de l’adresse IP et du port source vers une adresse IP et un port de destination. Une passerelle d’application est un équilibreur de charge au niveau de la couche application, qui est la couche OSI 7.

• WAF est un service qui permet de fournir une protection centralisée des applications web contre les attaques et vulnérabilités courantes. WAF est basé sur des règles du CRS OWASP. Vous pouvez utiliser WAF pour créer des règles personnalisées évaluées pour chaque requête qui passe par une stratégie. Ces règles ont une priorité plus élevée que les autres règles des ensembles de règles gérés. Les règles personnalisées contiennent un nom de règle, une priorité de règle et un tableau des conditions de correspondance. Si la demande répond à ces conditions, WAF autorise ou bloque la requête en fonction de la règle.

• Azure Bastion est un service PaaS complètement managé que vous approvisionnez au sein de votre réseau virtuel. Azure Bastion permet de fournir une connectivité RDP (Remote Desktop Protocol) sécurisée et transparente aux machines virtuelles de votre réseau virtuel, directement à partir du Portail Azure via TLS.

• Azure Machines Virtuelles fournit des ressources informatiques évolutives à la demande qui vous offrent la flexibilité de la virtualisation sans avoir à acheter et à maintenir le matériel physique.

• Le réseau virtuel Azure est le bloc de construction fondamental pour vos réseaux privés Azure. Avec Réseau virtuel, les ressources Azure, telles que les machines virtuelles, peuvent communiquer entre elles, internet et réseaux locaux de manière plus sécurisée. Le réseau virtuel Azure est similaire à un réseau traditionnel local, mais il inclut les avantages de l’infrastructure Azure, tels que la scalabilité, la disponibilité et l’isolement.

• Les interfaces de réseau virtuel permettent d’établir la communication entre les machines virtuelles Azure et Internet, Azure et les ressources 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 sont des volumes de stockage au niveau du bloc qu’Azure gère sur des machines virtuelles Azure. Les types de disques incluent stockage sur disque Azure Ultra, SSD Azure Premium, SSD Azure Standard et HDD Azure Standard.

• Le stockage Blob est une solution de stockage d’objets Microsoft pour le cloud. Stockage Blob est optimisé pour stocker des quantités massives de données non structurées. Les données non structurées sont des données qui ne respectent pas un modèle de données ou une définition particulier, telles que des données texte ou des données binaires.

• Private Link fournit un point de terminaison privé dans votre réseau virtuel afin de pouvoir accéder aux services PaaS Azure, tels que Stockage Blob et Key Vault, et accéder aux services hébergés par Azure, appartenant au client ou aux services partenaires.

Autres solutions

Lorsque vous exposez des charges de travail que vous hébergez dans un cluster AKS, vous avez plusieurs solutions à prendre en compte. Au lieu d’utiliser L’AGIC, vous pouvez utiliser Application Gateway pour conteneurs ou l’entrée NGINX gérée avec le module complémentaire de routage d’application. Ces alternatives offrent différentes fonctionnalités pour aider à gérer et sécuriser le trafic vers votre cluster AKS.

Cette architecture installe AGIC via le module complémentaire AGIC pour AKS. Vous pouvez également installer L’AGIC via un graphique Helm. Lorsque vous créez une configuration, vous pouvez utiliser une ligne dans Azure CLI pour déployer une nouvelle passerelle d’application et un nouveau cluster AKS. Cette méthode active AGIC en tant que module complémentaire. Le module complémentaire est un service entièrement géré, qui offre des avantages supplémentaires, tels que les mises à jour automatiques et une prise en charge accrue. Il est également considéré comme un module complémentaire de première classe, qui offre une meilleure intégration à AKS. Microsoft prend en charge les deux méthodes de déploiement pour L’AGIC.

Le module complémentaire AGIC est déployé en tant que pod dans votre cluster AKS. Toutefois, il existe quelques différences entre la version du déploiement Helm et la version du module complémentaire de l’AGIC. La liste suivante présente les différences entre les deux versions :

• Vous ne pouvez pas modifier les valeurs de déploiement Helm sur le module complémentaire AKS :

  • La propriété usePrivateIp est définie sur false par défaut. Vous ne pouvez pas remplacer cette valeur par le biais de l’annotation use-private-ip .
  • Le module complémentaire ne prend pas en charge l’option shared de configuration.

• L’AGIC déployé par Helm prend en charge ProhibitedTargets, ce qui signifie que l’AGIC peut configurer la passerelle d’application spécifiquement pour les clusters AKS sans affecter d’autres back-ends existants.

• Le module complémentaire AGIC est un service managé. Il est donc automatiquement mis à jour vers la dernière version. Si vous déployez L’AGIC via Helm, vous devez mettre à jour manuellement l’AGIC.

• Vous ne pouvez déployer qu’un seul module complémentaire AGIC pour chaque cluster AKS. Chaque module complémentaire AGIC ne peut cibler qu’une seule instance Application Gateway. Pour les déploiements qui nécessitent plusieurs AGIC pour chaque cluster ou plusieurs GIC qui ciblent une instance Application Gateway, vous pouvez utiliser l’AGIC déployé par Helm.

Une seule instance de l’AGIC peut ingérer des événements à partir de plusieurs espaces de noms Kubernetes. Si l’administrateur AKS utilise la passerelle d’application comme entrée, tous les espaces de noms utilisent la même instance d’Application Gateway. Une seule installation de L’AGIC surveille les espaces de noms accessibles et configure la passerelle d’application à laquelle elle est associée. Pour plus d’informations, consultez Activer la prise en charge de plusieurs espaces de noms dans un cluster AKS avec l’AGIC.

Pour activer la prise en charge de plusieurs espaces de noms, procédez comme suit :

1. Modifiez le fichier helm-config.yaml de l’une des manières suivantes :

• Supprimez entièrement la watchNamespace clé du fichier helm-config.yaml pour permettre à l’AGIC d’observer tous les espaces de noms.
• Définissez watchNamespace sur une chaîne vide pour permettre à l’AGIC d’observer tous les espaces de noms.
• Ajoutez plusieurs espaces de noms séparés par une virgule, par exemple watchNamespace: default,secondNamespace, pour permettre à l’AGIC d’observer ces espaces de noms exclusivement.

2. Appliquer des modifications de modèle Helm avec ce script : helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure.

Après avoir déployé L’AGIC avec la possibilité d’observer plusieurs espaces de noms, l’AGIC effectue les actions suivantes :

1. Répertorie les ressources d’entrée de tous les espaces de noms accessibles
2. Filtre les ressources d’entrée qui sont annotées avec kubernetes.io/ingress.class: azure/application-gateway
3. Compose la configuration d’Application Gateway combinée
4. Applique la configuration à la passerelle d’application associée via Azure Resource Manager

Détails du scénario

Cette architecture partage un cluster Kubernetes mutualisé entre plusieurs utilisateurs et charges de travail communément appelés locataires. Cette définition inclut différentes équipes ou divisions au sein d’une organisation qui partagent des clusters Kubernetes. Il inclut également des clusters partagés par les instances par client d’une application SaaS (Software as a Service). L’architecture multi-locataire de cluster est une alternative à la gestion de nombreux clusters dédiés à un seul locataire. Les opérateurs d’un cluster Kubernetes mutualisés doivent isoler les locataires les uns des autres. Cette isolation réduit les dommages qu’un locataire compromis ou malveillant peut causer au cluster et à d’autres locataires. Lorsque plusieurs utilisateurs ou équipes partagent le même cluster avec un nombre fixe de nœuds, une équipe peut utiliser plus de ressources que nécessaire. Les administrateurs peuvent utiliser des quotas de ressources pour résoudre ce problème.

Lorsque vous envisagez de créer un cluster AKS multilocataire, vous devez prendre en compte les couches d’isolation des ressources que Kubernetes fournit, notamment le cluster, l’espace de noms, le nœud, le pod et l’isolation de conteneur. Vous devez également prendre en compte les implications en matière de sécurité du partage de différents types de ressources entre plusieurs locataires. Par exemple, si vous planifiez des pods à partir de différents locataires sur le même nœud, vous pouvez réduire le nombre d’ordinateurs dont vous avez besoin dans le cluster. En revanche, vous devrez peut-être empêcher certaines charges de travail d’être colocalisées. Par exemple, vous pourriez ne pas autoriser l'exécution de code non fiable provenant de l'extérieur de votre organisation sur le même nœud que les conteneurs qui traitent des informations sensibles. Vous pouvez utiliser Azure Policy pour que seuls les registres approuvés puissent être déployés sur AKS.

Kubernetes ne peut pas garantir une isolation parfaitement sécurisée entre les locataires, mais elle offre des fonctionnalités qui fournissent une sécurité suffisante pour des cas d’usage spécifiques. En guise de meilleure pratique, vous devez séparer chaque locataire et ses ressources Kubernetes dans leurs propres espaces de noms. Vous pouvez ensuite utiliser le RBAC Kubernetes et les stratégies réseau pour aider à appliquer l’isolation des locataires. Par exemple, le diagramme suivant montre un modèle de fournisseur SaaS classique qui héberge plusieurs instances de la même application sur le même cluster, un pour chaque locataire. Chaque application se trouve dans un espace de noms distinct. Lorsque les locataires ont besoin d’un niveau plus élevé d’isolation physique et de performances garanties, leurs charges de travail peuvent être déployées sur un ensemble dédié de nœuds, un pool dédié ou même un cluster dédié.

L’AGIC est une application Kubernetes, de sorte que les clients AKS peuvent utiliser une passerelle d’application pour exposer leurs applications conteneurisées à Internet. L’AGIC surveille le cluster Kubernetes sur lequel il est hébergé et met à jour en permanence une passerelle d’application afin que les services sélectionnés soient exposés à Internet. L’AGIC s’exécute dans son propre pod sur l’instance AKS du client. L’AGIC surveille un sous-ensemble de ressources Kubernetes pour les modifications. L’état du cluster AKS est traduit en configuration spécifique à Application Gateway et appliqué à Resource Manager. Cette architecture décrit les pratiques éprouvées pour déployer un cluster AKS public ou privé via une passerelle d’application et un module complémentaire AGIC.

Une seule instance de l’AGIC peut ingérer des événements à partir de plusieurs espaces de noms et y observer. Si l’administrateur AKS utilise Application Gateway comme entrée, tous les espaces de noms utilisent la même instance d’Application Gateway. Une seule installation d’AGIC surveille les espaces de noms accessibles et configure la passerelle d’application à laquelle elle est associée.

Cas d’usage potentiels

Utilisez AGIC pour exposer et protéger des charges de travail accessibles sur Internet qui s’exécutent sur un cluster AKS dans un environnement multilocataire.

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 de ces considérations ne concernent pas entièrement l’architecture multilocataire dans AKS, mais elles sont essentielles à cette solution. Ces considérations incluent la sécurité, les performances, la disponibilité, la fiabilité, le stockage, le planificateur, le maillage de service et les conseils de surveillance.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

Ces considérations relatives à la disponibilité et à la fiabilité ne sont pas entièrement liées à l’architecture mutualisée dans AKS, mais elles sont essentielles à cette solution. Tenez compte des méthodes suivantes pour optimiser la disponibilité de votre cluster AKS et de vos charges de travail.

Conteneurs

• Les sondes d’intégrité Kubernetes permettent de vérifier que vos conteneurs sont actifs et sains :

  • LivenessProbe indique si le conteneur est en cours d’exécution. Si la sonde liveness échoue, le kubelet met fin au conteneur et le conteneur est soumis à sa stratégie de redémarrage.

  • readinessProbe indique si le conteneur est prêt à répondre aux requêtes. Si la sonde de préparation échoue, le contrôleur de point de terminaison supprime l’adresse IP du pod des points de terminaison de tous les services qui correspondent au pod. État de préparation par défaut avant l’échec du délai initial.

  • Le startupProbe indique si l’application au sein du conteneur est démarrée. Si vous disposez d’une sonde de démarrage, toutes les autres sondes sont désactivées jusqu’à ce que la sonde de démarrage réussisse. Si la sonde de démarrage échoue, kubelet met fin au conteneur et le conteneur est soumis à sa stratégie de redémarrage.

• La contention de ressources est susceptible d’affecter la disponibilité du service. Définissez des contraintes de ressources de conteneurs pour éviter qu’un seul conteneur ne surcharge les ressources de mémoire et de CPU de cluster. Vous pouvez utiliser les diagnostics AKS pour identifier les problèmes dans le cluster.

• Utilisez la limite de ressources pour limiter le nombre total de ressources allouées à un conteneur afin qu’un conteneur ne puisse pas priver d’autres personnes.

Registre de conteneurs

• Stockez des images conteneur dans Container Registry. Utilisez la géoréplication container Registry pour géorépliquer le registre dans chaque région AKS. La géoréplication est une fonctionnalité du registre de conteneurs de référence SKU Premium.

• Analysez vos images conteneur pour détecter les vulnérabilités. Déployez uniquement des images qui passent la validation. Mettez régulièrement à jour les images de base et le runtime de l’application, puis redéployez vos charges de travail dans le cluster AKS.

• Limitez les registres d’images que les pods et déploiements peuvent utiliser. Limitez l’accès aux registres approuvés dans lesquels vous pouvez valider et contrôler les images disponibles.

• Analysez les images conteneur pour détecter les vulnérabilités dans le cadre d’un pipeline d’intégration continue et de livraison continue (CI/CD) avant de publier des images dans Container Registry. Lorsque vous utilisez des images de base pour les images d’application, utilisez l’automatisation pour générer de nouvelles images lorsque vous mettez à jour l’image de base. Les images de base incluent généralement des correctifs de sécurité. Vous devez donc mettre à jour les images conteneur d’applications en aval. Nous vous recommandons d’intégrer Microsoft Defender pour conteneurs dans des flux de travail CI/CD. Pour plus d’informations, consultez Automatiser les builds d’images conteneur.

• Utilisez les tâches Container Registry pour automatiser la mise à jour corrective du système d’exploitation et de l’infrastructure pour vos conteneurs Docker. Les tâches container Registry prennent en charge un processus de génération automatisé lorsque vous mettez à jour l’image de base d’un conteneur. Par exemple, vous pouvez corriger le système d’exploitation ou l’infrastructure d’application dans l’une de vos images de base.

Résilience entre les régions

• Envisagez de déployer les pools de nœuds de votre cluster AKS sur toutes les zones de disponibilité d’une région. Utilisez Azure Standard Load Balancer ou Application Gateway devant vos pools de nœuds. Cette topologie offre une meilleure résilience si une panne de centre de données unique se produit. Cette méthode distribue les nœuds de cluster entre plusieurs centres de données qui résident 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 des contraintes de répartition de topologie de pod pour contrôler la façon dont vous répartissez des pods sur votre cluster AKS entre des domaines d’échec, tels que des régions, des zones de disponibilité et des nœuds.

• Envisagez d’utiliser un contrat de niveau de service de temps d’activité (SLA) pour les clusters AKS qui hébergent des charges de travail stratégiques. Un contrat SLA de temps d’activité est une fonctionnalité facultative permettant d’activer un contrat SLA financièrement soutenu, plus élevé pour un cluster. Un contrat SLA de temps d’activité garantit une disponibilité de 99,95 % du point de terminaison du serveur d’API Kubernetes pour les clusters qui utilisent des zones de disponibilité. Il garantit une disponibilité de 99,90 % pour les clusters qui n’utilisent pas de zones de disponibilité. AKS utilise des réplicas de nœud de plan de contrôle entre les domaines de mise à jour et d’erreur pour répondre aux exigences du 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. Vous devez également adopter un équilibreur de charge global, tel qu’Azure Traffic Manager ou Azure Front Door. Combinez l’équilibreur de charge avec une méthode de routage active/active ou active/passive pour garantir la continuité d’activité et la récupération d’urgence.

• Script, documentez et testez régulièrement tous les processus de basculement régionaux dans un environnement d’assurance qualité. Les processus de basculement permettent d’éviter des problèmes imprévisibles si une panne dans la région primaire affecte un service principal.

• Utilisez des tests de processus de basculement pour vérifier si l’approche de récupération d’urgence répond à l’objectif de point de récupération (RPO) et aux objectifs de délai de récupération (RTO). Incluez des processus manuels et des interventions dans votre vérification.

• Testez les procédures de restauration automatique pour vous assurer 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 Container Registry.

• Évitez de stocker l’état du service à l’intérieur d’un conteneur, le cas échéant. Utilisez plutôt un modèle PaaS Azure qui prend en charge la réplication multirégion.

• Préparez et testez comment migrer votre stockage de la région primaire vers la région de sauvegarde si vous utilisez Stockage Azure.

• Envisagez d’utiliser GitOps pour déployer la configuration du cluster. GitOps fournit une uniformité entre les clusters principaux et de récupération d’urgence et fournit également un moyen rapide de reconstruire un nouveau cluster si vous en perdez un.

• Envisagez la sauvegarde et la restauration de la configuration du cluster à l’aide d’outils, tels que la sauvegarde AKS ou Velero.

Maillage de services

• Envisagez d’utiliser un maillage de service open source, comme Istio, Linkerd ou Consul, dans votre cluster AKS. Un maillage de services utilise le protocole TLS mutuel pour améliorer l’observabilité, la fiabilité et la sécurité de vos microservices. Vous pouvez également implémenter des stratégies de fractionnement du trafic, telles que des déploiements bleu/vert et des déploiements canary. Un maillage de service est une couche d’infrastructure dédiée qui permet de rendre la communication de service à service plus sûre, rapide et fiable. Pour plus d’informations, consultez le module complémentaire AKS Istio Service Mesh.

• Envisagez d’adopter Dapr pour créer des applications basées sur des microservices résilientes, qu’elles soient sans état et avec état. Vous pouvez utiliser n’importe quel langage de programmation et infrastructure de développement.

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 en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

Les considérations relatives à la sécurité ne sont pas entièrement liées à l’architecture mutualisée dans AKS, mais elles sont essentielles à cette solution.

Mutualisation

• Concevez des clusters AKS pour l’architecture multi-locataire. Kubernetes fournit des fonctionnalités que vous pouvez utiliser pour isoler logiquement les équipes et les charges de travail dans le même cluster. Fournissez le moins de privilèges aux ressources dont chaque équipe a besoin. Un espace de noms dans Kubernetes crée une limite d’isolation logique.

• L’isolement logique permet de séparer des équipes et des projets. Réduisez le nombre de clusters AKS physiques que vous déployez pour isoler des équipes ou des applications. La séparation logique de clusters fournit généralement une densité de pods supérieure à celle résultant de l’isolement physique.

• Utilisez des pools de nœuds dédiés ou des clusters AKS dédiés chaque fois que vous devez implémenter un isolement physique strict. Par exemple, vous pouvez dédier un pool de nœuds Worker ou un cluster entier à une équipe ou à un locataire dans un environnement mutualisé.

  Utilisez une combinaison de teintes et de tolérances pour contrôler le déploiement de pods vers un pool de nœuds spécifique. Vous pouvez uniquement teinter un nœud dans AKS au moment de la création du pool de nœuds. Vous pouvez également utiliser des étiquettes et des sélecteurs nodePool pour déployer la charge de travail sur des pools de nœuds spécifiques uniquement.

Sécurité du réseau

• Créez un point de terminaison privé pour tout service PaaS que vos charges de travail AKS utilisent, comme Key Vault, Azure Service Bus ou Azure SQL Database. Un point de terminaison privé permet de s’assurer que le trafic entre les applications et ces services n’est pas exposé à l’Internet public. Pour plus d’informations, consultez What is Private Link.

• Configurez votre ressource d’entrée Kubernetes pour exposer des charges de travail via HTTPS. Utilisez un sous-domaine et un certificat numérique distincts pour chaque locataire. L’AGIC configure automatiquement l’écouteur Application Gateway pour l’arrêt SSL.

• Configurez Application Gateway pour utiliser une stratégie WAF pour protéger les charges de travail publiques qui s’exécutent sur AKS contre les attaques malveillantes.

• Utilisez la mise en réseau Azure CNI dans AKS pour intégrer des réseaux virtuels existants ou des réseaux locaux. Ce modèle réseau offre également une meilleure séparation des ressources et plus de contrôle dans un environnement d’entreprise.

• Utilisez des stratégies réseau pour séparer et sécuriser les communications intra-service 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 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. Pour plus d’informations, consultez Stratégie réseau.

• N'exposez pas de connectivité à distance sur vos nœuds AKS. Créez un hôte bastion ou un jumpbox dans un réseau virtuel de gestion. Utilisez l’hôte bastion pour acheminer le trafic en toute sécurité dans votre cluster AKS aux tâches de gestion à distance.

• Envisagez d’utiliser des plages d’adresses IP autorisées dans AKS pour créer un cluster AKS privé dans votre environnement de production. Si vous ne pouvez pas utiliser un cluster AKS privé, au moins un accès sécurisé au serveur d’API.

• Combinez Azure DDoS Protection avec les meilleures pratiques de conception d’application pour fournir des fonctionnalités d’atténuation DDoS améliorées et une défense supplémentaire contre les attaques DDoS. Activez la protection DDoS sur les réseaux virtuels de périmètre.

Authentification et autorisation

• Déployez des clusters AKS avec l’intégration Microsoft Entra. Pour obtenir plus d’informations, consultez Intégration Microsoft Entra gérée par AKS. Microsoft Entra ID centralise le composant de gestion des identités.

• Utilisez le RBAC Kubernetes pour définir les autorisations dont disposent les utilisateurs ou les groupes sur les ressources du cluster. Utilisez des rôles ou clusterRoles et des liaisons pour étendre les utilisateurs ou les groupes au moins de nombre d’autorisations nécessaires. Intégrez Kubernetes RBAC à l’ID Microsoft Entra afin que toute modification de l’état de l’utilisateur ou de l’appartenance au groupe met automatiquement à jour l’accès aux ressources du cluster. Pour plus d’informations, consultez RBAC Kubernetes.

• Utilisez Azure RBAC pour définir les autorisations minimales requises dont disposent les utilisateurs ou les groupes pour les ressources AKS dans un ou plusieurs abonnements. Pour plus d’informations, consultez Utiliser Azure RBAC pour l’autorisation Kubernetes.

• Utilisez ID de charge de travail Microsoft Entra pour affecter une identité managée à des microservices individuels pour l’accès aux ressources Azure. Le microservice peut ensuite accéder aux ressources managées, telles que Key Vault, SQL Database, Service Bus et Azure Cosmos DB. Le microservice n’a pas besoin de stocker et de récupérer des informations d’identification ou des chaîne de connexion à partir de secrets Kubernetes.

• Utilisez le pilote CSI du magasin de secrets pour Key Vault pour accéder aux secrets, tels que les informations d’identification et la chaîne de connexions, à partir de Key Vault plutôt que des secrets Kubernetes.

• Combinez le bloc de construction du magasin de secrets Dapr avec le magasin Key Vault et les identités managées sur Kubernetes pour récupérer des secrets, tels que des informations d’identification et des chaîne de connexion, à partir de Key Vault.

Charge de travail et cluster

• Sécurisez l’accès au serveur d’API Kubernetes pour sécuriser votre cluster. Intégrez Kubernetes RBAC à l’ID Microsoft Entra pour contrôler l’accès au serveur d’API. Utilisez ces contrôles pour sécuriser AKS de la même façon que pour l’accès aux abonnements Azure.

• Limitez l’accès aux actions que les conteneurs peuvent effectuer. Utilisez la fonctionnalité d’admission de sécurité des pods pour activer l’autorisation affinée de la création et des mises à jour des pods. Fournissez le plus petit nombre d’autorisations et évitez d’utiliser l’élévation des privilèges or de racine. Pour plus d’informations, consultez Sécuriser l’accès des pods aux ressources.

• Évitez d’exécuter des conteneurs en tant qu’utilisateur racine dans la mesure du possible.

• Le module de sécurité du noyau Linux AppArmor permet de limiter les actions que les conteneurs peuvent effectuer.

• Mettez régulièrement à niveau vos clusters AKS vers la dernière version de Kubernetes pour tirer parti des nouvelles fonctionnalités et des correctifs de bogues.

• Utilisez le daemonset kured pour surveiller les redémarrages en attente, le cordon et les nœuds de drainage, et appliquer des mises à jour. AKS télécharge et installe automatiquement les correctifs de sécurité sur chaque nœud Linux, mais ne redémarre pas automatiquement le nœud si nécessaire. Pour les nœuds Windows Server, effectuez régulièrement une opération de mise à niveau AKS pour isoler et drainer les pods de façon sécurisée, et pour déployer les nœuds mis à jour.

• Envisagez d’utiliser des protocoles de transport sécurisé HTTPS et gRPC pour toutes les communications intra-pods. Et utilisez un mécanisme d’authentification plus avancé qui ne vous oblige pas à envoyer les informations d’identification simples sur chaque requête, comme Open Authorization (OAuth) ou JSON Web Tokens (JWTs). Établissez une communication intra-service plus sécurisée à l’aide d’un maillage de service, comme Istio, Linkerd ou Consul. Vous pouvez également utiliser Dapr.

Registre de conteneurs

Analysez vos images conteneur pour détecter les vulnérabilités et déployez uniquement des images qui réussissent la validation. Mettez régulièrement à jour les images de base et le runtime de l’application. Redéployez ensuite des charges de travail dans le cluster AKS. Votre flux de travail de déploiement CI/CD doit inclure un processus d’analyse des images conteneur. Vous pouvez utiliser Microsoft Defender pour la sécurité DevOps pour analyser le code pour détecter les vulnérabilités dans vos pipelines automatisés pendant les phases de génération et de déploiement. Vous pouvez également utiliser des outils tels que Prisma Cloud ou Aqua pour analyser et autoriser uniquement les images vérifiées à déployer.

Optimisation des coûts

L’optimisation des coûts consiste à examiner 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.

Le coût de cette architecture dépend des aspects de configuration, tels que les composants suivants :

• Niveaux de service
• Scalabilité ou nombre d’instances que les services allouent dynamiquement pour prendre en charge une demande donnée
• Scripts d’automatisation
• votre niveau de récupération d’urgence.

Après avoir évalué ces aspects, utilisez la calculatrice de prix Azure pour estimer vos coûts. Pour plus d’informations, consultez les principes de l’infrastructure bien architected de l’optimisation des coûts.

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.

Stockage

• Envisagez de déployer votre cluster AKS avec des disques de système d’exploitation éphémères qui fournissent une latence de lecture et d’écriture inférieure, ainsi que des mises à niveau de nœud et de cluster plus rapides.

• Comprendre les besoins de votre application pour choisir le stockage approprié. Utilisez un stockage ssd hautes performances pour les charges de travail de production. Planifiez un système de stockage basé sur le réseau, tel qu’Azure Files, lorsque plusieurs pods doivent accéder simultanément aux mêmes fichiers. Pour plus d’informations, consultez Options de stockage pour les applications dans AKS.

• Planifiez les demandes de votre application afin de déployer la taille appropriée des nœuds. Chaque taille de nœud prend en charge un nombre maximal de disques. Différentes tailles de nœud fournissent également des quantités différentes de stockage local et de bande passante de réseau.

• Optez pour un approvisionnement dynamique. Pour réduire la surcharge de gestion et activer la mise à l’échelle, ne créez pas et affectez statiquement des volumes persistants. Dans vos classes de stockage, définissez la stratégie de récupération appropriée pour réduire les coûts de stockage inutiles après la suppression des pods.

DevOps

• Utilisez un système DevOps, tel que GitHub Actions ou Azure DevOps, pour déployer vos charges de travail sur AKS via un graphique Helm dans un pipeline CI/CD. Pour plus d’informations, consultez Générer et déployer sur AKS.

• Introduisez les déploiements A/B test et canary dans la gestion du cycle de vie de votre application pour tester correctement une application avant de l’introduire à tous les utilisateurs. Vous pouvez utiliser plusieurs techniques pour fractionner le trafic entre les différentes versions du même service.

• En guise d’alternative, vous pouvez utiliser les fonctionnalités de gestion du trafic qu’offre un maillage de service. Pour plus d’informations, consultez La gestion du trafic Istio.

• Utilisez Container Registry ou un autre magasin de registre, comme Docker Hub, pour cataloguer et traiter les images Docker privées que vous déployez sur le cluster. AKS peut utiliser son identité Microsoft Entra pour s’authentifier auprès de Container Registry.

• Si vous devez modifier les paramètres sur Application Gateway, apportez la modification à l’aide de la configuration exposée sur le contrôleur d’entrée ou d’autres objets Kubernetes, tels que l’utilisation d’annotations prises en charge. Après avoir lié une passerelle d’application à l’AGIC, le contrôleur d’entrée synchronise et contrôle presque toutes les configurations de cette passerelle. Si vous configurez directement Application Gateway de manière impérative ou via l’infrastructure en tant que code, le contrôleur d’entrée remplace finalement ces modifications.

Surveillance

• Envisagez les options de supervision intégrées à Azure pour surveiller l’état d’intégrité du cluster AKS et des charges de travail.

• Configurez tous les services PaaS, tels que Container Registry et Key Vault, pour collecter les journaux de diagnostic et les métriques et les envoyer à Log Analytics.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

Les considérations relatives aux performances ne sont pas entièrement liées à l’architecture mutualisée dans AKS, mais elles sont essentielles à cette solution :

• Pour les charges de travail à faible latence, envisagez de déployer un pool de nœuds dédié dans un groupe de placement de proximité. Lorsque vous déployez votre application dans Azure, les instances de machine virtuelle réparties entre les régions ou les zones de disponibilité créent une latence réseau, ce qui peut affecter les performances globales de votre application. Un groupe de placement de proximité est un regroupement logique que vous pouvez utiliser pour vous assurer que les ressources de calcul Azure se trouvent physiquement à proximité les unes des autres. Certains cas d’usage, tels que les jeux, les simulations d’ingénierie et les transactions à haute fréquence, nécessitent une faible latence et des tâches qui se terminent rapidement. Pour les scénarios de calcul hautes performances tels que ceux-ci, envisagez d’utiliser des groupes de placement de proximité pour les pools de nœuds de votre cluster.

• Utilisez toujours des images conteneur plus petites, car vous pouvez créer des builds plus rapides. Les images plus petites sont également moins vulnérables aux vecteurs d’attaque en raison d’une surface d’attaque réduite.

• Utilisez la mise à l’échelle automatique Kubernetes pour effectuer un scale-out dynamique du nombre de nœuds Worker dans un cluster AKS lorsque le trafic augmente. Avec l’autoscaler de pod horizontal et un autoscaler de cluster, les volumes de nœuds et de pods sont ajustés dynamiquement en temps réel pour correspondre à la condition de trafic et éviter les temps d’arrêt qui provoquent des problèmes de capacité. Pour plus d’informations, consultez Utiliser l’autoscaler de cluster dans AKS.

Planificateur

• Passez en revue et implémentez les meilleures pratiques pour les opérateurs de cluster et les développeurs d’applications pour générer et exécuter des applications avec succès sur AKS.

• Planifiez et appliquez des quotas de ressources au niveau de l’espace de noms pour tous les espaces de noms. Si les pods ne définissent pas de demandes ni de limites de ressources, rejetez le déploiement. Supervisez l’utilisation des ressources, puis ajustez les quotas en fonction des besoins. Lorsque plusieurs équipes ou locataires partagent un cluster AKS qui a un nombre fixe de nœuds, vous pouvez utiliser des quotas de ressources pour affecter un partage équitable de ressources à chaque équipe ou locataire.

• Adoptez des plages de limites pour limiter les allocations de ressources aux pods ou conteneurs d’un espace de noms, en termes d’UC et de mémoire.

• Définissez explicitement les demandes et limites de ressources pour l’utilisation du processeur et de la mémoire pour vos pods dans les manifestes YAML ou les graphiques Helm que vous utilisez pour déployer des applications. Lorsque vous spécifiez la requête de ressource pour les conteneurs dans un pod, le planificateur Kubernetes utilise ces informations pour déterminer le nœud sur lequel placer le pod. Lorsque vous spécifiez une limite de ressources pour un conteneur, par exemple l’UC ou la mémoire, kubelet applique ces limites afin que le conteneur en cours d’exécution ne puisse pas utiliser plus de cette ressource que la limite que vous définissez.

• Maintenez la disponibilité des applications en définissant des budgets d’interruption de pod pour vous assurer qu’un nombre minimal de pods sont disponibles dans le cluster.

• Utilisez des classes de priorité pour indiquer l’importance d’un pod. Si le planificateur ne peut pas planifier un pod, il tente de préemptiser ou de supprimer des pods de priorité inférieure afin qu’il puisse planifier le pod en attente.

• Utilisez des teintes Kubernetes et des tolérances pour placer des applications gourmandes en ressources sur des nœuds spécifiques et pour éviter les problèmes de voisin bruyants. Conservez les ressources de nœud disponibles pour les charges de travail qui en ont besoin. N’autorisez pas d’autres charges de travail à planifier sur les nœuds.

• Utilisez des sélecteurs de nœuds, une affinité de nœud ou une affinité entre pods pour contrôler la planification des pods sur les nœuds. Utilisez les paramètres d’affinité entre pods et d’anti-affinité pour colocaliser des pods qui ont des communications chatteuse, pour placer des pods sur différents nœuds et éviter d’exécuter plusieurs instances du même type de pod sur le même nœud.

Déployer ce scénario

Le code source de ce scénario est disponible sur GitHub. Le diagramme suivant montre une application de démonstration que vous pouvez trouver dans le référentiel GitHub AGIC multilocataire AKS.

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

Prérequis

Pour les déploiements en ligne, vous devez disposer d’un compte Azure existant. Si vous n’en avez pas, créez un compte Azure gratuit avant de commencer.

Déployer dans Azure

1. Vérifiez que vos informations d’abonnement Azure sont accessibles.

2. Clonez le référentiel GitHub du workbench :

   git clone https://github.com/Azure-Samples/aks-agic.git
   

3. 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

• Bonnes pratiques relatives aux clusters AKS
• Bonnes pratiques relatives aux fonctionnalités basiques du planificateur dans AKS
• Créer un cluster AKS privé
• Créer des stratégies WAF pour Application Gateway
• Différence entre un déploiement Helm et le module complémentaire AKS
• Fonctionnement d’une passerelle applicative

Ressources associées

• Architecture de référence pour un cluster AKS

Cette solution utilise le pare-feu d’applications web Azure (WAF) pour fournir une protection centralisée pour les applications web que vous déployez sur un cluster Azure Kubernetes Service (AKS) mutualisé. WAF permet de protéger contre les attaques et les vulnérabilités courantes.

Vous pouvez utiliser une stratégie WAF sur Azure Application Gateway pour protéger les applications web contre les attaques malveillantes, telles que l’injection SQL et les scripts intersites. Cette méthode permet de protéger les applications web qui s’exécutent sur un cluster AKS et sont exposées via le contrôleur d’entrée Application Gateway (AGIC). La stratégie WAF sur Application Gateway est préconfigurée avec l’ensemble de règles OWASP (Open Worldwide Application Security Project) Core Rule Set (CRS) et prend en charge d’autres versions OWASP CRS. Vous pouvez également créer des règles personnalisées.

Architecture

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

Flux de travail

• Cette architecture utilise un modèle Azure Resource Manager complémentaire (modèle ARM) pour déployer un nouveau réseau virtuel avec quatre sous-réseaux :

  • AksSubnet héberge le cluster AKS.
  • VmSubnet héberge une machine virtuelle jumpbox et des points de terminaison privés.
  • AppGatewaySubnet héberge le niveau WAF2 Application Gateway.
  • AzureBastionSubnet héberge Azure Bastion.

• Le cluster AKS utilise une identité managée définie par l’utilisateur pour créer davantage de ressources, telles que des équilibreurs de charge et des disques managés, dans Azure. Vous pouvez utiliser le modèle ARM pour déployer un cluster AKS avec les fonctionnalités suivantes :

  • Pilotes CSI (Container Stockage Interface) pour les disques Azure et Azure Files
  • Intégration Microsoft Entra gérée par AKS
  • Contrôle d'accès Azure basé sur les rôles (RBAC) pour l'autorisation Kubernetes
  • Une identité managée à la place d’un principal de service
  • ID de charge de travail Microsoft Entra
  • Stratégies réseau Azure
  • Module complémentaire des insights de conteneur Azure Monitor
  • Module complémentaire AGIC
  • Allocation dynamique d’adresses IP et prise en charge améliorée du sous-réseau

• Le cluster AKS possède les pools de nœuds suivants :

  • Le pool de nœuds système héberge uniquement les pods et services système critiques. Les nœuds Worker ont une teinte de nœud qui empêche les pods d’application d’être planifiés sur ce pool de nœuds.
  • Le pool de nœuds utilisateur héberge les charges de travail et les artefacts des utilisateurs.

• Une machine virtuelle est déployée dans le même réseau virtuel que celui 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 fournit une connectivité SECURE Shell (SSH) sécurisée et transparente à la machine virtuelle jumpbox, directement dans le Portail Azure via SSL (Secure Sockets Layer). Cette solution utilise Azure Container Registry pour générer, stocker et gérer des images et artefacts conteneur, tels que des graphiques Helm.

• L’architecture inclut une passerelle d’application que le contrôleur d’entrée utilise. La passerelle d’application est déployée sur un sous-réseau dédié et exposée à l’Internet public via une adresse IP publique que partagent toutes les charges de travail de locataire. Une stratégie WAF permet de protéger les charges de travail des locataires contre les attaques malveillantes.

  La stratégie WAF est associée à la passerelle Application Gateway au niveau racine et au niveau de l’écouteur HTTP. La stratégie est configurée en mode de prévention et utilise OWASP 3.1 pour bloquer les intrusions et les attaques détectées par les règles. L’attaquant reçoit une exception d’accès non autorisé 403 et la connexion est fermée. Le mode de prévention enregistre ces attaques dans les journaux WAF.

• Les charges de travail qui s’exécutent sur AKS utilisent un coffre de clés comme magasin de clés pour récupérer des clés, des certificats et des secrets via une bibliothèque cliente, un pilote CSI du magasin de secrets ou Dapr. Azure Private Link permet aux charges de travail AKS d’accéder aux solutions PaaS (Platform as a Service) Azure, telles qu’Azure Key Vault, sur un point de terminaison privé dans le réseau virtuel.

• Cette architecture inclut des points de terminaison privés aux composants suivants :

  • Compte Stockage Blob Azure
  • Registre de conteneurs
  • Coffre-fort de clés
  • Serveur d’API du cluster Kubernetes, si vous utilisez un cluster AKS privé

• L’architecture inclut également des zones DNS privées pour résoudre le nom de domaine complet (FQDN) d’un service PaaS vers l’adresse IP privée de son point de terminaison privé associé. Cette architecture inclut des zones DNS privées pour résoudre les points de terminaison privés vers les composants suivants :

  • Compte de stockage d’objets blob
  • Registre de conteneurs
  • Coffre-fort de clés
  • L’API du serveur Kubernetes, si vous déployez le cluster en tant que privé

• Une liaison de réseau virtuel existe entre le réseau virtuel qui héberge le cluster AKS et les zones DNS privées précédentes. Un espace de travail Log Analytics collecte les journaux de diagnostic et les métriques à partir des sources suivantes :

  • Le cluster AKS
  • Machine virtuelle jumpbox
  • Application Gateway
  • Coffre-fort de clés
  • Groupes de sécurité réseau Azure

Composants

• 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. Vous pouvez également utiliser des tâches Container Registry pour générer des images conteneur dans Azure. Vous pouvez générer à la demande ou automatiser entièrement des builds avec des déclencheurs, tels que des validations de code source et des mises à jour d’images de base.

• AKS simplifie le déploiement d’un cluster Kubernetes managé 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 l’analyse de l’intégrité et la maintenance. Azure gère les nœuds du plan de contrôle Kubernetes, de sorte que vous gérez et gérez uniquement les nœuds de l’agent.

• Key Vault permet de stocker et de contrôler en toute sécurité l’accès aux secrets, tels que les clés API, les mots de passe, les certificats et les clés de chiffrement. Vous pouvez utiliser Key Vault pour provisionner, gérer et déployer facilement des certificats TLS ou SSL (Transport Layer Security) publics et privés, et les utiliser avec Azure et vos ressources connectées internes.

• Application Gateway est un équilibreur de charge de trafic web que vous pouvez utiliser pour gérer le trafic entrant qui passe aux applications web en aval et aux API REST. Les équilibreurs de charge traditionnels fonctionnent au niveau de la couche de transport, qui est open Systems Interconnexion (OSI) couche 4, pour gérer le trafic qui utilise tcp (Transmission Control Protocol) et UDP (User Datagram Protocol). Ils acheminent le trafic en fonction de l’adresse IP et du port source vers une adresse IP et un port de destination. Une passerelle d’application est un équilibreur de charge au niveau de la couche application, qui est la couche OSI 7.

• WAF est un service qui permet de fournir une protection centralisée des applications web contre les attaques et vulnérabilités courantes. WAF est basé sur des règles du CRS OWASP. Vous pouvez utiliser WAF pour créer des règles personnalisées évaluées pour chaque requête qui passe par une stratégie. Ces règles ont une priorité plus élevée que les autres règles des ensembles de règles gérés. Les règles personnalisées contiennent un nom de règle, une priorité de règle et un tableau des conditions de correspondance. Si la demande répond à ces conditions, WAF autorise ou bloque la requête en fonction de la règle.

• Azure Bastion est un service PaaS complètement managé que vous approvisionnez au sein de votre réseau virtuel. Azure Bastion permet de fournir une connectivité RDP (Remote Desktop Protocol) sécurisée et transparente aux machines virtuelles de votre réseau virtuel, directement à partir du Portail Azure via TLS.

• Azure Machines Virtuelles fournit des ressources informatiques évolutives à la demande qui vous offrent la flexibilité de la virtualisation sans avoir à acheter et à maintenir le matériel physique.

• Le réseau virtuel Azure est le bloc de construction fondamental pour vos réseaux privés Azure. Avec Réseau virtuel, les ressources Azure, telles que les machines virtuelles, peuvent communiquer entre elles, internet et réseaux locaux de manière plus sécurisée. Le réseau virtuel Azure est similaire à un réseau traditionnel local, mais il inclut les avantages de l’infrastructure Azure, tels que la scalabilité, la disponibilité et l’isolement.

• Les interfaces de réseau virtuel permettent d’établir la communication entre les machines virtuelles Azure et Internet, Azure et les ressources 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 sont des volumes de stockage au niveau du bloc qu’Azure gère sur des machines virtuelles Azure. Les types de disques incluent stockage sur disque Azure Ultra, SSD Azure Premium, SSD Azure Standard et HDD Azure Standard.

• Le stockage Blob est une solution de stockage d’objets Microsoft pour le cloud. Stockage Blob est optimisé pour stocker des quantités massives de données non structurées. Les données non structurées sont des données qui ne respectent pas un modèle de données ou une définition particulier, telles que des données texte ou des données binaires.

• Private Link fournit un point de terminaison privé dans votre réseau virtuel afin de pouvoir accéder aux services PaaS Azure, tels que Stockage Blob et Key Vault, et accéder aux services hébergés par Azure, appartenant au client ou aux services partenaires.

Autres solutions

Lorsque vous exposez des charges de travail que vous hébergez dans un cluster AKS, vous avez plusieurs solutions à prendre en compte. Au lieu d’utiliser L’AGIC, vous pouvez utiliser Application Gateway pour conteneurs ou l’entrée NGINX gérée avec le module complémentaire de routage d’application. Ces alternatives offrent différentes fonctionnalités pour aider à gérer et sécuriser le trafic vers votre cluster AKS.

Cette architecture installe AGIC via le module complémentaire AGIC pour AKS. Vous pouvez également installer L’AGIC via un graphique Helm. Lorsque vous créez une configuration, vous pouvez utiliser une ligne dans Azure CLI pour déployer une nouvelle passerelle d’application et un nouveau cluster AKS. Cette méthode active AGIC en tant que module complémentaire. Le module complémentaire est un service entièrement géré, qui offre des avantages supplémentaires, tels que les mises à jour automatiques et une prise en charge accrue. Il est également considéré comme un module complémentaire de première classe, qui offre une meilleure intégration à AKS. Microsoft prend en charge les deux méthodes de déploiement pour L’AGIC.

Le module complémentaire AGIC est déployé en tant que pod dans votre cluster AKS. Toutefois, il existe quelques différences entre la version du déploiement Helm et la version du module complémentaire de l’AGIC. La liste suivante présente les différences entre les deux versions :

• Vous ne pouvez pas modifier les valeurs de déploiement Helm sur le module complémentaire AKS :

  • La propriété usePrivateIp est définie sur false par défaut. Vous ne pouvez pas remplacer cette valeur par le biais de l’annotation use-private-ip .
  • Le module complémentaire ne prend pas en charge l’option shared de configuration.

• L’AGIC déployé par Helm prend en charge ProhibitedTargets, ce qui signifie que l’AGIC peut configurer la passerelle d’application spécifiquement pour les clusters AKS sans affecter d’autres back-ends existants.

• Le module complémentaire AGIC est un service managé. Il est donc automatiquement mis à jour vers la dernière version. Si vous déployez L’AGIC via Helm, vous devez mettre à jour manuellement l’AGIC.

• Vous ne pouvez déployer qu’un seul module complémentaire AGIC pour chaque cluster AKS. Chaque module complémentaire AGIC ne peut cibler qu’une seule instance Application Gateway. Pour les déploiements qui nécessitent plusieurs AGIC pour chaque cluster ou plusieurs GIC qui ciblent une instance Application Gateway, vous pouvez utiliser l’AGIC déployé par Helm.

Une seule instance de l’AGIC peut ingérer des événements à partir de plusieurs espaces de noms Kubernetes. Si l’administrateur AKS utilise la passerelle d’application comme entrée, tous les espaces de noms utilisent la même instance d’Application Gateway. Une seule installation de L’AGIC surveille les espaces de noms accessibles et configure la passerelle d’application à laquelle elle est associée. Pour plus d’informations, consultez Activer la prise en charge de plusieurs espaces de noms dans un cluster AKS avec l’AGIC.

Pour activer la prise en charge de plusieurs espaces de noms, procédez comme suit :

1. Modifiez le fichier helm-config.yaml de l’une des manières suivantes :

• Supprimez entièrement la watchNamespace clé du fichier helm-config.yaml pour permettre à l’AGIC d’observer tous les espaces de noms.
• Définissez watchNamespace sur une chaîne vide pour permettre à l’AGIC d’observer tous les espaces de noms.
• Ajoutez plusieurs espaces de noms séparés par une virgule, par exemple watchNamespace: default,secondNamespace, pour permettre à l’AGIC d’observer ces espaces de noms exclusivement.

2. Appliquer des modifications de modèle Helm avec ce script : helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure.

Après avoir déployé L’AGIC avec la possibilité d’observer plusieurs espaces de noms, l’AGIC effectue les actions suivantes :

1. Répertorie les ressources d’entrée de tous les espaces de noms accessibles
2. Filtre les ressources d’entrée qui sont annotées avec kubernetes.io/ingress.class: azure/application-gateway
3. Compose la configuration d’Application Gateway combinée
4. Applique la configuration à la passerelle d’application associée via Azure Resource Manager

Détails du scénario

Cette architecture partage un cluster Kubernetes mutualisé entre plusieurs utilisateurs et charges de travail communément appelés locataires. Cette définition inclut différentes équipes ou divisions au sein d’une organisation qui partagent des clusters Kubernetes. Il inclut également des clusters partagés par les instances par client d’une application SaaS (Software as a Service). L’architecture multi-locataire de cluster est une alternative à la gestion de nombreux clusters dédiés à un seul locataire. Les opérateurs d’un cluster Kubernetes mutualisés doivent isoler les locataires les uns des autres. Cette isolation réduit les dommages qu’un locataire compromis ou malveillant peut causer au cluster et à d’autres locataires. Lorsque plusieurs utilisateurs ou équipes partagent le même cluster avec un nombre fixe de nœuds, une équipe peut utiliser plus de ressources que nécessaire. Les administrateurs peuvent utiliser des quotas de ressources pour résoudre ce problème.

Lorsque vous envisagez de créer un cluster AKS multilocataire, vous devez prendre en compte les couches d’isolation des ressources que Kubernetes fournit, notamment le cluster, l’espace de noms, le nœud, le pod et l’isolation de conteneur. Vous devez également prendre en compte les implications en matière de sécurité du partage de différents types de ressources entre plusieurs locataires. Par exemple, si vous planifiez des pods à partir de différents locataires sur le même nœud, vous pouvez réduire le nombre d’ordinateurs dont vous avez besoin dans le cluster. En revanche, vous devrez peut-être empêcher certaines charges de travail d’être colocalisées. Par exemple, vous pourriez ne pas autoriser l'exécution de code non fiable provenant de l'extérieur de votre organisation sur le même nœud que les conteneurs qui traitent des informations sensibles. Vous pouvez utiliser Azure Policy pour que seuls les registres approuvés puissent être déployés sur AKS.

Kubernetes ne peut pas garantir une isolation parfaitement sécurisée entre les locataires, mais elle offre des fonctionnalités qui fournissent une sécurité suffisante pour des cas d’usage spécifiques. En guise de meilleure pratique, vous devez séparer chaque locataire et ses ressources Kubernetes dans leurs propres espaces de noms. Vous pouvez ensuite utiliser le RBAC Kubernetes et les stratégies réseau pour aider à appliquer l’isolation des locataires. Par exemple, le diagramme suivant montre un modèle de fournisseur SaaS classique qui héberge plusieurs instances de la même application sur le même cluster, un pour chaque locataire. Chaque application se trouve dans un espace de noms distinct. Lorsque les locataires ont besoin d’un niveau plus élevé d’isolation physique et de performances garanties, leurs charges de travail peuvent être déployées sur un ensemble dédié de nœuds, un pool dédié ou même un cluster dédié.

L’AGIC est une application Kubernetes, de sorte que les clients AKS peuvent utiliser une passerelle d’application pour exposer leurs applications conteneurisées à Internet. L’AGIC surveille le cluster Kubernetes sur lequel il est hébergé et met à jour en permanence une passerelle d’application afin que les services sélectionnés soient exposés à Internet. L’AGIC s’exécute dans son propre pod sur l’instance AKS du client. L’AGIC surveille un sous-ensemble de ressources Kubernetes pour les modifications. L’état du cluster AKS est traduit en configuration spécifique à Application Gateway et appliqué à Resource Manager. Cette architecture décrit les pratiques éprouvées pour déployer un cluster AKS public ou privé via une passerelle d’application et un module complémentaire AGIC.

Une seule instance de l’AGIC peut ingérer des événements à partir de plusieurs espaces de noms et y observer. Si l’administrateur AKS utilise Application Gateway comme entrée, tous les espaces de noms utilisent la même instance d’Application Gateway. Une seule installation d’AGIC surveille les espaces de noms accessibles et configure la passerelle d’application à laquelle elle est associée.

Cas d’usage potentiels

Utilisez AGIC pour exposer et protéger des charges de travail accessibles sur Internet qui s’exécutent sur un cluster AKS dans un environnement multilocataire.

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 de ces considérations ne concernent pas entièrement l’architecture multilocataire dans AKS, mais elles sont essentielles à cette solution. Ces considérations incluent la sécurité, les performances, la disponibilité, la fiabilité, le stockage, le planificateur, le maillage de service et les conseils de surveillance.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

Ces considérations relatives à la disponibilité et à la fiabilité ne sont pas entièrement liées à l’architecture mutualisée dans AKS, mais elles sont essentielles à cette solution. Tenez compte des méthodes suivantes pour optimiser la disponibilité de votre cluster AKS et de vos charges de travail.

Conteneurs

• Les sondes d’intégrité Kubernetes permettent de vérifier que vos conteneurs sont actifs et sains :

  • LivenessProbe indique si le conteneur est en cours d’exécution. Si la sonde liveness échoue, le kubelet met fin au conteneur et le conteneur est soumis à sa stratégie de redémarrage.

  • readinessProbe indique si le conteneur est prêt à répondre aux requêtes. Si la sonde de préparation échoue, le contrôleur de point de terminaison supprime l’adresse IP du pod des points de terminaison de tous les services qui correspondent au pod. État de préparation par défaut avant l’échec du délai initial.

  • Le startupProbe indique si l’application au sein du conteneur est démarrée. Si vous disposez d’une sonde de démarrage, toutes les autres sondes sont désactivées jusqu’à ce que la sonde de démarrage réussisse. Si la sonde de démarrage échoue, kubelet met fin au conteneur et le conteneur est soumis à sa stratégie de redémarrage.

• La contention de ressources est susceptible d’affecter la disponibilité du service. Définissez des contraintes de ressources de conteneurs pour éviter qu’un seul conteneur ne surcharge les ressources de mémoire et de CPU de cluster. Vous pouvez utiliser les diagnostics AKS pour identifier les problèmes dans le cluster.

• Utilisez la limite de ressources pour limiter le nombre total de ressources allouées à un conteneur afin qu’un conteneur ne puisse pas priver d’autres personnes.

Registre de conteneurs

• Stockez des images conteneur dans Container Registry. Utilisez la géoréplication container Registry pour géorépliquer le registre dans chaque région AKS. La géoréplication est une fonctionnalité du registre de conteneurs de référence SKU Premium.

• Analysez vos images conteneur pour détecter les vulnérabilités. Déployez uniquement des images qui passent la validation. Mettez régulièrement à jour les images de base et le runtime de l’application, puis redéployez vos charges de travail dans le cluster AKS.

• Limitez les registres d’images que les pods et déploiements peuvent utiliser. Limitez l’accès aux registres approuvés dans lesquels vous pouvez valider et contrôler les images disponibles.

• Analysez les images conteneur pour détecter les vulnérabilités dans le cadre d’un pipeline d’intégration continue et de livraison continue (CI/CD) avant de publier des images dans Container Registry. Lorsque vous utilisez des images de base pour les images d’application, utilisez l’automatisation pour générer de nouvelles images lorsque vous mettez à jour l’image de base. Les images de base incluent généralement des correctifs de sécurité. Vous devez donc mettre à jour les images conteneur d’applications en aval. Nous vous recommandons d’intégrer Microsoft Defender pour conteneurs dans des flux de travail CI/CD. Pour plus d’informations, consultez Automatiser les builds d’images conteneur.

• Utilisez les tâches Container Registry pour automatiser la mise à jour corrective du système d’exploitation et de l’infrastructure pour vos conteneurs Docker. Les tâches container Registry prennent en charge un processus de génération automatisé lorsque vous mettez à jour l’image de base d’un conteneur. Par exemple, vous pouvez corriger le système d’exploitation ou l’infrastructure d’application dans l’une de vos images de base.

Résilience entre les régions

• Envisagez de déployer les pools de nœuds de votre cluster AKS sur toutes les zones de disponibilité d’une région. Utilisez Azure Standard Load Balancer ou Application Gateway devant vos pools de nœuds. Cette topologie offre une meilleure résilience si une panne de centre de données unique se produit. Cette méthode distribue les nœuds de cluster entre plusieurs centres de données qui résident 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 des contraintes de répartition de topologie de pod pour contrôler la façon dont vous répartissez des pods sur votre cluster AKS entre des domaines d’échec, tels que des régions, des zones de disponibilité et des nœuds.

• Envisagez d’utiliser un contrat de niveau de service de temps d’activité (SLA) pour les clusters AKS qui hébergent des charges de travail stratégiques. Un contrat SLA de temps d’activité est une fonctionnalité facultative permettant d’activer un contrat SLA financièrement soutenu, plus élevé pour un cluster. Un contrat SLA de temps d’activité garantit une disponibilité de 99,95 % du point de terminaison du serveur d’API Kubernetes pour les clusters qui utilisent des zones de disponibilité. Il garantit une disponibilité de 99,90 % pour les clusters qui n’utilisent pas de zones de disponibilité. AKS utilise des réplicas de nœud de plan de contrôle entre les domaines de mise à jour et d’erreur pour répondre aux exigences du 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. Vous devez également adopter un équilibreur de charge global, tel qu’Azure Traffic Manager ou Azure Front Door. Combinez l’équilibreur de charge avec une méthode de routage active/active ou active/passive pour garantir la continuité d’activité et la récupération d’urgence.

• Script, documentez et testez régulièrement tous les processus de basculement régionaux dans un environnement d’assurance qualité. Les processus de basculement permettent d’éviter des problèmes imprévisibles si une panne dans la région primaire affecte un service principal.

• Utilisez des tests de processus de basculement pour vérifier si l’approche de récupération d’urgence répond à l’objectif de point de récupération (RPO) et aux objectifs de délai de récupération (RTO). Incluez des processus manuels et des interventions dans votre vérification.

• Testez les procédures de restauration automatique pour vous assurer 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 Container Registry.

• Évitez de stocker l’état du service à l’intérieur d’un conteneur, le cas échéant. Utilisez plutôt un modèle PaaS Azure qui prend en charge la réplication multirégion.

• Préparez et testez comment migrer votre stockage de la région primaire vers la région de sauvegarde si vous utilisez Stockage Azure.

• Envisagez d’utiliser GitOps pour déployer la configuration du cluster. GitOps fournit une uniformité entre les clusters principaux et de récupération d’urgence et fournit également un moyen rapide de reconstruire un nouveau cluster si vous en perdez un.

• Envisagez la sauvegarde et la restauration de la configuration du cluster à l’aide d’outils, tels que la sauvegarde AKS ou Velero.

Maillage de services

• Envisagez d’utiliser un maillage de service open source, comme Istio, Linkerd ou Consul, dans votre cluster AKS. Un maillage de services utilise le protocole TLS mutuel pour améliorer l’observabilité, la fiabilité et la sécurité de vos microservices. Vous pouvez également implémenter des stratégies de fractionnement du trafic, telles que des déploiements bleu/vert et des déploiements canary. Un maillage de service est une couche d’infrastructure dédiée qui permet de rendre la communication de service à service plus sûre, rapide et fiable. Pour plus d’informations, consultez le module complémentaire AKS Istio Service Mesh.

• Envisagez d’adopter Dapr pour créer des applications basées sur des microservices résilientes, qu’elles soient sans état et avec état. Vous pouvez utiliser n’importe quel langage de programmation et infrastructure de développement.

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 en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

Les considérations relatives à la sécurité ne sont pas entièrement liées à l’architecture mutualisée dans AKS, mais elles sont essentielles à cette solution.

Mutualisation

• Concevez des clusters AKS pour l’architecture multi-locataire. Kubernetes fournit des fonctionnalités que vous pouvez utiliser pour isoler logiquement les équipes et les charges de travail dans le même cluster. Fournissez le moins de privilèges aux ressources dont chaque équipe a besoin. Un espace de noms dans Kubernetes crée une limite d’isolation logique.

• L’isolement logique permet de séparer des équipes et des projets. Réduisez le nombre de clusters AKS physiques que vous déployez pour isoler des équipes ou des applications. La séparation logique de clusters fournit généralement une densité de pods supérieure à celle résultant de l’isolement physique.

• Utilisez des pools de nœuds dédiés ou des clusters AKS dédiés chaque fois que vous devez implémenter un isolement physique strict. Par exemple, vous pouvez dédier un pool de nœuds Worker ou un cluster entier à une équipe ou à un locataire dans un environnement mutualisé.

  Utilisez une combinaison de teintes et de tolérances pour contrôler le déploiement de pods vers un pool de nœuds spécifique. Vous pouvez uniquement teinter un nœud dans AKS au moment de la création du pool de nœuds. Vous pouvez également utiliser des étiquettes et des sélecteurs nodePool pour déployer la charge de travail sur des pools de nœuds spécifiques uniquement.

Sécurité du réseau

• Créez un point de terminaison privé pour tout service PaaS que vos charges de travail AKS utilisent, comme Key Vault, Azure Service Bus ou Azure SQL Database. Un point de terminaison privé permet de s’assurer que le trafic entre les applications et ces services n’est pas exposé à l’Internet public. Pour plus d’informations, consultez What is Private Link.

• Configurez votre ressource d’entrée Kubernetes pour exposer des charges de travail via HTTPS. Utilisez un sous-domaine et un certificat numérique distincts pour chaque locataire. L’AGIC configure automatiquement l’écouteur Application Gateway pour l’arrêt SSL.

• Configurez Application Gateway pour utiliser une stratégie WAF pour protéger les charges de travail publiques qui s’exécutent sur AKS contre les attaques malveillantes.

• Utilisez la mise en réseau Azure CNI dans AKS pour intégrer des réseaux virtuels existants ou des réseaux locaux. Ce modèle réseau offre également une meilleure séparation des ressources et plus de contrôle dans un environnement d’entreprise.

• Utilisez des stratégies réseau pour séparer et sécuriser les communications intra-service 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 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. Pour plus d’informations, consultez Stratégie réseau.

• N'exposez pas de connectivité à distance sur vos nœuds AKS. Créez un hôte bastion ou un jumpbox dans un réseau virtuel de gestion. Utilisez l’hôte bastion pour acheminer le trafic en toute sécurité dans votre cluster AKS aux tâches de gestion à distance.

• Envisagez d’utiliser des plages d’adresses IP autorisées dans AKS pour créer un cluster AKS privé dans votre environnement de production. Si vous ne pouvez pas utiliser un cluster AKS privé, au moins un accès sécurisé au serveur d’API.

• Combinez Azure DDoS Protection avec les meilleures pratiques de conception d’application pour fournir des fonctionnalités d’atténuation DDoS améliorées et une défense supplémentaire contre les attaques DDoS. Activez la protection DDoS sur les réseaux virtuels de périmètre.

Authentification et autorisation

• Déployez des clusters AKS avec l’intégration Microsoft Entra. Pour obtenir plus d’informations, consultez Intégration Microsoft Entra gérée par AKS. Microsoft Entra ID centralise le composant de gestion des identités.

• Utilisez le RBAC Kubernetes pour définir les autorisations dont disposent les utilisateurs ou les groupes sur les ressources du cluster. Utilisez des rôles ou clusterRoles et des liaisons pour étendre les utilisateurs ou les groupes au moins de nombre d’autorisations nécessaires. Intégrez Kubernetes RBAC à l’ID Microsoft Entra afin que toute modification de l’état de l’utilisateur ou de l’appartenance au groupe met automatiquement à jour l’accès aux ressources du cluster. Pour plus d’informations, consultez RBAC Kubernetes.

• Utilisez Azure RBAC pour définir les autorisations minimales requises dont disposent les utilisateurs ou les groupes pour les ressources AKS dans un ou plusieurs abonnements. Pour plus d’informations, consultez Utiliser Azure RBAC pour l’autorisation Kubernetes.

• Utilisez ID de charge de travail Microsoft Entra pour affecter une identité managée à des microservices individuels pour l’accès aux ressources Azure. Le microservice peut ensuite accéder aux ressources managées, telles que Key Vault, SQL Database, Service Bus et Azure Cosmos DB. Le microservice n’a pas besoin de stocker et de récupérer des informations d’identification ou des chaîne de connexion à partir de secrets Kubernetes.

• Utilisez le pilote CSI du magasin de secrets pour Key Vault pour accéder aux secrets, tels que les informations d’identification et la chaîne de connexions, à partir de Key Vault plutôt que des secrets Kubernetes.

• Combinez le bloc de construction du magasin de secrets Dapr avec le magasin Key Vault et les identités managées sur Kubernetes pour récupérer des secrets, tels que des informations d’identification et des chaîne de connexion, à partir de Key Vault.

Charge de travail et cluster

• Sécurisez l’accès au serveur d’API Kubernetes pour sécuriser votre cluster. Intégrez Kubernetes RBAC à l’ID Microsoft Entra pour contrôler l’accès au serveur d’API. Utilisez ces contrôles pour sécuriser AKS de la même façon que pour l’accès aux abonnements Azure.

• Limitez l’accès aux actions que les conteneurs peuvent effectuer. Utilisez la fonctionnalité d’admission de sécurité des pods pour activer l’autorisation affinée de la création et des mises à jour des pods. Fournissez le plus petit nombre d’autorisations et évitez d’utiliser l’élévation des privilèges or de racine. Pour plus d’informations, consultez Sécuriser l’accès des pods aux ressources.

• Évitez d’exécuter des conteneurs en tant qu’utilisateur racine dans la mesure du possible.

• Le module de sécurité du noyau Linux AppArmor permet de limiter les actions que les conteneurs peuvent effectuer.

• Mettez régulièrement à niveau vos clusters AKS vers la dernière version de Kubernetes pour tirer parti des nouvelles fonctionnalités et des correctifs de bogues.

• Utilisez le daemonset kured pour surveiller les redémarrages en attente, le cordon et les nœuds de drainage, et appliquer des mises à jour. AKS télécharge et installe automatiquement les correctifs de sécurité sur chaque nœud Linux, mais ne redémarre pas automatiquement le nœud si nécessaire. Pour les nœuds Windows Server, effectuez régulièrement une opération de mise à niveau AKS pour isoler et drainer les pods de façon sécurisée, et pour déployer les nœuds mis à jour.

• Envisagez d’utiliser des protocoles de transport sécurisé HTTPS et gRPC pour toutes les communications intra-pods. Et utilisez un mécanisme d’authentification plus avancé qui ne vous oblige pas à envoyer les informations d’identification simples sur chaque requête, comme Open Authorization (OAuth) ou JSON Web Tokens (JWTs). Établissez une communication intra-service plus sécurisée à l’aide d’un maillage de service, comme Istio, Linkerd ou Consul. Vous pouvez également utiliser Dapr.

Registre de conteneurs

Analysez vos images conteneur pour détecter les vulnérabilités et déployez uniquement des images qui réussissent la validation. Mettez régulièrement à jour les images de base et le runtime de l’application. Redéployez ensuite des charges de travail dans le cluster AKS. Votre flux de travail de déploiement CI/CD doit inclure un processus d’analyse des images conteneur. Vous pouvez utiliser Microsoft Defender pour la sécurité DevOps pour analyser le code pour détecter les vulnérabilités dans vos pipelines automatisés pendant les phases de génération et de déploiement. Vous pouvez également utiliser des outils tels que Prisma Cloud ou Aqua pour analyser et autoriser uniquement les images vérifiées à déployer.

Optimisation des coûts

L’optimisation des coûts consiste à examiner 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.

Le coût de cette architecture dépend des aspects de configuration, tels que les composants suivants :

• Niveaux de service
• Scalabilité ou nombre d’instances que les services allouent dynamiquement pour prendre en charge une demande donnée
• Scripts d’automatisation
• votre niveau de récupération d’urgence.

Après avoir évalué ces aspects, utilisez la calculatrice de prix Azure pour estimer vos coûts. Pour plus d’informations, consultez les principes de l’infrastructure bien architected de l’optimisation des coûts.

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.

Stockage

• Envisagez de déployer votre cluster AKS avec des disques de système d’exploitation éphémères qui fournissent une latence de lecture et d’écriture inférieure, ainsi que des mises à niveau de nœud et de cluster plus rapides.

• Comprendre les besoins de votre application pour choisir le stockage approprié. Utilisez un stockage ssd hautes performances pour les charges de travail de production. Planifiez un système de stockage basé sur le réseau, tel qu’Azure Files, lorsque plusieurs pods doivent accéder simultanément aux mêmes fichiers. Pour plus d’informations, consultez Options de stockage pour les applications dans AKS.

• Planifiez les demandes de votre application afin de déployer la taille appropriée des nœuds. Chaque taille de nœud prend en charge un nombre maximal de disques. Différentes tailles de nœud fournissent également des quantités différentes de stockage local et de bande passante de réseau.

• Optez pour un approvisionnement dynamique. Pour réduire la surcharge de gestion et activer la mise à l’échelle, ne créez pas et affectez statiquement des volumes persistants. Dans vos classes de stockage, définissez la stratégie de récupération appropriée pour réduire les coûts de stockage inutiles après la suppression des pods.

DevOps

• Utilisez un système DevOps, tel que GitHub Actions ou Azure DevOps, pour déployer vos charges de travail sur AKS via un graphique Helm dans un pipeline CI/CD. Pour plus d’informations, consultez Générer et déployer sur AKS.

• Introduisez les déploiements A/B test et canary dans la gestion du cycle de vie de votre application pour tester correctement une application avant de l’introduire à tous les utilisateurs. Vous pouvez utiliser plusieurs techniques pour fractionner le trafic entre les différentes versions du même service.

• En guise d’alternative, vous pouvez utiliser les fonctionnalités de gestion du trafic qu’offre un maillage de service. Pour plus d’informations, consultez La gestion du trafic Istio.

• Utilisez Container Registry ou un autre magasin de registre, comme Docker Hub, pour cataloguer et traiter les images Docker privées que vous déployez sur le cluster. AKS peut utiliser son identité Microsoft Entra pour s’authentifier auprès de Container Registry.

• Si vous devez modifier les paramètres sur Application Gateway, apportez la modification à l’aide de la configuration exposée sur le contrôleur d’entrée ou d’autres objets Kubernetes, tels que l’utilisation d’annotations prises en charge. Après avoir lié une passerelle d’application à l’AGIC, le contrôleur d’entrée synchronise et contrôle presque toutes les configurations de cette passerelle. Si vous configurez directement Application Gateway de manière impérative ou via l’infrastructure en tant que code, le contrôleur d’entrée remplace finalement ces modifications.

Surveillance

• Envisagez les options de supervision intégrées à Azure pour surveiller l’état d’intégrité du cluster AKS et des charges de travail.

• Configurez tous les services PaaS, tels que Container Registry et Key Vault, pour collecter les journaux de diagnostic et les métriques et les envoyer à Log Analytics.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

Les considérations relatives aux performances ne sont pas entièrement liées à l’architecture mutualisée dans AKS, mais elles sont essentielles à cette solution :

• Pour les charges de travail à faible latence, envisagez de déployer un pool de nœuds dédié dans un groupe de placement de proximité. Lorsque vous déployez votre application dans Azure, les instances de machine virtuelle réparties entre les régions ou les zones de disponibilité créent une latence réseau, ce qui peut affecter les performances globales de votre application. Un groupe de placement de proximité est un regroupement logique que vous pouvez utiliser pour vous assurer que les ressources de calcul Azure se trouvent physiquement à proximité les unes des autres. Certains cas d’usage, tels que les jeux, les simulations d’ingénierie et les transactions à haute fréquence, nécessitent une faible latence et des tâches qui se terminent rapidement. Pour les scénarios de calcul hautes performances tels que ceux-ci, envisagez d’utiliser des groupes de placement de proximité pour les pools de nœuds de votre cluster.

• Utilisez toujours des images conteneur plus petites, car vous pouvez créer des builds plus rapides. Les images plus petites sont également moins vulnérables aux vecteurs d’attaque en raison d’une surface d’attaque réduite.

• Utilisez la mise à l’échelle automatique Kubernetes pour effectuer un scale-out dynamique du nombre de nœuds Worker dans un cluster AKS lorsque le trafic augmente. Avec l’autoscaler de pod horizontal et un autoscaler de cluster, les volumes de nœuds et de pods sont ajustés dynamiquement en temps réel pour correspondre à la condition de trafic et éviter les temps d’arrêt qui provoquent des problèmes de capacité. Pour plus d’informations, consultez Utiliser l’autoscaler de cluster dans AKS.

Planificateur

• Passez en revue et implémentez les meilleures pratiques pour les opérateurs de cluster et les développeurs d’applications pour générer et exécuter des applications avec succès sur AKS.

• Planifiez et appliquez des quotas de ressources au niveau de l’espace de noms pour tous les espaces de noms. Si les pods ne définissent pas de demandes ni de limites de ressources, rejetez le déploiement. Supervisez l’utilisation des ressources, puis ajustez les quotas en fonction des besoins. Lorsque plusieurs équipes ou locataires partagent un cluster AKS qui a un nombre fixe de nœuds, vous pouvez utiliser des quotas de ressources pour affecter un partage équitable de ressources à chaque équipe ou locataire.

• Adoptez des plages de limites pour limiter les allocations de ressources aux pods ou conteneurs d’un espace de noms, en termes d’UC et de mémoire.

• Définissez explicitement les demandes et limites de ressources pour l’utilisation du processeur et de la mémoire pour vos pods dans les manifestes YAML ou les graphiques Helm que vous utilisez pour déployer des applications. Lorsque vous spécifiez la requête de ressource pour les conteneurs dans un pod, le planificateur Kubernetes utilise ces informations pour déterminer le nœud sur lequel placer le pod. Lorsque vous spécifiez une limite de ressources pour un conteneur, par exemple l’UC ou la mémoire, kubelet applique ces limites afin que le conteneur en cours d’exécution ne puisse pas utiliser plus de cette ressource que la limite que vous définissez.

• Maintenez la disponibilité des applications en définissant des budgets d’interruption de pod pour vous assurer qu’un nombre minimal de pods sont disponibles dans le cluster.

• Utilisez des classes de priorité pour indiquer l’importance d’un pod. Si le planificateur ne peut pas planifier un pod, il tente de préemptiser ou de supprimer des pods de priorité inférieure afin qu’il puisse planifier le pod en attente.

• Utilisez des teintes Kubernetes et des tolérances pour placer des applications gourmandes en ressources sur des nœuds spécifiques et pour éviter les problèmes de voisin bruyants. Conservez les ressources de nœud disponibles pour les charges de travail qui en ont besoin. N’autorisez pas d’autres charges de travail à planifier sur les nœuds.

• Utilisez des sélecteurs de nœuds, une affinité de nœud ou une affinité entre pods pour contrôler la planification des pods sur les nœuds. Utilisez les paramètres d’affinité entre pods et d’anti-affinité pour colocaliser des pods qui ont des communications chatteuse, pour placer des pods sur différents nœuds et éviter d’exécuter plusieurs instances du même type de pod sur le même nœud.

Déployer ce scénario

Le code source de ce scénario est disponible sur GitHub. Le diagramme suivant montre une application de démonstration que vous pouvez trouver dans le référentiel GitHub AGIC multilocataire AKS.

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

Prérequis

Pour les déploiements en ligne, vous devez disposer d’un compte Azure existant. Si vous n’en avez pas, créez un compte Azure gratuit avant de commencer.

Déployer dans Azure

1. Vérifiez que vos informations d’abonnement Azure sont accessibles.

2. Clonez le référentiel GitHub du workbench :

   git clone https://github.com/Azure-Samples/aks-agic.git
   

3. 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

• Bonnes pratiques relatives aux clusters AKS
• Bonnes pratiques relatives aux fonctionnalités basiques du planificateur dans AKS
• Créer un cluster AKS privé
• Créer des stratégies WAF pour Application Gateway
• Différence entre un déploiement Helm et le module complémentaire AKS
• Fonctionnement d’une passerelle applicative

Ressources associées

• Architecture de référence pour un cluster AKS