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

Important

Le 31 mars 2028, la mise en réseau kubenet pour Azure Kubernetes Service (AKS) sera retirée.

Pour éviter les interruptions de service, vous devezmettre à niveau vers l'interface de mise en réseau de conteneurs (CNI) en superposition Azureavant cette date, lorsque les charges de travail s'exécutant sur kubenet d'AKS ne seront plus prises en charge.

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 :

• Expliquez le mode réseau Azure CNI (Container Networking Interface) dans le service Azure Kubernetes (AKS).
• prévoir l'adressage IP et la connectivité nécessaires ;
• distribuer le trafic à l'aide d'équilibreurs de charge, de contrôleurs d'entrée ou de pare-feu d'applications web ;
• se connecter en toute sécurité aux nœuds de cluster.

Choisir le modèle réseau adapté

Conseils sur les bonnes pratiques

Utilisez le réseau Azure CNI dans AKS (Azure Kubernetes Service) pour l’intégration à des réseaux virtuels existants ou à des réseaux locaux. Ce modèle réseau offre une meilleure séparation des ressources et plus de contrôle dans un environnement d'entreprise.

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 :

• mise en réseau Azure CNI : se déploie dans un réseau virtuel et utilise le plug-in Kubernetes Azure CNI. Les pods reçoivent des adresses IP individuelles qui peuvent communiquer avec d’autres services réseau ou ressources locales.

Azure CNI est une option valide pour les déploiements de production.

Mise en réseau CNI

Azure CNI est un protocole neutre par le fournisseur qui permet au runtime du conteneur d’effectuer des requêtes auprès d’un fournisseur de réseau. Il affecte des adresses IP aux pods et aux nœuds, et fournit des fonctionnalités de gestion des adresses IP (IPAM) lorsque vous vous connectez à des réseaux virtuels existants Azure. Chaque ressource de nœud et de pod reçoit une adresse IP dans le réseau virtuel Azure. Il n’est pas nécessaire d’effectuer un routage supplémentaire pour communiquer avec d’autres ressources ou services.

Notamment, le réseau Azure CNI pour la production permet de séparer le contrôle et 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. Avec Azure mise en réseau CNI, vous vous connectez à des ressources Azure existantes, à des ressources locales ou à d’autres services directement via des adresses IP affectées à chaque pod.

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 :

• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/read

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.

Dans la mesure où chacun des nœuds et des pods reçoit sa propre adresse IP, vous devez planifier les plages d'adresses des sous-réseaux AKS. Tenez compte des critères suivants :

• Le sous-réseau doit être suffisamment grand pour fournir une adresse IP à chaque nœud, pod et ressource réseau que vous déployez.
  • Avec le réseau Azure CNI, chaque nœud actif a des limites par défaut sur le nombre de pods.
• É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’adresse IP requise, consultez Configurer le réseau CNI Azure dans 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 de pont Docker, 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 pas les unes les autres, ni aucun réseau associé 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 limites et le dimensionnement de ces plages d’adresses, consultez Configure Azure mise en réseau CNI dans AKS.

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.

Il existe deux composants d’entrée :

1. une ressource d'entrée ;
2. 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 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 à laquelle il accède.

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

Contrôleur d’entrée

Un contrôleur d'entrée est un démon qui s'exécute sur un nœud AKS et qui surveille les demandes entrantes. Le trafic est ensuite distribué selon les règles définies dans la ressource d’entrée. 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, etc.

Les contrôleurs d’entrée doivent être planifiés sur un nœud Linux. Utilisez un sélecteur de nœud dans votre manifeste YAML ou votre déploiement de graphique Helm pour indiquer que la ressource doit s'exécuter sur un nœud Linux. 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).

Entrée avec le module complémentaire de routage d’application

Le module complémentaire de routage d’application est la méthode recommandée pour configurer un contrôleur d’entrée dans AKS. Le module complémentaire de routage des applications est un contrôleur d’entrée entièrement géré pour Azure Kubernetes Service (AKS) qui 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 sur le module complémentaire de routage d’application, consultez 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 Application Gateway pour conteneurs. Ces ressources réseau plus avancées peuvent également acheminer le trafic au-delà des connexions HTTP et HTTPS et de l’arrêt TLS de base.

Généralement, un contrôleur d'entrée est une ressource Kubernetes du cluster AKS qui distribue le trafic aux services et applications. Le contrôleur s'exécute en tant que démon sur un nœud AKS et consomme des ressources du nœud, comme le processeur, la mémoire et la bande passante réseau. Dans les environnements plus grands, vous pouvez tenir compte des é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.

Un pare-feu d'applications web (WAF) tel que Azure App Gateway peut protéger et répartir le trafic pour votre cluster AKS

Pour cette couche supplémentaire de sécurité, un pare-feu d'applications web (WAF) filtre le trafic entrant. Avec un ensemble de règles, open web Application Security Project (OWASP) surveille les attaques telles que l’écriture de scripts intersites ou l’empoisonnement des cookies. Azure Application Gateway pour conteneurs est un WAF qui s’intègre aux clusters AKS, verrouille ces fonctionnalités de sécurité avant que le trafic atteigne votre cluster AKS et vos applications.

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 d'application Gateway pour conteneurs.

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, la fonctionnalité peut être activée lors de la création du cluster ou sur un cluster AKS existant. Si vous envisagez d’utiliser des stratégies réseau, vérifiez que la fonctionnalité est activée sur votre cluster AKS.

Remarque

Les stratégies réseau peuvent être utilisées pour les nœuds et pods basés sur Linux ou Windows dans AKS.

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

Activez LocalDNS sur vos pools de nœuds AKS pour améliorer les performances, la fiabilité et réduire la charge sur les pods CoreDNS centralisés.

La résolution DNS est essentielle pour la communication de service à service dans Kubernetes. Par défaut, toutes les requêtes DNS provenant de pods sont envoyées aux pods CoreDNS centralisés, ce qui peut devenir un goulot d’étranglement à grande échelle. AKS offre LocalDNS, qui déploie un proxy DNS en tant que systemd service sur chaque nœud. Ce proxy gère les requêtes DNS localement, ce qui réduit les tronçons réseau et la latence de résolution.

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é permet de maintenir la connectivité des pods et la fiabilité du service pendant les pannes DNS temporaires.

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 à travers un hôte bastion

Conseils sur les bonnes pratiques

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.

Vous pouvez effectuer la plupart des opérations dans AKS à l’aide des outils de gestion Azure ou via le 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 vous connecter aux nœuds et assurer la maintenance et le support, acheminez vos connexions via un hôte bastion ou une jumpbox. Vérifiez que cet hôte réside dans un réseau virtuel de gestion distinct et appairé en toute sécurité avec le réseau virtuel du cluster AKS.

Vous devez également sécuriser le réseau de gestion pour l’hôte bastion. Utilisez une passerelle Azure ExpressRoute ou VPN pour vous connecter à un réseau local et contrôler l’accès à l’aide de 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)