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

Article
08/02/2024

Lorsque vous créez et gérez des clusters dans Azure Kubernetes Service (AKS), vous assurez une connectivité réseau à vos nœuds et à vos 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 :

comparer les modes réseau kubenet et Azure Container Networking interface (CNI) dans 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 la mise en réseau Azure CNI dans AKS pour l'intégration avec 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 d’Azure CNI : se déploie dans un réseau virtuel et utilise le plugin Azure CNI Kubernetes. Les pods reçoivent des adresses IP individuelles qui peuvent communiquer avec d’autres services réseau ou ressources locales.
Mise en réseau Kubenet : Azure gère les ressources de réseau virtuel pendant le déploiement du cluster et utilise le plug-in Kubernetes kubenet.

Azure CNI et kubenet sont des options valides pour les déploiements de production.

Mise en réseau CNI

Azure CNI est un protocole indépendant du fournisseur qui permet au runtime du conteneur d'adresser des demandes à un fournisseur de réseau. Il attribue des adresses IP aux pods et aux nœuds, et offre des fonctionnalités de Gestion des adresses IP (IPAM) lorsque vous vous connectez aux réseaux virtuels Azure existants. Chaque nœud et ressource 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.

Diagramme représentant 2 nœuds avec des ponts les reliant chacun à un réseau virtuel Azure

La mise en réseau Azure CNI pour la production permet notamment 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. Une mise en réseau Azure CNI vous permet de vous connecter directement à des ressources Azure existantes, à des ressources locales ou à d'autres services avec les adresses IP attribuées à chacun des pods.

Avec une mise en réseau Azure CNI, la ressource de réseau virtuel se trouve dans un groupe de ressources distinct du 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 les mises en réseau kubenet et Azure CNI, chaque nœud en cours d’exécution dispose de limites par défaut pour 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 de scale-out et les mises à niveau de cluster, des adresses IP supplémentaires sont nécessaires sur le sous-réseau attribué.
- 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 Mettre à niveau un pool de nœuds dans AKS.

Pour calculer l’adresse IP requise, voir Configurer la mise en réseau Azure CNI dans AKS.

Lorsque vous créez un cluster avec la mise en réseau Azure CNI, vous spécifiez d'autres plages d'adresses pour le cluster, comme l'adresse du pont Docker, l'adresse IP du service DNS et la plage d'adresses du 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 Configurer la mise en réseau Azure CNI dans AKS.

Mise en réseau Kubenet

Bien que kubenet ne vous oblige pas à configurer les réseaux virtuels avant de déployer le cluster, l'attente présente des inconvénients, tels que :

Comme les nœuds et les pods sont placés sur des sous-réseaux IP différents, l'itinéraire défini par l'utilisateur (UDR) et le transfert IP acheminent le trafic entre les pods et les nœuds. Ce routage supplémentaire peut réduire les performances du réseau.
Les connexions à des réseaux locaux existants et le peering avec d’autres réseaux virtuels Azure peuvent être complexes.

Étant donné que vous ne créez pas le réseau virtuel et les sous-réseaux séparément du cluster AKS, Kubenet est idéal pour les scénarios suivants :

les petites charges de travail de développement ou de test ;
les sites web simples à faible trafic ;
les opérations de lift-and-shift des charges de travail dans des conteneurs.

Pour les déploiements de production, kubenet et Azure CNI sont tous deux des options valides. Les environnements qui nécessitent la séparation du contrôle et de la gestion, Azure CNI peut être l’option préférée. En outre, kubenet convient uniquement aux environnements Linux où la conservation de la plage d’adresses IP est une priorité.

Vous pouvez également configurer vos propres plages d’adresses IP et réseaux virtuels à l’aide de Kubenet. Comme pour la mise en réseau Azure CNI, ces plages d'adresses ne doivent pas se chevaucher les unes les autres, ni les réseaux associés au cluster (réseaux virtuels, sous-réseaux, réseaux locaux et réseaux appairés).

Pour plus d'informations sur les limites et le dimensionnement de ces plages d'adresses, consultez Utiliser la mise en réseau kubenet avec vos propres plages d'adresses IP 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 offrent des fonctionnalités supplémentaires et peuvent être gérés comme des ressources Kubernetes natives.

Bien qu'un équilibreur de charge Azure puisse distribuer le trafic client aux applications de votre cluster AKS, sa compréhension de ce trafic est limitée. 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.

Diagramme montrant le flux de trafic d’entrée dans un cluster AKS

Il existe deux composants d’entrée :

une ressource d'entrée ;
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 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 managé 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 à la recherche d'attaques potentielles, utilisez un pare-feu d'application web (WAF) tel que Barracuda pour Azure ou Azure Application Gateway. 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) comme Azure Application Gateway peut protéger et distribuer le trafic d’un cluster AKS

Pour cette couche supplémentaire de sécurité, un pare-feu d'applications web (WAF) filtre le trafic entrant. Le projet OWASP (Open Web Application Security Project) propose un ensemble de règles pour surveiller les attaques de type script intersites ou cookie poisoning. Azure Application Gateway (en préversion dans AKS) est un pare-feu WAF qui intègre ces fonctionnalités de sécurité dans les clusters AKS, avant que le trafic n’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. App Gateway peut être géré de manière centralisée comme contrôleur d’entrée avec une définition de ressource. Pour commencer, voir Créer un contrôleur d’entrée Application Gateway.

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 une stratégie réseau, activez la fonctionnalité lorsque vous créez un cluster AKS. Vous ne pouvez pas activer une stratégie réseau sur un cluster AKS existant. Anticipez l'activation de la stratégie réseau sur les clusters nécessaires.

Notes

Une stratégie réseau doit uniquement être utilisée pour les nœuds et pods Linux 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 Sécuriser le trafic entre les pods avec des stratégies réseau dans Azure Kubernetes Service (AKS).

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.

Dans AKS, la plupart des opérations peuvent être effectuées à 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.

Se connecter à des nœuds AKS à l’aide d’un hôte bastion ou d’une jumpbox

Vous devez également sécuriser le réseau de gestion pour l’hôte bastion. Utilisez Azure ExpressRoute ou 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 principes fondamentaux des réseaux dans Kubernetes, voir Concepts relatifs au réseau des applications dans Azure Kubernetes Service (AKS).

Partager via