Modifier

Utiliser AGIC (Application Gateway Ingress Controller) avec Azure Kubernetes Service multilocataire

Azure Application Gateway
Azure Key Vault
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Bastion

Dans cette solution, Azure Web Application Firewall (WAF) fournit une protection centralisée pour les applications web déployées sur un cluster Azure Kubernetes Service multilocataire (AKS) contre les attaques et vulnérabilités courantes. Les applications web s’exécutant sur un cluster Azure Kubernetes Service (AKS) et exposées par le biais d’Application Gateway Ingress Controller (AGIC) peuvent être protégées des attaques malveillantes, telles que l’injection SQL et les scripts intersites, à l’aide d’une stratégie WAF sur Azure Application Gateway. La stratégie WAF sur Azure Application Gateway est préconfigurée avec les ensembles de règles de base OWASP et peut être modifiée en d’autres versions OWASP CRS prises en charge.

Architecture

Diagramme de cette solution de contrôleur d’entrée Application Gateway.

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

Workflow

Le modèle ARM auxiliaire déploie 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 Application Gateway WAF2.
  • AzureBastionSubnet : héberge Azure Bastion

Le cluster Azure Kubernetes Service (AKS) utilise une identité managée définie par l’utilisateur pour créer des ressources supplémentaires, telles que des équilibreurs de charge et des disques managés, dans Azure. Le modèle ARM vous permet de déployer un cluster AKS avec les fonctionnalités suivantes :

Le cluster AKS est composé des éléments suivants :

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

Une machine virtuelle est déployée dans le même réseau virtuel que celui qui héberge le cluster AKS. Lorsque vous déployez Azure Kubernetes Service en tant que cluster privé, cette machine virtuelle peut être utilisée par les administrateurs système 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 de stockage Azure.

Un hôte Azure Bastion offre une connectivité SSH sécurisée et transparente à la machine virtuelle jumpbox, directement sur le portail Azure via SSL. Azure Container Registry (ACR) permet de créer, stocker et gérer des images conteneur et des artefacts (tels que des graphiques Helm).

L’architecture comprend une Application Gateway utilisée par le contrôleur d’entrée. Application Gateway est déployé sur un sous-réseau dédié et exposé à l’Internet public via une adresse IP publique qui est partagée par toutes les charges de travail du locataire. Une stratégie de pare-feu d’applications web (WAF) est associée à Application Gateway au niveau de la racine et au niveau de l’écouteur HTTP afin de protéger les charges de travail des locataires contre les attaques malveillantes. La stratégie est configurée en mode prévention et utilise OWASP 3.1 pour bloquer les intrusions et les attaques qui sont détectées par les règles. L’attaquant reçoit une exception « 403 Accès non autorisé » et la connexion est fermée. Le mode de prévention enregistre ces attaques dans les journaux WAF.

Un Key Vault est utilisé comme magasin de secrets par les charges de travail qui s’exécutent sur Azure Kubernetes Service (AKS) pour récupérer les clés, les certificats et les secrets via une bibliothèque cliente, le pilote CSI du magasin de secrets ou Dapr. Le lien privé Azure permet aux charges de travail AKS d’accéder aux services PaaS Azure, tels que les Key Vault, sur un point de terminaison privé du réseau virtuel.

L’exemple de topologie comprend les points de terminaison privés suivants :

  • Un point de terminaison privé pour le compte de stockage Blob
  • Un point de terminaison privé pour Azure Container Registry (ACR)
  • Un point de terminaison privé pour Key Vault
  • Si vous optez pour un cluster AKS privé, un point de terminaison privé vers le serveur d’API du cluster Kubernetes

L’architecture comprend également les zones de DNS privé suivantes pour la résolution de noms du nom de domaine complet (FQDN) d’un service PaaS à l’adresse IP privée du point de terminaison privé associé :

  • Une zone de DNS privé pour la résolution de noms du point de terminaison privé vers le compte de stockage Blob Azure
  • Une zone de DNS privé pour la résolution de noms du point de terminaison privé vers Azure Container Registry (ACR)
  • Une zone de DNS privé pour la résolution de noms du point de terminaison privé vers Azure Key Vault
  • Si vous déployez le cluster comme privé, une zone de DNS privé pour la résolution de noms du point de terminaison privé vers l’API du serveur Kubernetes

Il existe une liaison de réseau virtuel entre le réseau virtuel qui héberge le cluster AKS et les zones de DNS privé ci-dessus. Un espace de travail Log Analytics permet de collecter les journaux et les métriques de diagnostic à partir des sources suivantes :

  • Cluster Azure Kubernetes Service
  • Machine virtuelle jumpbox
  • Azure Application Gateway
  • Azure Key Vault
  • Groupes de sécurité réseau Azure

Composants

  • Azure Container Registry est un service de registre Docker managé 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 existants, ou utiliser Azure Container Registry Tasks pour créer des images conteneur dans Azure. Créez des builds à la demande ou des builds entièrement automatisés avec des déclencheurs, tels que des validations du code source et des mises à jour d’images de base.

  • Azure Kubernetes Service 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. Sachant qu’Azure gère les maîtres Kubernetes, vous n’assurer la gestion et la maintenance que des nœuds agents.

  • La solution Azure Key Vault stocke de manière sécurisée des secrets, tels que des clés API, des mots de passe, des certificats et des clés de chiffrement, et contrôle étroitement l’accès à ceux-ci. Azure Key Vault vous permet également de facilement approvisionner, gérer et déployer des certificats TLS/SSL (Transport Layer Security/Secure Sockets Layer) publics et privés pour une utilisation avec Azure et vos ressources connectées internes.

  • Azure Application Gateway est un équilibreur de charge de trafic web qui vous permet de gérer le trafic entrant vers plusieurs API REST et applications web en aval. Les équilibreurs de charge traditionnels fonctionnent au niveau de la couche de transport (couche OSI 4 - TCP et UDP) et acheminent le trafic en fonction de l’adresse IP et du port sources, vers une adresse IP et un port de destination. Par contre, Application Gateway est un équilibreur de charge de couche application (OSI couche 7). (OSI signifie Interconnexion des systèmes ouverts, TCP Protocole de contrôle de transmission et UDP Protocole de datagramme utilisateur.)

  • Le pare-feu d’applications web, ou WAF; est un service qui permet de centraliser la protection de vos applications web contre les vulnérabilités et les attaques courantes. WAF suit les règles des ensembles de règles de base OWASP (Open Web Application Security Project). Azure WAF vous permet de créer des règles personnalisées évaluées pour chaque requête passant 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 ces conditions sont remplies, une action est entreprise (pour autoriser ou bloquer).

  • Azure Bastion est un service PaaS complètement managé que vous provisionnez au sein de votre réseau virtuel. Azure Bastion fournit une connectivité sécurisée et fluide du protocole RDP et de SSH (Secure Shell) aux machines virtuelles de votre réseau virtuel, directement à partir du portail Azure sur TLS.

  • Les machines virtuelles Azure fournissent des ressources informatiques évolutives à la demande qui vous donnent la flexibilité de la virtualisation sans devoir acheter ni maintenir le matériel physique.

  • Le réseau virtuel Azure est le bloc de construction fondamental pour vos réseaux privés Azure. Via les réseaux virtuels, les ressources Azure (telles que les machines virtuelles), peuvent communiquer en toute sécurité entre elles, avec Internet et avec les réseaux locaux. 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 interface de réseau virtuel permettent aux machines virtuelles Azure de communiquer avec des ressources sur Internet, sur Azure et locales. Vous pouvez ajouter plusieurs cartes d’interface réseau supplémentaires à une machine virtuelle Azure, de sorte que les machines virtuelles enfants puissent avoir leurs propres périphériques d’interface réseau et adresses IP dédiés.

  • Les disques managés Azure fournissent des volumes de stockage au niveau du bloc qu’Azure gère sur des machines virtuelles Azure. Les types de disques disponibles sont les disques Ultra, les disques SSD Premium, les disques SSD Standard et les disques durs (HDD).

  • Le Stockage Blob Azure est la solution de stockage d’objets de Microsoft pour le cloud. Stockage Blob est optimisé pour le stockage d’immenses quantités de données non structurées. Les données non structurées sont des données qui n’obéissent pas à un modèle ou une définition de données en particulier, comme des données texte ou binaires.

  • Azure Private Link vous permet d’accéder aux services Azure PaaS (par exemple Stockage Blob Azure et Key Vault) ainsi qu’aux services de partenaires ou de clients hébergés par Azure sur un point de terminaison privé dans votre réseau virtuel.

Autres solutions

Dans cette architecture, Application Gateway Ingress Controller (AGIC) a été installé à l’aide du module complémentaire AGIC pour Azure Kubernetes Service (AKS). Vous pouvez également installer Application Gateway Ingress Controller via un graphique Helm. Pour une nouvelle installation, à l’aide d’une ligne dans Azure CLI, vous pouvez déployer une nouvelle Application Gateway et un nouveau cluster AKS (avec AGIC activé en tant que module complémentaire). De plus, le module complémentaire est un service entièrement géré qui offre d’autres avantages, comme les mises à jour automatiques et une meilleure prise en charge. Les deux méthodes de déploiement d’AGIC (Helm et module complémentaire AKS) sont entièrement prises en charge par Microsoft. En outre, le module complémentaire permet une meilleure intégration avec AKS en tant que module complémentaire de première classe.

Le module complémentaire AGIC (Application Gateway Ingres Controller) est toujours déployé en tant que pod dans votre cluster AKS. Il existe toutefois quelques différences entre la version de déploiement de Helm et la version de module complémentaire d’AGIC. La liste suivante présente les différences entre les deux versions :

  • Les valeurs de déploiement avec Helm ne peuvent pas être modifiées sur le module complémentaire AKS :

    • usePrivateIp sera défini sur false par défaut ; il peut être remplacé par l'annotation use-private-ip
    • shared n’est pas pris en charge par le module complémentaire

  • S’il a été déployé avec Helm, AGIC prend en charge ProhibitedTargets, ce qui signifie qu’AGIC peut configurer Application Gateway spécifiquement pour les clusters AKS sans perturber les autres serveurs back-end existants.

  • Étant donné que le module complémentaire AGIC est un service géré, il est automatiquement mis à jour vers la dernière version du module complémentaire AGIC, ce qui n’est pas le cas dans un déploiement d’AGIC via Helm (où vous devez mettre à jour AGIC manuellement).

  • Les clients ne peuvent déployer qu’un seul module complémentaire AGIC par cluster AKS et chaque module complémentaire AGIC ne peut actuellement cibler qu’une seule instance d’Application Gateway. Pour les déploiements qui requièrent plusieurs AGIC par cluster ou plusieurs AGIC ciblant une Application Gateway, continuez à utiliser AGIC déployé via Helm.

Une seule instance d’Azure Application Gateway Kubernetes Ingress Controller (AGIC) peut ingérer des événements de plusieurs espaces de noms Kubernetes. Si l’administrateur AKS décide d’utiliser Application Gateway comme entrée, tous les espaces de noms utilisent la même instance d’Application Gateway. Une seule installation du contrôleur d’entrée surveille les espaces de noms accessibles et configure l’Application Gateway à laquelle il est associé. Pour plus d’informations, consultez Activer la prise en charge de plusieurs espaces de noms dans un cluster AKS avec Application Gateway Ingress Controller.

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

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

    • Supprimez watchNamespace entièrement la clé du fichier helm-config.yaml. AGIC observe tous les espaces de noms.
    • Définissez watchNamespace sur une chaîne vide. AGIC observe tous les espaces de noms.
    • Ajoutez plusieurs espaces de noms, séparés par une virgule (watchNamespace: default,secondNamespace). AGIC observe ces espaces de noms exclusivement.

  • Appliquez les modifications du modèle Helm avec ce script : helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure

Une fois déployé avec la possibilité d’observer plusieurs espaces de noms, AGIC réalise les actions suivantes :

  • Répertorier les ressources d’entrée de tous les espaces de noms accessibles
  • Filtrer les ressources d’entrée annotées avec kubernetes.io/ingress.class : azure/application-gateway
  • Composer une configuration Application Gateway combinée
  • Appliquer la configuration à l’Application Gateway associée via ARM

Détails du scénario

Un cluster Kubernetes multi-locataire est partagé par plusieurs utilisateurs et charges de travail couramment appelés « locataires ». Cette définition inclut des clusters Kubernetes qui sont partagés par différentes équipes ou divisions au sein d’une organisation. Il comprend également les clusters qui sont 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, il est important qu’une équipe puisse utiliser plus que sa part de ressources équitable. Les quotas de ressources permettent aux administrateurs de résoudre ce problème.

Si vous envisagez de créer un cluster Azure Kubernetes Service (AKS) multi-locataire, vous devez prendre en compte les couches d’isolement des ressources fournies par Kubernetes : cluster, espace de noms, nœud, pod et 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, la planification de pods de différents locataires sur le même nœud peut réduire le nombre de machines nécessaires dans le cluster. En revanche, vous devrez peut-être empêcher certaines charges de travail d’être colocalisées. Par exemple, vous ne pouvez pas autoriser l’exécution de code non fiable en dehors de votre organisation sur le même nœud que les conteneurs qui traitent des informations sensibles. Azure Policy permet de limiter le déploiement à AKS à partir de registres approuvés uniquement.

Bien que Kubernetes ne puisse pas garantir un isolement parfaitement sécurisé entre les locataires, il offre des fonctionnalités pouvant suffire 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 des stratégies réseau et RBAC Kubernetes pour appliquer l’isolement des locataires. (RBAC signifie contrôle d’accès en fonction du rôle.) Par exemple, l’illustration suivante montre le modèle de fournisseur SaaS classique qui héberge plusieurs instances de la même application sur le même cluster, une pour chaque locataire. Chaque application réside dans un espace de noms distinct. Lorsque les locataires ont besoin d’un niveau supérieur d’isolement 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é.

Diagramme d’architecture mutualisée

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

Application Gateway Ingress Controller (AGIC) est une application Kubernetes, qui permet aux clients d’Azure Kubernetes Service (AKS) d’utiliser Azure Application Gateway pour exposer leurs applications conteneurisées à Internet. AGIC surveille le cluster Kubernetes sur lequel il est hébergé et met à jour en permanence Application Gateway afin que les services sélectionnés soient exposés à Internet. Le contrôleur d’entrée s’exécute dans son propre pod sur l’instance AKS du client. AGIC surveille les modifications dans un sous-ensemble de ressources Kubernetes. L’état du cluster AKS est converti en configuration spécifique à Application Gateway et appliqué à Azure Resource Manager (ARM). Cet exemple d’architecture illustre des pratiques éprouvées pour déployer un cluster Azure Kubernetes Service (AKS) public ou privé avec une Azure Application Gateway et un module complémentaire Application Gateway Ingress Controller.

Une seule instance d’Azure Application Gateway Kubernetes Ingress Controller (AGIC) peut observer plusieurs espaces de noms et en ingérer des événements. Si l’administrateur AKS décide d’utiliser Application Gateway comme entrée, tous les espaces de noms utilisent la même instance d’Application Gateway. Une seule installation du contrôleur d’entrée surveille les espaces de noms accessibles et configure l’Application Gateway à laquelle il est associé.

Cas d’usage potentiels

Application Gateway Ingress Controller (AGIC) permet d’exposer et de protéger les charges de travail accessibles sur Internet qui s’exécutent sur un cluster Azure Kubernetes Service (AKS) dans un environnement multi-locataire.

Considérations

Bien que certaines des considérations suivantes ne se rapportent pas à l’architecture multi-locataire dans Azure Kubernetes Service (AKS), nous pensons qu’il s’agit d’exigences essentielles lors du déploiement de cette solution. Cela comprend nos considérations relatives à la sécurité, aux performances, à la disponibilité et la fiabilité, au stockage, au planificateur, au maillage des services et à la surveillance.

Considérations relatives à l’architecture multi-locataire

  • Concevez des clusters AKS pour l’architecture multi-locataire. Kubernetes fournit des fonctionnalités qui vous permettent d’isoler logiquement les équipes et les charges de travail dans le même cluster. L’objectif est de fournir un minimum de privilèges et de les limiter 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. Essayez de réduire le nombre de clusters AKS physiques que vous déployez pour isoler les équipes ou les 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 multi-locataire.
    • Vous pouvez utiliser une combinaison de teintes et de tolérances pour contrôler le déploiement de pods vers un pool de nœuds spécifique. Notez qu’un nœud dans AKS ne peut être entaché qu’au moment de la création du pool de nœuds. Vous pouvez également utiliser des étiquettes et des sélecteurs nodePool pour contrôler le déploiement de la charge de travail sur des pools de nœuds spécifiques.

Considérations relatives à la sécurité

Bien que les considérations de sécurité ne se rapportent pas pleinement à l’architecture multi-locataire dans AKS, nous pensons qu’il s’agit d’exigences essentielles lors du déploiement de cette solution.

Sécurité du réseau

  • Créez un point de terminaison privé pour tout service PaaS utilisé par les charges de travail AKS, par exemple Key Vault, Service Bus ou Azure SQL Database. Ainsi, le trafic entre les applications et ces services n’est pas exposé à l’Internet public. Pour plus d’informations, consultez Qu’est-ce qu’Azure Private Link ?.
  • Configurez votre ressource d’entrée Kubernetes de manière à exposer des charges de travail via HTTPS et utilisez un sous-domaine et un certificat numérique distincts pour chaque locataire. Application Gateway Ingress Controller (AGIC) configure automatiquement l’écouteur Azure Application Gateway pour la terminaison SSL (Secure Socket Layer).
  • Configurez Azure Application Gateway de manière à utiliser une stratégie de pare-feu d’applications web pour protéger les charges de travail publiques (qui s’exécutent sur AKS) contre les attaques malveillantes.
  • Pour l'intégration avec des réseaux virtuels existants ou des réseaux locaux, utilisez la mise en réseau Azure CNI dans AKS. 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 stratégies réseau Azure ou les stratégies réseau Calico pour définir des règles qui contrôlent le flux de trafic entre les différents microservices. Pour plus d’informations, consultez Stratégie réseau.
  • N'exposez pas de connectivité à distance sur vos nœuds AKS. Créez un hôte bastion, ou une jumpbox, dans un réseau virtuel de gestion. Utilisez l’hôte bastion pour acheminer le trafic en toute sécurité dans votre cluster AKS aux tâches de gestion à distance.
  • Envisagez d’utiliser un cluster AKS privé dans votre environnement de production ou au moins un accès sécurisé au serveur d’API, à l’aide de plages d’adresses IP autorisées dans Azure Kubernetes Service.
  • Azure DDoS Protection, combiné aux bonnes pratiques de conception d’application, offre des fonctionnalités d’atténuation des attaques DDoS améliorées pour une meilleure défense contre les attaques DDoS. Vous devez activer Azure DDOS Protection sur tout réseau virtuel 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. L’utilisation de Microsoft Entra ID permet de centraliser le composant de gestion des identités. Tout changement au niveau du compte d’utilisateur ou de l’état du groupe est automatiquement mis à jour dans l’accès au cluster AKS. Utilisez des rôles ou des ClusterRoles et des liaisons pour étendre les utilisateurs ou les groupes au plus petit nombre d’autorisations nécessaires.
  • Utilisez le RBAC Kubernetes pour définir les autorisations dont disposent les utilisateurs ou les groupes sur les ressources du cluster. Créez des rôles et des liaisons qui affectent le plut petit nombre d’autorisations nécessaires. Intégrez le contrôle d’accès en fonction du rôle (RBAC) Kubernetes à Microsoft Entra ID pour refléter automatiquement tout changement apporté à l’état de l’utilisateur ou à l’appartenance à un groupe et pour tenir à jour l’accès aux ressources de cluster.
  • 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 RBAC Kubernetes et Utiliser RBAC Azure pour l’autorisation Kubernetes.
  • Envisagez d’utiliser Microsoft Entra Workload ID pour affecter une identité managée pour une ressource Azure à des microservices individuels, qu’ils peuvent ensuite utiliser pour accéder à des ressources managées (comme Azure Key Vault, SQL Database, Service Bus et Cosmos DB). Tout cela sans le besoin de stocker et récupérer des chaînes de connexion ou des informations d’identification à partir de secrets Kubernetes.
  • Envisagez d’utiliser le pilote CSI du magasin de secrets pour Azure Key Vault pour accéder aux secrets, tels que les chaînes d’informations d’identification et de connexion à partir de Key Vault, plutôt qu’à partir de secrets Kubernetes.
  • Envisagez d’utiliser le bloc de construction Magasins de secrets Dapr avec le magasin Azure Key Vault avec des identités managées sur Kubernetes pour récupérer les secrets (tels que les informations d’identification et les chaînes de connexion) à partir de Key Vault.

Charge de travail et cluster

  • La sécurisation de l’accès au serveur d’API Kubernetes est l’une des choses les plus importantes à faire pour protéger votre cluster. Intégrez le contrôle d’accès en fonction du rôle Kubernetes (RBAC Kubernetes) à Microsoft Entra ID pour contrôler l’accès au serveur d’API. Ces contrôles vous permettent de sécuriser AKS de la même façon que vous sécurisez l’accès à vos abonnements Azure.
  • Limitez l’accès aux actions que les conteneurs peuvent effectuer. Utilisez l'admission de sécurité des pods pour activer l’autorisation de granularité fine de création et de mise à jour de pods. Fournissez le plus petit nombre d’autorisations et évitez d’utiliser l’escalade de privilèges/racine. Pour plus de meilleures pratiques, consultez Sécuriser l’accès du pod aux ressources.
  • Dans la mesure du possible, évitez d’exécuter des conteneurs en tant qu’utilisateur racine.
  • 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 Kubernetes pour tirer parti des nouvelles fonctionnalités et des correctifs de bogues.
  • 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. Utilisez kured pour surveiller les redémarrages en attente, isoler et drainer les nœuds, et, enfin, appliquer vos mises à jour. 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 entre les pods et d’utiliser un mécanisme d’authentification plus avancé qui ne vous oblige pas à envoyer les informations d’identification en texte brut à chaque demande, comme OAuth ou JWT. Il est possible de sécuriser la communication entre les services en tirant parti d’un maillage de services, tels que Istio, Linkerd, ou Consul ou en utilisant Dapr.

Azure Container Registry

  • Analysez vos images de conteneur à la recherche de vulnérabilités et ne déployez que les images validées. Mettez régulièrement à jour les images de base et le runtime de l’application, puis redéployez les 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. Microsoft Defender pour le cloud – Sécurité DevOps permet d’analyser le code des vulnérabilités pendant la génération/le temps de déploiement dans vos pipelines automatisés. Vous pouvez également utiliser des outils tels que Prisma Cloud ou Aqua pour analyser et autoriser uniquement les images vérifiées à déployer.
  • Comme vous utilisez des images de base pour les images de l’application, utilisez l’automatisation pour générer de nouvelles images lorsque l’image de base est mise à jour. Ces images de base incluant généralement des correctifs de sécurité, mettez à jour les images de conteneur d’application en aval. Pour plus d’informations sur la mise à jour des images de base, consultez Automatiser la génération des images en fonction de la mise à jour d’une image de base avec Azure Container Registry Tasks.

Considérations relatives aux performances

Bien que les considérations relatives aux performances ne se rapportent pas à l’architecture multi-locataire dans Azure Kubernetes Service (AKS), nous pensons qu’il s’agit d’exigences essentielles lors du déploiement de 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é. Quand vous déployez votre application dans Azure, la répartition des instances de machine virtuelle sur différentes régions ou zones de disponibilité engendre une latence au niveau du réseau, qui peut impacter les performances globales de votre application. Un groupe de placement de proximité est un regroupement logique utilisé pour s’assurer que les ressources de calcul Azure se trouvent proches physiquement les unes des autres. Certains cas d'usage (tels que les jeux, les simulations d’ingénierie et les transactions à haute fréquence (HFT)) exigent que la latence soit faible et que les tâches s’exécutent rapidement. Dans ces types de scénarios de calcul haute performance (HPC), envisagez d’utiliser des groupes de placement de proximité (PPG) pour les pools de nœuds de votre cluster.
  • Utilisez toujours des images conteneur plus petites, car cela vous permet de 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.
  • La mise à l’échelle automatique Kubernetes permet d’augmenter dynamiquement le nombre de nœuds Worker d’un cluster AKS lorsque le trafic augmente. Avec Autoscaler de pods horizontaux et autoscaler de cluster, les volumes nœud et pod sont ajustés de façon dynamique en temps réel afin de correspondre à la condition de trafic et d’éviter les temps d’arrêt causés par des problèmes de capacité. Pour plus d’informations, consultez Utiliser l'autoscaler de cluster dans Azure Kubernetes Service (AKS).

Considérations relatives à la disponibilité et à la fiabilité

Bien que les considérations relatives à la disponibilité et à la fiabilité ne se rapportent pas à l’architecture multi-locataire dans Azure Kubernetes Service (AKS), nous pensons qu’il s’agit d’exigences essentielles lors du déploiement de cette solution. Tenez compte des méthodes suivantes pour optimiser la disponibilité de votre cluster AKS et de vos charges de travail.

Containers

  • 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. En cas d’échec de probe liveness, le kubelet arrête le 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. En cas d’échec de probe readiness, le contrôleur des points de terminaison supprime l’adresse IP du pod des points de terminaison de tous les services qui correspondent au pod. L’état de préparation par défaut avant le retard initial est Échec.
    • La sonde de démarrage indique si l’application au sein du conteneur est démarrée. Toutes les autres sondes sont désactivées si une sonde de démarrage est fournie, jusqu’à ce qu’elle aboutisse. En cas d’échec de la sonde de démarrage, le kubelet arrête le 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 des problèmes dans le cluster.

  • Utilisez la limite de ressources pour restreindre la quantité totale de ressources autorisées pour un conteneur et ainsi éviter qu’un conteneur donné ne puisse en priver d’autres.

Registre de conteneurs

  • Nous vous suggérons de stocker les images de conteneur dans Azure Container Registry, puis de géorépliquer le registre dans chaque région AKS à l’aide de la géo-réplication Azure Container Registry. La géoréplication est une fonctionnalité disponible pour les registres ACR dans la référence (SKU) Premium.
  • Analysez vos images de conteneur à la recherche de vulnérabilités et ne déployez que les images validées. 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. Autorisez uniquement les registres approuvés dans lesquels vous validez et contrôlez les images disponibles.
  • Comme vous utilisez des images de base pour les images de l’application, utilisez l’automatisation pour générer de nouvelles images lorsque l’image de base est mise à jour. Ces images de base incluant généralement des correctifs de sécurité, mettez à jour les images de conteneur d’application en aval. Nous vous recommandons d’analyser les images conteneur pour détecter les vulnérabilités dans le cadre du pipeline CI/CD avant de publier les images dans le registre de conteneurs. Azure Defender pour les conteneurs peut être intégré aux workflows CI/CD.
  • Tirez profit d’ACR Tasks dans Azure Container Registry pour automatiser les mises à jour correctives du système d’exploitation et de l’infrastructure pour vos conteneurs Docker. ACR Tasks prend en charge l’exécution des générations automatisées lorsque l’image de base d’un conteneur est mise à jour, par exemple lorsque vous retouchez 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 tous les zones de disponibilité au sein d’une région et utilisez un Azure Standard Load Balancer ou Azure Application Gateway devant vos pools de nœuds. Cette topologie offre une meilleure résilience en cas de panne d’un centre de donnée unique. De cette façon, les nœuds de cluster sont répartis entre plusieurs centres de données, en trois zones de disponibilité distinctes au sein d’une même région.
  • Activez la redondance de zone dans Azure Container Registry à des fins de résilience et de haute disponibilité entre les régions.
  • Les contraintes de répartition de topologie de pod permettent de contrôler la répartition des pods dans votre cluster AKS entre des domaines de défaillance, tels que des régions, des zones de disponibilité et des nœuds.
  • Envisagez d’utiliser le contrat SLA de durée de fonctionnement pour les clusters AKS qui hébergent des charges de travail stratégiques. Le contrat SLA de durée de fonctionnement est une fonctionnalité facultative permettant de bénéficier d’un contrat SLA soutenu et élevé pour un cluster. Le contrat SLA de durée de fonctionnement garantit une disponibilité de 99,95 % du point de terminaison de serveur de l’API Kubernetes pour les clusters qui utilisent des zones de disponibilité. Et il garantit une disponibilité de 99,9 % pour les clusters qui n’utilisent pas de zones de disponibilité. AKS utilise les réplicas de nœud principal entre les domaines de mise à jour et d’erreur pour garantir la satisfaction des exigences de contrat SLA.

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

  • Envisagez de déployer votre solution dans au moins deux régions Azure jumelées d’une zone géographique. Vous devez également adopter un équilibreur de charge global, tel que Azure Traffic Manager ou Azure Front Door, avec une méthode de routage actif/actif ou actif/passif afin de garantir la continuité des activités et la récupération d’urgence.
  • Veillez à créer des scripts, à documenter et à tester régulièrement les processus de basculement régional dans un environnement AQ afin d’éviter des problèmes imprévisibles si un service principal est affecté par une panne dans la région primaire.
  • Ces tests sont également destinés à valider si l’approche de récupération d’urgence répond aux objectifs RPO/RTO, en association avec les éventuels processus manuels et interventions nécessaires à un basculement.
  • Veillez à tester les procédures de restauration afin de comprendre si elles fonctionnent comme prévu.
  • Stockez vos images conteneur dans Azure Container Registry et géorépliquez le registre dans chaque région AKS. Pour plus d’informations, consultez Géoréplication dans Azure Container Registry.
  • Dans la mesure du possible, ne stockez pas l’état du service dans le conteneur. Utilisez plutôt une plateforme Azure en tant que service (PaaS) qui prend en charge la réplication multirégion.
  • Si vous utilisez Stockage Azure, préparez et testez la migration de votre stockage de la région principale vers la région de sauvegarde.
  • Envisagez de déployer la configuration du cluster à l’aide de GitOps. L’utilisation de GitOps offre une uniformité entre les clusters principaux et de récupération d’urgence et un moyen rapide de reconstruire un nouveau cluster en cas de perte de cluster.
  • Envisagez de sauvegarder/restaurer la configuration du cluster à l’aide d’outils tels que Sauvegarde Azure Kubernetes Service ou Velero.

Considérations relatives au stockage

Bien que les considérations relatives au stockage ne se rapportent pas à l’architecture multi-locataire dans Azure Kubernetes Service (AKS), nous pensons qu’il s’agit d’exigences essentielles lors du déploiement de cette solution :

  • Envisagez de déployer votre cluster AKS avec des disques de système d’exploitation éphémères, qui peuvent réduire la latence en lecture/écriture, tout en accélérant la mise à l’échelle des nœuds et les mise à niveau du cluster.
  • Identifiez les besoins de votre application pour choisir le stockage approprié. Utilisez un stockage sur disque SSD haute performance 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 Azure Kubernetes Service (AKS).
  • 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. Planifiez les exigences de votre application pour déployer la taille appropriée de nœuds.
  • Pour réduire les frais de gestion et permettre votre mise à l'échelle, ne créez et n’affectez pas de volumes persistants de manière statique. Optez pour un approvisionnement dynamique. Dans vos classes de stockage, définissez la stratégie de demande de récupération appropriée pour réduire les coûts de stockage inutiles une fois les pods supprimés.

Considérations relatives au planificateur

Bien que certaines des considérations relatives au planificateur ne se rapportent pas à l’architecture multi-locataire dans Azure Kubernetes Service (AKS), nous pensons qu’il s’agit d’exigences essentielles lors du déploiement de cette solution :

  • Veillez à passer en revue et à mettre en œuvre les meilleures pratiques permettant aux opérateurs de cluster et aux développeurs d’applications de créer et d’exécuter correctement des applications sur Azure Kubernetes Service (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 avec un nombre fixe de nœuds, les quotas de ressources peuvent être utilisés pour affecter un partage équitable des ressources à chaque équipe ou locataire.
  • Adoptez des plages de limites pour contraindre les allocations de ressources (aux pods ou aux conteneurs) dans un espace de noms en termes de processeur et de mémoire.
  • Définissez explicitement les requêtes et les 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 ressource (processeur ou mémoire) pour un conteneur, le kubelet applique ces limites afin que le conteneur en cours d’exécution ne puisse pas utiliser une plus grande partie de ces ressources que la limite que vous avez définie.
  • Pour maintenir la disponibilité des applications, définissez des Budgets d’interruption de pod pour vous assurer qu’un nombre minimal de pods est disponible dans le cluster.
  • Les classes de priorité peuvent être utilisées pour indiquer l’importance d’un pod. S’il est impossible de planifier un pod, le planificateur tente de préempter (supprimer) des pods de priorité inférieure afin de rendre possible la planification du pod en attente.
  • Utilisez des teintes et des tolérances Kubernetes pour placer des applications gourmandes en ressources sur des nœuds spécifiques et pour éviter des problèmes de voisins bruyants. Conservez les ressources de nœud disponibles pour les charges de travail qui en ont besoin et n’autorisez pas la planification d’autres charges de travail sur les nœuds.
  • Contrôlez la planification des pods sur les nœuds à l’aide de sélecteurs de nœuds, de l’affinité entre nœuds ou de l’affinité entre pods. Utilisez les paramètres d’affinité et d’anti-affinité entre pods pour colocaliser les pods qui ont de longues communications, placer des pods sur des nœuds différents et éviter d’exécuter plusieurs instances du même type de pod sur le même nœud.

Considérations relatives au maillage de service

Bien que les considérations relatives au maillage de service ne se rapportent pas pleinement à l’architecture multi-locataire dans AKS, nous pensons qu’il s’agit d’exigences essentielles lors du déploiement de cette solution.

  • Envisagez d’utiliser un maillage de services open source (tels que Istio, Linkerd, ou Consul) dans votre cluster AKS afin d’améliorer l’observabilité, la fiabilité et la sécurité de vos microservices, via le TLS mutuel. Vous pouvez également implémenter des stratégies de fractionnement du trafic (telles que des déploiements bleus/verts et des déploiements de contrôle de validité). En bref, un maillage de service est une couche d’infrastructure dédiée pour rendre la communication entre les services sécurisée, rapide et fiable. Pour voir le module complémentaire d'Istio intégré à AKS, consultez : Module complémentaire AKS du maillage de service Istio

  • Envisagez d’adopter Dapr pour créer des applications robustes, sans état de microservice et avec état. Vous pouvez utiliser n’importe quel langage de programmation et infrastructure de développement.

Considérations relatives à DevOps

  • Déployez vos charges de travail dans Azure Kubernetes Service (AKS) avec un graphique Helm dans un pipeline CI/CD à l’aide d’un système DevOps, tel que GitHub Actions ou Azure DevOps. Pour plus d’informations, consultez Générer et déployer sur Azure Kubernetes Service.

  • Introduisez des tests A/B et des déploiements de contrôle de validité dans la gestion du cycle de vie des applications pour tester correctement une application avant de la rendre disponible pour tous les utilisateurs. Vous pouvez utiliser plusieurs techniques pour fractionner le trafic entre les différentes versions du même service.

  • Vous pouvez également utiliser les fonctionnalités de gestion du trafic fournies par une implémentation de maillage de services. Pour plus d’informations, consultez l’article suivant :

  • Utilisez Azure Container Registry ou un autre registre de conteneurs (comme Docker Hub) pour stocker les images Docker privées déployées sur le cluster. AKS peut s’authentifier auprès d’Azure Container Registry en tirant parti de son identité Microsoft Entra.

Surveillance - Éléments à prendre en compte

Bien que les considérations relatives à la surveillance ne se rapportent pas à l’architecture multi-locataire dans Azure Kubernetes Service (AKS), nous pensons qu’il s’agit d’exigences essentielles lors du déploiement de cette solution :

  • 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 qu’Azure Container Registry et Key Vault) pour collecter les journaux et les métriques de diagnostic pour Azure Monitor Log Analytics.

Optimisation des coûts

Le coût de cette architecture dépend de divers aspects liés à la configuration, par exemple :

  • Niveaux de service
  • Scalabilité, c’est-à-dire le nombre d’instances allouées dynamiquement par les services 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, accédez à la calculatrice de prix Azure pour estimer vos coûts. En outre, pour obtenir d’autres options d’optimisation de la tarification, consultez les principes d’optimisation des coûts dans Microsoft Azure Well-Architected Framework.

Déployer ce scénario

Le code source de ce scénario est disponible sur GitHub. Vous trouverez également une application de démonstration, comme illustré dans la figure suivante, dans ce référentiel GitHub.

Le diagramme présente le déploiement de cet AGIC avec une architecture 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éploiement vers Azure

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

  2. Commencez par cloner 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.

Auteurs principaux :

Étapes suivantes

Azure Kubernetes Service

Azure Application Gateway

Contrôleur d’entrée d’Azure Application Gateway

Pare-feu d'applications web Azure Application Gateway

Aide relative à l’architecture

Architectures de référence