Meilleures pratiques pour la connectivité réseau et la sécurité dans Azure Kubernetes Service (AKS)

Lorsque vous créez et gérez des clusters dans Azure Kubernetes Service (AKS), vous fournissez une connectivité réseau pour vos nœuds et applications. Parmi ces ressources réseau figurent des plages d’adresses IP, des équilibreurs de charge et des contrôleurs d’entrée.

Cet article porte sur les meilleures pratiques en matière de connectivité réseau et de sécurité pour les opérateurs de clusters. Dans cet article, vous apprendrez comment :

Choisir le modèle réseau adapté

Conseils sur les bonnes pratiques

Utilisez Azure CNI Overlay dans la plupart des scénarios. Si les charges de travail nécessitent un accès direct aux adresses IP des pods depuis des réseaux connectés, utilisez un réseau plat avec Azure CNI Pod Subnet.

Les réseaux virtuels assurent une connectivité de base pour les nœuds AKS et les clients qui accèdent à vos applications. Il existe deux façons différentes de déployer des clusters AKS dans des réseaux virtuels :

• Réseau overlay : Azure CNI Overlay attribue des adresses IP aux pods à partir d’un CIDR de pods distinct. Le trafic qui quitte le cluster est traduit en adresse IP du nœud, et les pods ne sont pas directement accessibles par leurs adresses IP privées à partir de réseaux connectés.
• Réseau plat : Azure CNI Pod Subnet ou le Azure CNI Node Subnet hérité attribuent des adresses IP aux pods à partir de l’espace du réseau virtuel. Les pods peuvent être atteints par leurs adresses IP privées à partir de réseaux connectés.

Pour plus d’informations sur la sélection d’un modèle de mise en réseau, consultez Planifier la mise en réseau des pods pour AKS.

Vue d’ensemble de la mise en réseau CNI Azure

Azure CNI fournit la gestion des adresses IP (IPAM) et la connectivité pour les pods et les nœuds. L’option IPAM est distincte du plan de données réseau. Par exemple, vous pouvez utiliser Azure CNI avec Cilium avec Azure CNI Overlay ou une option de réseau plat.

Le diagramme suivant montre deux nœuds AKS, chacun connecté via un pont réseau à un réseau partagé Azure réseau virtuel.

La mise en réseau CNI d’Azure permet de dissocier le contrôle de la gestion des ressources. Du point de vue de la sécurité, il est souvent préférable que différentes équipes gèrent et sécurisent ces ressources. Les caractéristiques de connectivité dépendent du modèle de mise en réseau. Les pods de superposition initient des connexions au réseau virtuel et aux ressources locales via l’adresse IP du nœud. Les pods de réseau plat peuvent communiquer directement avec les ressources connectées via leurs adresses IP privées.

Lorsque vous utilisez Azure mise en réseau CNI, la ressource de réseau virtuel se trouve dans un groupe de ressources distinct pour le cluster AKS. Déléguez des permissions à l’identité du cluster AKS pour qu’il puisse accéder à ces ressources et les gérer. L’identité de cluster utilisée par le cluster AKS doit au moins disposer des autorisations Contributeur de réseau sur le sous-réseau de votre réseau virtuel.

Si vous souhaitez définir un rôle personnalisé au lieu d’utiliser le rôle de contributeur de réseau intégré, les autorisations suivantes sont nécessaires :

Par défaut, AKS utilise une identité managée pour son identité de cluster. Toutefois, vous pouvez utiliser un principal de service à la place.

• Pour plus d’informations sur la délégation du principal du service AKS, voir Déléguer l’accès à d’autres ressources Azure.
• Pour plus d’informations sur les identités managées, consultez Utiliser des identités managées.

Planifier des plages d’adresses basées sur le modèle de mise en réseau. Tenez compte des critères suivants :

• Avec Azure CNI Overlay, dimensionnez le sous-réseau des nœuds pour accueillir les nœuds et utilisez une plage CIDR privée distincte pour les pods. Chaque nœud reçoit un espace d’adressage /24 à partir du CIDR du pod.
• Dans un réseau plat, dimensionnez les sous-réseaux du réseau virtuel destinés aux nœuds et aux pods. Azure CNI Pod Subnet utilise des sous-réseaux distincts pour les nœuds et les pods, tandis que l’ancien Azure CNI Node Subnet utilise un seul sous-réseau pour les deux.
• Évitez d'utiliser des plages d'adresses IP qui se chevauchent avec les ressources réseau existantes.
  • C’est nécessaire pour permettre la connectivité aux réseaux locaux ou appairés dans Azure.
• Pour gérer les événements avec montée en puissance parallèle ou les mises à niveau de cluster, vous avez besoin d’adresses IP supplémentaires disponibles dans le sous-réseau affecté.
  • Cet espace d’adressage supplémentaire est particulièrement important si vous utilisez des conteneurs Windows Server, car ces pools de nœuds nécessitent une mise à niveau pour appliquer les derniers correctifs de sécurité. Pour plus d’informations sur les nœuds Windows Server, consultez Upgrader un pool de nœuds dans AKS.

Pour calculer l’espace d’adressage IP requis, consultez la planification des adresses IP pour les clusters AKS.

Lors de la création d’un cluster avec Azure mise en réseau CNI, vous spécifiez d’autres plages d’adresses pour le cluster, telles que l’adresse IP du service DNS et la plage d’adresses de service. En général, assurez-vous que ces plages d’adresses ne se chevauchent ni entre elles ni avec les réseaux associés au cluster, y compris les réseaux virtuels, les sous-réseaux, les réseaux sur site et les réseaux appairés.

Pour plus d’informations sur les modèles de mise en réseau, les limites et le dimensionnement des adresses, consultez Azure vue d’ensemble de la mise en réseau CNI.

Distribuer le trafic d’entrée

Conseils sur les bonnes pratiques

Pour distribuer le trafic HTTP ou HTTPS à vos applications, utilisez des ressources et des contrôleurs d'entrée. Par rapport à un équilibreur de charge Azure, les contrôleurs d’entrée fournissent des fonctionnalités supplémentaires et peuvent être gérés en tant que ressources Kubernetes natives.

Bien qu'un équilibreur de charge Azure puisse distribuer le trafic client aux applications de votre cluster AKS, il est limité dans la compréhension de ce trafic. Une ressource d’équilibrage de charge, qui agit au niveau du calque 4, répartit le trafic en fonction du protocole ou des ports.

La plupart des applications web qui utilisent HTTP ou HTTPS doivent de préférence utiliser des ressources et des contrôleurs d'entrée Kubernetes, qui fonctionnent au niveau du calque 7. L’entrée peut distribuer le trafic en fonction de l’URL de l’application et gérer l’arrêt TLS/SSL. L'entrée réduit également le nombre d'adresses IP exposées et mappées.

Avec un équilibreur de charge, une adresse IP publique doit généralement être affectée et mappée au service dans le cluster AKS pour chaque application. Avec une ressource d’entrée, une seule adresse IP peut répartir le trafic entre plusieurs applications.

Le diagramme montre une adresse IP publique unique recevant le trafic externe et un contrôleur d’entrée distribuant ce trafic à plusieurs services dans le cluster AKS.

L’entrée comporte deux composants : une ressource d’entrée et un contrôleur d’entrée.

Ressource d'entrée

La ressource d'entrée est un manifeste YAML de kind: Ingress. Celui-ci définit l'hôte, les certificats et les règles d'acheminement du trafic vers les services exécutés dans votre cluster AKS.

L’exemple de manifeste YAML suivant utilise la classe d’entrée NGINX managée du module complémentaire de routage d’application. Il distribue le trafic pour myapp.com à l’un des deux services, blogservice ou storeservice, et dirige le client vers un service ou l’autre en fonction de l’URL qu’ils accèdent.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  tls:
  - hosts:
    - myapp.com
    secretName: myapp-secret
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /blog
        pathType: Prefix
        backend:
          service:
            name: blogservice
            port:
              number: 80
      - path: /store
        pathType: Prefix
        backend:
          service:
            name: storeservice
            port:
              number: 80

Le ingressClassName champ sélectionne la classe d’entrée et doit correspondre à une classe configurée sur un contrôleur d’entrée dans le cluster. La valeur webapprouting.kubernetes.azure.com sélectionne le contrôleur d’entrée NGINX managé fourni par le module complémentaire de routage d’application. Remplacez-le par le nom de classe de votre contrôleur d’entrée si vous utilisez une autre implémentation.

Contrôleur d’entrée

Un contrôleur d’entrée hébergé par un cluster s’exécute en tant que charge de travail sur un nœud AKS et surveille les requêtes entrantes. Le trafic entrant est ensuite distribué en fonction des règles définies dans la ressource d’entrée associée à ce contrôleur. Le contrôleur d'entrée le plus courant est basé sur NGINX, mais AKS ne vous impose aucun contrôleur spécifique. Vous pouvez utiliser Application Gateway pour conteneurs, Contour, HAProxy, Traefik et autres.

Vous devez planifier des contrôleurs d’entrée hébergés par un cluster sur un nœud Linux. Indiquez que la ressource doit s’exécuter sur un nœud Linux à l’aide d’un sélecteur de nœuds dans votre manifeste YAML ou déploiement de graphique Helm. Pour plus d’informations, consultez Use node selectors to control where pods are scheduled in AKS (Utiliser des sélecteurs de nœud pour contrôler l’emplacement de planification des pods dans AKS).

Ingress avec le module complémentaire de routage d’application

Le module complémentaire de routage des applications fournit des implémentations d’entrée managées pour AKS. Pour les nouveaux déploiements de longue durée, utilisez l’implémentation de l’API passerelle de routage d’application lorsqu’elle prend en charge vos besoins. Gateway API est la norme de référence à long terme pour l’Ingress Kubernetes et la gestion du trafic de couche 7.

L’implémentation NGINX gérée fournit les fonctionnalités suivantes :

• Configuration facile des contrôleurs NGINX Ingress managés basés sur le contrôleur d’entrée NGINX Kubernetes.
• Intégration à Azure DNS pour la gestion des zones publiques et privées.
• Arrêt SSL avec des certificats stockés dans Azure Key Vault.

Pour plus d’informations, consultez Configurer l’entrée avec l’API passerelle de routage d’application et l’entrée MANAGED NGINX avec le module complémentaire de routage d’application.

Sécuriser le trafic avec un pare-feu d’applications web (WAF)

Conseils sur les bonnes pratiques

Pour analyser le trafic entrant pour détecter des attaques potentielles, utilisez un pare-feu d’applications web (WAF) tel que Barracuda WAF pour Azure ou Azure Web Application Firewall sur Application Gateway pour conteneurs. Application Gateway pour conteneurs achemine le trafic HTTP, HTTPS, gRPC, WebSocket et d’inférence d’IA, et prend en charge la terminaison TLS.

Un contrôleur d’entrée hébergé par un cluster s’exécute en tant que charge de travail Kubernetes dans votre cluster AKS et distribue le trafic vers les services et les applications. Il consomme certaines des ressources du nœud, telles que l’UC, la mémoire et la bande passante réseau. Dans les environnements plus volumineux, vous pouvez envisager les éléments suivants :

• décharger une partie du routage du trafic ou de la terminaison TLS vers une ressource réseau située en dehors du cluster AKS ;
• analyser le trafic entrant à la recherche d'attaques potentielles.

Le diagramme illustre le trafic externe passant par Azure Application Gateway pour les conteneurs. Lorsque la protection WAF est configurée, les règles WAF filtrent les demandes avant qu’Application Gateway pour conteneurs transfère le trafic autorisé aux services dans le cluster AKS.

Pour cette couche de sécurité supplémentaire, un pare-feu d’applications web (WAF) filtre le trafic entrant. Les règles managées et personnalisées protègent contre les attaques telles que l’écriture de scripts intersites et l’injection SQL. Application Gateway pour conteneurs est un service d’équilibrage de charge et de gestion du trafic de couche 7 qui prend en charge Azure WAF.

La protection WAF n’est pas activée en déployant Application Gateway pour conteneurs seul. Vous devez créer une stratégie WAF et effectuer les deux configurations suivantes avant d’inspecter le trafic :

• Créez une ressource enfant dans Azure SecurityPolicy qui fait référence à la stratégie WAF.
• Appliquez une ressource personnalisée Kubernetes WebApplicationFirewallPolicy qui fait référence à la même stratégie WAF et cible la ressource HTTPRoute ou Gateway à protéger.

Une fois les deux configurations terminées, vérifiez l’état des ressources personnalisées et les journaux WAF avant de vous appuyer sur la stratégie de protection. Pour plus d’informations, consultez Azure Web Application Firewall sur Application Gateway pour conteneurs.

Comme d'autres solutions tierces remplissent également ces fonctions, vous pouvez continuer à utiliser les investissements ou l'expertise déjà acquis avec votre produit préféré.

Les ressources d'équilibrage de charge ou d'entrée s'exécutent en permanence dans le cluster AKS et affinent la distribution du trafic. Azure Application Gateway pour conteneurs peut être géré de manière centralisée en tant que contrôleur d’entrée avec une définition de ressource. Pour commencer, créez une passerelle Application Gateway pour conteneurs, puis configurez la protection WAF séparément.

Contrôler le flux de trafic avec des stratégies réseau

Conseils sur les bonnes pratiques

Utilisez des stratégies réseau pour autoriser ou refuser le trafic vers les pods. Par défaut, tout le trafic est autorisé entre les pods au sein d’un cluster. Pour une sécurité accrue, définissez des règles qui limitent la communication des pods.

L’utilisation de stratégies réseau est une fonctionnalité Kubernetes disponible dans AKS qui vous permet de contrôler le flux de trafic entre les pods. Vous autorisez ou refusez le trafic vers le pod en fonction de paramètres tels que les étiquettes attribuées, l'espace de noms ou le port de trafic. Les stratégies réseau constituent un moyen natif Cloud de contrôler le flux de trafic pour les pods. Les pods étant créés de façon dynamique dans un cluster AKS, les stratégies réseau nécessaires peuvent être appliquées automatiquement.

Pour utiliser des stratégies réseau dans AKS, sélectionnez un moteur de stratégie réseau qui prend en charge vos systèmes d’exploitation de nœud et votre plan de données réseau. Vous pouvez activer un moteur de stratégie lors de la création du cluster ou sur un cluster pris en charge existant.

Pour les pools de nœuds Linux, utilisez Azure CNI alimenté par Cilium et son application de stratégie réseau Cilium intégrée. Cilium n'est pas pris en charge pour les pools de nœuds Windows. Pour les charges de travail Windows, utilisez Calico.

Vous créez une stratégie réseau en tant que ressource Kubernetes à l'aide d'un manifeste YAML. Les stratégies sont appliquées aux pods définis, avec des règles d'entrée ou de sortie qui définissent le flux de trafic.

L’exemple suivant applique une stratégie réseau à des pods dotés de l’étiquette app: backend. La règle d'entrée autorise uniquement le trafic en provenance des pods dotés de l'étiquette app: frontend.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Pour commencer à utiliser des stratégies, consultez Trafic sécurisé entre les pods à l’aide de stratégies réseau dans Azure Kubernetes Service (AKS).

Optimiser la résolution DNS avec LocalDNS

Conseils sur les bonnes pratiques

Utilisez LocalDNS pour améliorer les performances et la fiabilité DNS et réduire la charge sur les pods CoreDNS centralisés. LocalDNS est préconfiguré dans AKS Automatic. Dans AKS Standard, activez et configurez LocalDNS par pool de nœuds.

LocalDNS déploie un proxy DNS en tant que systemd service sur chaque nœud pour gérer les requêtes DNS localement. Par défaut, les pods envoient toutes les requêtes DNS aux pods CoreDNS centralisés. À grande échelle, la centralisation de ces requêtes peut créer un goulot d’étranglement, tandis que la résolution locale réduit les tronçons réseau et la latence.

LocalDNS supprime également les entrées de la table conntrack pour le trafic DNS, évitant ainsi l’épuisement de la table conntrack ainsi que les conditions de concurrence susceptibles de provoquer des déconnexions. Les connexions du cache local vers CoreDNS sont mises à niveau vers TCP, ce qui permet le rééquilibrage des connexions et un nettoyage plus rapide des entrées de suivi.

Pour les charges de travail nécessitant une haute disponibilité DNS, LocalDNS prend en charge le service des réponses mises en cache obsolètes pendant une durée configurable lorsque dns en amont n’est pas disponible. Cette fonctionnalité optimale peut aider à maintenir la connectivité des pods et la fiabilité du service pendant les pannes DNS temporaires, mais elle ne garantit pas qu’un enregistrement obsolète est disponible.

Dans AKS Standard, l’activation de LocalDNS sur un pool de nœuds existant recrée l’image de ses nœuds. Planifiez le déploiement pour tenir compte de cette interruption.

Pour plus d’informations sur l’architecture et les fonctionnalités LocalDNS, consultez résolution DNS dans AKS. Pour obtenir des instructions de configuration, consultez Configurer LocalDNS.

Se connecter en toute sécurité aux nœuds

Conseils sur les bonnes pratiques

N'exposez pas de connectivité à distance sur vos nœuds AKS. Pour le dépannage courant des nœuds Linux, utilisez kubectl debug via l’API Kubernetes. Quand vous avez besoin d’un accès SSH, connectez-vous via une mise en réseau privée ou Azure Bastion.

Vous pouvez effectuer la plupart des opérations dans AKS à l’aide d’outils de gestion Azure ou du serveur d’API Kubernetes. Les nœuds AKS sont uniquement disponibles sur un réseau privé et ne sont pas connectés au réseau Internet public. Pour les nœuds Linux, utilisez cette option kubectl debug pour démarrer un conteneur de débogage privilégié via l’API Kubernetes. Cette approche ne nécessite pas de connectivité SSH directe au nœud.

Si l’accès à l’API Kubernetes n’est pas approprié ou si vous avez besoin de SSH, utilisez l’adresse IP privée du nœud à partir d’un réseau connecté. Azure Bastion pouvez fournir une connectivité privée sans exposer d’adresse IP publique sur le nœud. Pour Windows nœuds, utilisez un conteneur de processus hôte ou connectez-vous via un nœud proxy Linux. Azure Bastion est une alternative si le nœud proxy n’est pas disponible. Pour plus d’informations, consultez Se connecter aux nœuds de cluster AKS pour la maintenance ou la résolution des problèmes.

Le schéma illustre un réseau virtuel de gestion comprenant un serveur bastion qui achemine les connexions via une liaison d’appairage sécurisée vers le réseau virtuel du cluster AKS.

Si vous utilisez un hôte bastion ou un serveur de rebond, placez-le dans un réseau virtuel de gestion distinct, connecté par peering de manière sécurisée. Sécurisez le réseau de gestion à l’aide de Azure ExpressRoute ou d’une passerelle VPN pour vous connecter à un réseau local et contrôler l’accès avec des groupes de sécurité réseau.

Étapes suivantes

Cet article porte sur la sécurité et la connectivité réseau. Pour plus d'informations sur les concepts de base du réseau dans Kubernetes, consultez les concepts de réseau pour les applications dans Azure Kubernetes Service (AKS)