Meilleures pratiques pour la connectivité réseau et la sécurité dans Azure Kubernetes Service (AKS)Best practices for network connectivity and security in Azure Kubernetes Service (AKS)

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.As you create and manage clusters in Azure Kubernetes Service (AKS), you provide network connectivity for your nodes and applications. Parmi ces ressources réseau figurent des plages d’adresses IP, des équilibreurs de charge et des contrôleurs d’entrée.These network resources include IP address ranges, load balancers, and ingress controllers. Pour maintenir une qualité de service élevée dans les applications, il faut planifier, puis configurer ces ressources.To maintain a high quality of service for your applications, you need to plan for and then configure these resources.

Cet article porte sur les meilleures pratiques en matière de connectivité réseau et de sécurité pour les opérateurs de clusters.This best practices article focuses on network connectivity and security for cluster operators. Dans cet article, vous apprendrez comment :In this article, you learn how to:

  • comparer les modes réseau kubenet et Azure CNI dans Azure Kubernetes Service ;Compare the kubenet and Azure CNI network modes in AKS
  • prévoir l’adressage IP et la connectivité nécessaires ;Plan for required IP addressing and connectivity
  • distribuer le trafic à l’aide d’équilibreurs de charge, de contrôleurs d’entrée ou de pare-feu d’applications web ;Distribute traffic using load balancers, ingress controllers, or a web application firewall (WAF)
  • se connecter en toute sécurité aux nœuds de cluster.Securely connect to cluster nodes

Choisir le modèle réseau adaptéChoose the appropriate network model

Meilleures pratiques : pour une intégration avec des réseaux virtuels existants ou des réseaux locaux, utilisez la mise en réseau Azure CNI dans AKS.Best practice guidance - For integration with existing virtual networks or on-premises networks, use Azure CNI networking in AKS. Ce modèle réseau offre également une meilleure séparation des ressources et plus de contrôle dans un environnement d’entreprise.This network model also allows greater separation of resources and controls in an enterprise environment.

Les réseaux virtuels assurent une connectivité de base pour les nœuds AKS et les clients qui accèdent à vos applications.Virtual networks provide the basic connectivity for AKS nodes and customers to access your applications. Il existe deux façons différentes de déployer des clusters AKS dans des réseaux virtuels :There are two different ways to deploy AKS clusters into virtual networks:

  • 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.Kubenet networking - Azure manages the virtual network resources as the cluster is deployed and uses the kubenet Kubernetes plugin.
  • Mise en réseau Azure CNI : effectue le déploiement dans un réseau virtuel, et utilise le plug-in Kubernetes Azure Container Networking Interface (CNI).Azure CNI networking - Deploys into a virtual network, and uses the Azure Container Networking Interface (CNI) Kubernetes plugin. Les pods reçoivent des adresses IP individuelles qui peuvent communiquer avec d’autres services réseau ou ressources locales.Pods receive individual IPs that can route to other network services or on-premises resources.

L’interface Azure CNI est un protocole indépendant du fournisseur qui permet au runtime du conteneur d’adresser des demandes à un fournisseur de réseau.The Container Networking Interface (CNI) is a vendor-neutral protocol that lets the container runtime make requests to a network provider. Elle affecte des adresses IP aux pods et aux nœuds et offre des fonctionnalités de Gestion des adresses IP (IPAM) pour la connexion à des réseaux virtuels Azure existants.The Azure CNI assigns IP addresses to pods and nodes, and provides IP address management (IPAM) features as you connect to existing Azure virtual networks. Chaque ressource de type nœud ou pod reçoit une adresse IP dans le réseau virtuel Azure, sans qu’aucun routage supplémentaire soit nécessaire pour communiquer avec d’autres ressources ou services.Each node and pod resource receives an IP address in the Azure virtual network, and no additional routing is needed to communicate with other resources or services.

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

Pour les déploiements de production, kubenet et Azure CNI sont tous deux des options valides.For production deployments, both kubenet and Azure CNI are valid options.

Un des avantages notables de la mise en réseau Azure CNI pour la production est que le modèle réseau permet de séparer le contrôle et la gestion des ressources.A notable benefit of Azure CNI networking for production is the network model allows for separation of control and management of resources. 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.From a security perspective, you often want different teams to manage and secure those resources. 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 assignées à chacun des pods.Azure CNI networking lets you connect to existing Azure resources, on-premises resources, or other services directly via IP addresses assigned to each pod.

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.When you use Azure CNI networking, the virtual network resource is in a separate resource group to the AKS cluster. Déléguez des permissions au principal de service AKS pour qu’il puisse accéder à ces ressources et les gérer.Delegate permissions for the AKS service principal to access and manage these resources. Le principal du service utilisé par le cluster AKS doit disposer au moins des autorisations Contributeur de réseau sur le sous-réseau de votre réseau virtuel.The service principal used by the AKS cluster must have at least Network Contributor permissions on the subnet within your virtual network. 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 :If you wish to define a custom role instead of using the built-in Network Contributor role, the following permissions are required:

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

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.For more information about AKS service principal delegation, see Delegate access to other Azure resources. Au lieu d’utiliser le principal de service, vous pouvez aussi utiliser l’identité managée affectée par le système pour les autorisations.Instead of a service principal, you can also use the system assigned managed identity for permissions. Pour plus d’informations, consultez Utiliser des identités managées.For more information, see Use managed identities.

Dans la mesure où chaque nœud et chaque pod reçoit sa propre adresse IP, planifiez les plages d’adresses des sous-réseaux AKS.As each node and pod receive its own IP address, plan out the address ranges for the AKS subnets. Le sous-réseau doit être assez grand pour offrir une adresse IP à chacun des nœuds, pods et ressources réseau déployés.The subnet must be large enough to provide IP addresses for every node, pods, and network resources that you deploy. Chaque cluster AKS doit être placé dans son propre sous-réseau.Each AKS cluster must be placed in its own subnet. Pour autoriser la connexion à des réseaux locaux ou en peering dans Azure, n’utilisez pas de plages d’adresses IP qui recouvrent des ressources réseau existantes.To allow connectivity to on-premises or peered networks in Azure, don't use IP address ranges that overlap with existing network resources. Des limites par défaut s’appliquent au nombre de pods qu’exécute chaque nœud avec une mise en réseau Kubenet ou Azure CNI.There are default limits to the number of pods that each node runs with both kubenet and Azure CNI networking. Pour gérer les événements de scale-out et les mises à niveau de cluster, des adresses IP supplémentaires sont également nécessaires dans le sous-réseau attribué.To handle scale out events or cluster upgrades, you also need additional IP addresses available for use in the assigned subnet. 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é.This additional address space is especially important if you use Windows Server containers, as those node pools require an upgrade to apply the latest security patches. Pour plus d’informations sur les nœuds Windows Server, consultez Mettre à niveau un pool de nœuds dans AKS.For more information on Windows Server nodes, see Upgrade a node pool in AKS.

Pour calculer l’adresse IP requise, voir Configurer la mise en réseau Azure CNI dans AKS.To calculate the IP address required, see Configure Azure CNI networking in AKS.

Mise en réseau KubenetKubenet networking

Si la mise en réseau Kubenet n’impose pas de configurer les réseaux virtuels avant le déploiement du cluster, elle présente des inconvénients :Although kubenet doesn't require you to set up the virtual networks before the cluster is deployed, there are disadvantages:

  • Les nœuds et les pods sont placés sur différents sous-réseaux IP.Nodes and pods are placed on different IP subnets. Le routage défini par l’utilisateur (UDR) et le transfert IP sont utilisés pour acheminer le trafic entre les nœuds et les pods.User Defined Routing (UDR) and IP forwarding is used to route traffic between pods and nodes. Ce routage supplémentaire peut réduire les performances du réseau.This additional routing may reduce network performance.
  • Les connexions à des réseaux locaux existants et le peering avec d’autres réseaux virtuels Azure peuvent être complexes.Connections to existing on-premises networks or peering to other Azure virtual networks can be complex.

Une mise en réseau Kubenet convient pour de petites charges de travail de développement et de test, dans la mesure où il n’est pas nécessaire de créer le réseau virtuel et les sous-réseaux séparément du cluster AKS.Kubenet is suitable for small development or test workloads, as you don't have to create the virtual network and subnets separately from the AKS cluster. Les sites web simples recevant peu de trafic et le lift-and-shift de charges de travail dans des conteneurs peuvent également tirer avantage de la simplicité des clusters AKS déployés avec la mise en réseau Kubenet.Simple websites with low traffic, or to lift and shift workloads into containers, can also benefit from the simplicity of AKS clusters deployed with kubenet networking. Pour la plupart des déploiements de production, vous devez planifier et utiliser une mise en réseau Azure CNI.For most production deployments, you should plan for and use Azure CNI networking. Vous pouvez également configurer vos propres plages d’adresses IP et réseaux virtuels à l’aide de Kubenet.You can also configure your own IP address ranges and virtual networks using kubenet.

Distribuer le trafic d’entréeDistribute ingress traffic

Meilleures pratiques : pour répartir le trafic HTTP ou HTTPS sur vos applications, utilisez des contrôleurs et des ressources d’entrée.Best practice guidance - To distribute HTTP or HTTPS traffic to your applications, use ingress resources and controllers. Les contrôleurs d’entrée offrent des fonctionnalités supplémentaires par rapport à un équilibreur de charge Azure standard. Ils peuvent être gérés comme des ressources Kubernetes natives.Ingress controllers provide additional features over a regular Azure load balancer, and can be managed as native Kubernetes resources.

Un équilibreur de charge Azure peut distribuer le trafic de client aux applications du cluster AKS, mais sa compréhension du trafic reste limitée.An Azure load balancer can distribute customer traffic to applications in your AKS cluster, but it's limited in what it understands about that traffic. Une ressource d’équilibrage de charge, qui agit au niveau de la couche 4, répartit le trafic en fonction du protocole ou des ports.A load balancer resource works at layer 4, and distributes traffic based on protocol or ports. La plupart des applications web qui utilisent HTTP ou HTTPS doivent de préférence utiliser des contrôleurs et des ressources d’entrée Kubernetes, qui fonctionnent au niveau de la couche 7.Most web applications that use HTTP or HTTPS should use Kubernetes ingress resources and controllers, which work at layer 7. L’entrée peut distribuer le trafic en fonction de l’URL de l’application et gérer l’arrêt TLS/SSL.Ingress can distribute traffic based on the URL of the application and handle TLS/SSL termination. Cette capacité réduit également le nombre d’adresses IP exposées et mappées.This ability also reduces the number of IP addresses you expose and map. 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.With a load balancer, each application typically needs a public IP address assigned and mapped to the service in the AKS cluster. Avec une ressource d’entrée, une seule adresse IP peut répartir le trafic entre plusieurs applications.With an ingress resource, a single IP address can distribute traffic to multiple applications.

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

Il existe deux composants d’entrée :There are two components for ingress:

  • une ressource d’entrée ;An ingress resource, and
  • un contrôleur d’entrée.An ingress controller

La ressource d’entrée est un manifeste YAML de kind: Ingress qui définit l’hôte, les certificats et les règles de routage du trafic vers les services qui s’exécutent dans le cluster AKS.The ingress resource is a YAML manifest of kind: Ingress that defines the host, certificates, and rules to route traffic to services that run in your AKS cluster. L’exemple de manifeste YAML suivant distribuerait le trafic de myapp.com à un des deux services, blogservice ou storeservice.The following example YAML manifest would distribute traffic for myapp.com to one of two services, blogservice or storeservice. Le client est dirigé vers l’un ou l’autre selon l’URL consultée.The customer is directed to one service or the other based on the URL they access.

kind: Ingress
metadata:
 name: myapp-ingress
   annotations: kubernetes.io/ingress.class: "PublicIngress"
spec:
 tls:
 - hosts:
   - myapp.com
   secretName: myapp-secret
 rules:
   - host: myapp.com
     http:
      paths:
      - path: /blog
        backend:
         serviceName: blogservice
         servicePort: 80
      - path: /store
        backend:
         serviceName: storeservice
         servicePort: 80

Un contrôleur d’entrée est un démon qui s’exécute sur un nœud AKS et surveille les demandes entrantes.An ingress controller is a daemon that runs on an AKS node and watches for incoming requests. Le trafic est ensuite distribué selon les règles définies dans la ressource d’entrée.Traffic is then distributed based on the rules defined in the ingress resource. Le contrôleur d’entrée le plus courant est basé sur NGINX,The most common ingress controller is based on NGINX. mais AKS ne limite pas à un contrôleur spécifique : vous pouvez utiliser d’autres contrôleurs comme Contour, HAProxy ou Traefik.AKS doesn't restrict you to a specific controller, so you can use other controllers such as Contour, HAProxy, or Traefik.

Les contrôleurs d’entrée doivent être planifiés sur un nœud Linux.Ingress controllers must be scheduled on a Linux node. Les nœuds Windows Server ne doivent pas exécuter le contrôleur d’entrée.Windows Server nodes shouldn't run the ingress controller. 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.Use a node selector in your YAML manifest or Helm chart deployment to indicate that the resource should run on a Linux-based node. 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).For more information, see Use node selectors to control where pods are scheduled in AKS.

Il existe de nombreux scénarios pour l’entrée, notamment ceux des guides pratiques suivants :There are many scenarios for ingress, including the following how-to guides:

Sécuriser le trafic avec un pare-feu d’applications web (WAF)Secure traffic with a web application firewall (WAF)

Meilleures pratiques : pour analyser le risque d’attaques dans le trafic, utilisez un pare-feu d’applications web (WAF) comme Barracuda pour Azure ou Azure Application Gateway.Best practice guidance - To scan incoming traffic for potential attacks, use a web application firewall (WAF) such as Barracuda WAF for Azure or 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.These more advanced network resources can also route traffic beyond just HTTP and HTTPS connections or basic TLS termination.

Un contrôleur d’entrée qui distribue le trafic aux services et applications est généralement une ressource Kubernetes du cluster AKS.An ingress controller that distributes traffic to services and applications is typically a Kubernetes resource in your AKS cluster. 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.The controller runs as a daemon on an AKS node, and consumes some of the node's resources such as CPU, memory, and network bandwidth. Dans les environnements de grande taille, il est souvent nécessaire de décharger une partie du routage du trafic ou de l’arrêt TLS sur une ressource réseau située en dehors du cluster AKS.In larger environments, you often want to offload some of this traffic routing or TLS termination to a network resource outside of the AKS cluster. L’objectif est également d’analyser le risque d’attaques dans le trafic entrant.You also want to scan incoming traffic for potential attacks.

Un pare-feu d’applications web (WAF) comme Azure Application Gateway peut protéger et distribuer le trafic d’un cluster AKS

Un pare-feu d’applications web (WAF) ajoute une couche de sécurité supplémentaire en filtrant le trafic entrant.A web application firewall (WAF) provides an additional layer of security by filtering the incoming traffic. 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.The Open Web Application Security Project (OWASP) provides a set of rules to watch for attacks like cross site scripting or cookie poisoning. Azure Application Gateway (actuellement en préversion dans AKS) est un pare-feu WAF capable d’intégrer ces fonctionnalités de sécurité dans des clusters AKS, avant que le trafic n’atteigne les clusters et les applications.Azure Application Gateway (currently in preview in AKS) is a WAF that can integrate with AKS clusters to provide these security features, before the traffic reaches your AKS cluster and applications. D’autres solutions tierces assurent également ces fonctions, ce qui peut permettre de continuer à utiliser les investissements et l’expertise déjà acquis sur un produit donné.Other third-party solutions also perform these functions, so you can continue to use existing investments or expertise in a given product.

Les ressources d’équilibrage de charge ou d’entrée continuent de s’exécuter dans le cluster AKS pour affiner davantage la distribution du trafic.Load balancer or ingress resources continue to run in your AKS cluster to further refine the traffic distribution. App Gateway peut être géré de manière centralisée comme contrôleur d’entrée avec une définition de ressource.App Gateway can be centrally managed as an ingress controller with a resource definition. Pour commencer, voir Créer un contrôleur d’entrée Application Gateway.To get started, create an Application Gateway Ingress controller.

Contrôler le flux de trafic avec des stratégies réseauControl traffic flow with network policies

Bonnes pratiques - Utilisez des stratégies réseau pour autoriser ou refuser le trafic vers les pods.Best practice guidance - Use network policies to allow or deny traffic to pods. Par défaut, tout le trafic est autorisé entre les pods au sein d’un cluster.By default, all traffic is allowed between pods within a cluster. Pour une sécurité accrue, définissez des règles qui limitent la communication des pods.For improved security, define rules that limit pod communication.

L’utilisation de stratégies réseau est une fonctionnalité Kubernetes qui vous permet de contrôler le flux de trafic entre les pods.Network policy is a Kubernetes feature that lets you control the traffic flow between pods. Vous pouvez choisir d’autoriser ou de refuser un trafic en fonction de paramètres, tels que des étiquettes attribuées, un espace de noms ou un port de trafic.You can choose to allow or deny traffic based on settings such as assigned labels, namespace, or traffic port. L’utilisation de stratégies réseau offre une méthode native du cloud pour contrôler le flux de trafic.The use of network policies gives a cloud-native way to control the flow of traffic. 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.As pods are dynamically created in an AKS cluster, the required network policies can be automatically applied. N’utilisez pas des groupes de sécurité réseau Azure pour contrôler le trafic de pod à pod, mais plutôt des stratégies réseau.Don't use Azure network security groups to control pod-to-pod traffic, use network policies.

Pour utiliser une stratégie réseau, la fonctionnalité doit être activée lorsque vous créez un cluster AKS.To use network policy, the feature must be enabled when you create an AKS cluster. Vous ne pouvez pas activer une stratégie réseau sur un cluster AKS existant.You can't enable network policy on an existing AKS cluster. Prévoyez le temps nécessaire pour vérifier que vous activez la stratégie réseau sur les clusters et que vous pouvez les utiliser selon vos besoins.Plan ahead to make sure that you enable network policy on clusters and can use them as needed. Une stratégie réseau doit uniquement être utilisée pour les nœuds et pods Linux dans AKS.Network policy should only be used for Linux-based nodes and pods in AKS.

Une stratégie réseau est créée en tant que ressource Kubernetes à l’aide d’un manifeste YAML.A network policy is created as a Kubernetes resource using a YAML manifest. Les stratégies sont appliquées à des pods définis, puis des règles d’entrée ou de sortie définissent la circulation du trafic.The policies are applied to defined pods, then ingress or egress rules define how the traffic can flow. L’exemple suivant applique une stratégie réseau à des pods dotés de l’étiquette app: backend.The following example applies a network policy to pods with the app: backend label applied to them. La règle d’entrée autorise ensuite uniquement le trafic provenant des pods dotés de l’étiquette app: frontend :The ingress rule then only allows traffic from pods with the app: frontend label:

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).To get started with policies, see Secure traffic between pods using network policies in Azure Kubernetes Service (AKS).

Se connecter en toute sécurité aux nœuds à travers un hôte bastionSecurely connect to nodes through a bastion host

Meilleures pratiques : n’exposez pas de connectivité à distance sur vos nœuds AKS.Best practice guidance - Don't expose remote connectivity to your AKS nodes. Créez un hôte bastion, ou une jumpbox, dans un réseau virtuel de gestion.Create a bastion host, or jump box, in a management virtual network. Utilisez l’hôte bastion pour acheminer le trafic en toute sécurité dans votre cluster AKS aux tâches de gestion à distance.Use the bastion host to securely route traffic into your AKS cluster to remote management tasks.

La plupart des opérations effectuées dans AKS peuvent exploiter des outils de gestion Azure ou le serveur d’API Kubernetes.Most operations in AKS can be completed using the Azure management tools or through the Kubernetes API server. Les nœuds AKS, non connectés à l’Internet public, ne sont disponibles que sur un réseau privé.AKS nodes aren't connected to the public internet, and are only available on a private network. Pour vous connecter aux nœuds et effectuer des tâches de maintenance ou résoudre des problèmes, acheminez vos connexions à travers un hôte bastion ou une jumpbox.To connect to nodes and perform maintenance or troubleshoot issues, route your connections through a bastion host, or jump box. Cet hôte doit se trouver dans un réseau virtuel de gestion distinct, qui offre un peering sécurisé avec le réseau virtuel du cluster AKS.This host should be in a separate management virtual network that is securely peered to the AKS cluster virtual network.

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

Le réseau de gestion de l’hôte bastion doit lui aussi être sécurisé.The management network for the bastion host should be secured, too. 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.Use an Azure ExpressRoute or VPN gateway to connect to an on-premises network, and control access using network security groups.

Étapes suivantesNext steps

Cet article porte sur la sécurité et la connectivité réseau.This article focused on network connectivity and security. 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).For more information about network basics in Kubernetes, see Network concepts for applications in Azure Kubernetes Service (AKS)