Sécuriser le trafic entre les pods avec des stratégies réseau dans AKS

Article
10/04/2024

Lorsque vous exécutez des applications modernes, basées sur des microservices dans Kubernetes, vous souhaitez la plupart du temps décider des composants qui peuvent communiquer entre eux. Le principe du privilège minimum doit être appliqué à la façon dont le trafic peut circuler entre les pods dans un cluster Azure Kubernetes Service (AKS). Supposons que vous souhaitiez bloquer le trafic directement vers les applications principales. La fonctionnalité Network Policy (Stratégie réseau) de Kubernetes vous permet de définir des règles de trafic d’entrée et de sortie entre les pods d’un cluster.

Cet article vous explique comment installer le moteur de stratégie réseau et créer des stratégies réseau Kubernetes pour contrôler le flux du trafic entre les pods dans AKS. Les stratégies réseau peuvent être utilisées pour les nœuds et pods basés sur Linux ou Windows dans AKS.

Présentation de la stratégie réseau

Par défaut, tous les pods d’un cluster AKS peuvent envoyer et recevoir du trafic sans aucune limite. Pour améliorer la sécurité, vous pouvez définir des règles qui contrôlent le flux du trafic. Par exemple, les applications principales ne sont généralement exposées qu’aux services frontaux requis. De même, les composants de base de données sont uniquement accessibles aux couches Application qui s’y connectent.

Une stratégie réseau est une spécification Kubernetes qui définit les stratégies d’accès concernant la communication entre les pods. Lorsque vous utilisez des stratégies réseau, vous définissez un ensemble de règles ordonné pour envoyer et recevoir du trafic. Vous appliquez les règles à une collection de pods qui correspondent à un ou plusieurs sélecteurs d’étiquettes.

Les règles de stratégie réseau sont définies sous la forme de manifestes YAML. Les stratégies réseau peuvent être intégrées à un manifeste plus vaste qui crée également un déploiement ou un service.

Options de stratégie réseau dans AKS

Azure fournit trois moteurs de stratégie réseau pour appliquer des stratégies réseau :

Cilium pour les clusters AKS qui utilisent Azure CNI avec Cilium.
Azure Network Policy Manager.
Calico, une solution de réseau et de sécurité réseau open source conçue par Tigera.

Nous recommandons l’adoption du moteur de stratégie réseau Cilium. Cilium applique la stratégie réseau sur le trafic à l’aide de Linux Berkeley Packet Filter (BPF), qui est généralement plus efficace que « IPTables ». Pour plus d’informations, consultez la documentation Azure CNI avec Cilium.
Pour appliquer les stratégies spécifiées, Azure Network Policy Manager pour Linux utilise des IPTables Linux. Azure Network Policy Manager pour Windows utilise le service de réseau hôte (HNS) ACLPolicies. Les stratégies sont converties en ensembles de paires d’adresses IP autorisées et interdites. Ces paires sont ensuite programmées sous la forme de règles de filtre IPTable ou HNS ACLPolicy.

Différences entre les moteurs de stratégie réseau : Cilium, Azure NPM et Calico

Fonctionnalité	Azure Network Policy Manager	Calico	Cilium
Plateformes prises en charge	Linux, Windows Server 2022 (préversion)	Linux, Windows Server 2019 et 2022.	Linux.
Options de mise en réseau prises en charge	Azure Container Networking Interface (CNI).	Azure CNI (Linux, Windows Server 2019 et 2022) et kubenet (Linux).	Azure CNI.
Conformité à la spécification Kubernetes	Prise en charge de tous les types de stratégies	Tous les types de stratégie sont pris en charge.	Tous les types de stratégie sont pris en charge.
Autres fonctionnalités	Aucune.	Modèle de stratégie étendu composé d’une stratégie réseau globale, d’un ensemble réseau global et d’un point de terminaison d’hôte. Pour plus d’informations sur l’utilisation de la CLI `calicoctl` pour gérer ces fonctionnalités étendues, consultez les informations de référence utilisateur concernant calicoctl.	Aucune.
Support	Pris en charge par le Support Azure et l’équipe d’ingénierie.	Pris en charge par le Support Azure et l’équipe d’ingénierie.	Pris en charge par le Support Azure et l’équipe d’ingénierie.

Limites du Gestionnaire de stratégies réseau Azure

Remarque

Avec Azure NPM pour Linux, nous n’autorisons pas la mise à l’échelle au-delà de 250 nœuds et de 20 000 pods. Si vous tentez d’effectuer une mise à l’échelle au-delà de ces limites, vous pouvez faire face à des erreurs de mémoire insuffisante (« Out of Memory » (OOM)). Pour une meilleure scalabilité et une prise en charge IPv6, et si les limitations suivantes sont préoccupantes, nous vous recommandons d’utiliser ou de mettre à niveau vers Azure CNI Optimisé par Cilium pour utiliser Cilium comme moteur de stratégie réseau.

Azure NPM ne prend pas en charge IPv6. En revanche, il prend entièrement en charge les spécifications de stratégie réseau dans Linux.

Dans Windows, Azure NPM ne prend pas en charge les fonctionnalités suivantes des spécifications de stratégie réseau :

Les ports nommés.
Stream Control Transmission Protocol (SCTP).
Étiquette de correspondance négative ou sélecteurs d’espace de noms. Par exemple, toutes les étiquettes à l’exception de debug=true.
Les blocs de routage CIDR (Classless InterDomain Routing) except (routage CIDR avec exceptions).

Remarque

Les journaux de pod Azure Network Policy Manager enregistrent une erreur en cas de création d’une stratégie réseau n’étant pas prise en charge.

Modification ou suppression de stratégies réseau

Dans de rares cas, il est possible de rencontrer une condition de course qui peut entraîner une connectivité temporaire et inattendue pour les nouvelles connexions vers ou depuis les pods sur tous les nœuds concernés lors de l'édition ou de la suppression d'une politique de réseau « suffisamment importante ». L'atteinte de cette condition de course n'a jamais d'impact sur les connexions actives.

Si cette condition de course se produit pour un nœud, le pod Azure NPM sur ce nœud entre dans un état où il ne peut pas mettre à jour les règles de sécurité, ce qui peut conduire à une connectivité inattendue pour les nouvelles connexions vers ou depuis les pods sur le nœud affecté. Pour atténuer le problème, le pod Azure NPM redémarre automatiquement environ 15 secondes après être entré dans cet état. Pendant que Azure NPM redémarre sur le nœud concerné, il supprime toutes les règles de sécurité, puis réapplique les règles de sécurité pour toutes les stratégies de réseau. Bien que toutes les règles de sécurité soient réappliquées, il existe une probabilité de connectivité temporaire et inattendue pour les nouvelles connexions vers ou depuis des pods sur le nœud concerné.

Pour limiter le risque de rencontrer cette condition de course, vous pouvez réduire la taille de la stratégie de réseau. Ce problème se produit probablement pour une stratégie réseau avec plusieurs sections ipBlock. Une stratégie réseau avec quatre sections ou moinsipBlock est moins susceptible d’atteindre le problème.

Avant de commencer

L’interface de ligne de commande Azure (Azure CLI) version 2.0.61 ou une version ultérieure doit avoir été installée et configurée. Exécutez az --version pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.

Créer un cluster AKS et activer la stratégie réseau

Pour voir les stratégies réseau en action, créez un cluster AKS qui prend en charge la stratégie réseau, puis ajouter des stratégies.

Pour utiliser Azure Network Policy Manager, vous devez utiliser le plug-in Azure CNI. Calico peut être utilisé avec le plug-in Azure CNI ou avec le plug-in Kubenet CNI.

L’exemple de script suivant crée un cluster AKS avec une identité affectée par le système et active la stratégie réseau à l’aide d’Azure Network Policy Manager.

Remarque

Calico peut être utilisé avec les paramètres --network-plugin azure ou --network-plugin kubenet.

Au lieu d’utiliser une identité affectée par le système, vous pouvez également utiliser une identité affectée par l’utilisateur. Pour plus d’informations, consultez Utiliser des identités managées.

Créer un cluster AKS avec Azure Network Policy Manager activé - Linux uniquement

Dans cette section, vous créez un cluster avec des pools de nœuds Linux et Azure Network Policy Manager activé.

Pour commencer, remplacez les valeurs des variables $RESOURCE_GROUP_NAME et $CLUSTER_NAME.

$RESOURCE_GROUP_NAME=myResourceGroup-NP
$CLUSTER_NAME=myAKSCluster
$LOCATION=canadaeast

Créez le cluster AKS et spécifiez azure pour network-plugin et network-policy.

Pour créer un cluster, utilisez la commande suivante :

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --network-plugin azure \
    --network-policy azure \
    --generate-ssh-keys

Créer un cluster AKS avec Azure Network Policy Manager activé – Windows Server 2022 (préversion)

Dans cette section, vous créez un cluster avec des pools de nœuds Windows et Azure Network Policy Manager activé.

Remarque

Azure Network Policy Manager avec des nœuds Windows est disponible sur Windows Server 2022 uniquement.

Installer l’extension Azure CLI aks-preview

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

Pour installer l’extension aks-preview, exécutez la commande suivante :

az extension add --name aks-preview

Pour effectuer la mise à jour vers la dernière version de l’extension publiée, exécutez la commande suivante :

az extension update --name aks-preview

Inscrire l’indicateur de fonctionnalité WindowsNetworkPolicyPreview

Inscrivez l’indicateur de fonctionnalité WindowsNetworkPolicyPreview à l’aide de la commande az feature register, comme indiqué dans l’exemple suivant :

az feature register --namespace "Microsoft.ContainerService" --name "WindowsNetworkPolicyPreview"

Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit). Vérifiez l’état de l’inscription à l’aide de la commande az feature show :

az feature show --namespace "Microsoft.ContainerService" --name "WindowsNetworkPolicyPreview"

Quand l’état indique Inscrit, actualisez l’inscription du fournisseur de ressources Microsoft.ContainerService à l’aide de la commande az provider register :

az provider register --namespace Microsoft.ContainerService

Créer le cluster AKS

À présent, remplacez les valeurs pour les variables $RESOURCE_GROUP_NAME, $CLUSTER_NAME et $WINDOWS_USERNAME.

$RESOURCE_GROUP_NAME=myResourceGroup-NP
$CLUSTER_NAME=myAKSCluster
$WINDOWS_USERNAME=myWindowsUserName
$LOCATION=canadaeast

Créez un nom d’utilisateur à utiliser en tant qu’informations d’identification d’administrateur pour vos conteneurs Windows Server sur votre cluster. La commande suivante vous invite à indiquer un nom d’utilisateur. Affectez-lui la valeur $WINDOWS_USERNAME. N’oubliez pas que les commandes dans cet article sont entrées dans un interpréteur de commandes Bash.

echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME

Pour créer un cluster, utilisez la commande suivante :

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --windows-admin-username $WINDOWS_USERNAME \
    --network-plugin azure \
    --network-policy azure \
    --generate-ssh-keys

La création du cluster ne prend que quelques minutes. Par défaut, votre cluster est créé avec un pool de nœuds Linux uniquement. Si vous souhaitez utiliser des pools de nœuds Windows, vous pouvez en ajouter un. Voici un exemple :

az aks nodepool add \
    --resource-group $RESOURCE_GROUP_NAME \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name npwin \
    --node-count 1

Créer un cluster AKS avec Calico activé

Créez le cluster AKS et spécifiez --network-plugin azure, et --network-policy calico. Le fait de spécifier --network-policy calico active Calico sur les pools de nœuds Linux et Windows.

Si vous prévoyez d’ajouter des pools de nœuds Windows à votre cluster, incluez les paramètres windows-admin-username et windows-admin-password qui répondent aux exigences de mot de passe de Windows Server.

Important

À ce stade, l’utilisation de stratégies réseau Calico avec des nœuds Windows est disponible sur les nouveaux clusters à l’aide de Kubernetes version 1.20 ou ultérieure avec Calico 3.17.2 et requiert l’utilisation de la mise en réseau Azure CNI. Les nœuds Windows sur les clusters AKS avec Calico ont également l’option IP flottante activée par défaut.

Pour les clusters avec uniquement des pools de nœuds Linux exécutant Kubernetes 1.20 avec des versions antérieures de Calico, la version de Calico est automatiquement mise à niveau vers 3.17.2.

echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --windows-admin-username $WINDOWS_USERNAME \
    --network-plugin azure \
    --network-policy calico \
    --generate-ssh-keys

az aks nodepool add \
    --resource-group $RESOURCE_GROUP_NAME \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name npwin \
    --node-count 1

Installer Azure Network Policy Manager ou Calico sur un cluster existant

L’installation d’Azure Network Policy Manager ou de Calico sur des clusters AKS existants est également prise en charge.

Avertissement

Le processus de mise à niveau déclenche la réimage de chaque pool de nœuds simultanément. La mise à niveau de chaque pool de nœuds séparément n’est pas prise en charge. Toutes les interruptions de mise en réseau de cluster sont similaires à une mise à niveau d’image de nœud ou à une mise à niveau de version de Kubernetes où chaque nœud d’un pool de nœuds est réimagé.

Exemple de commande pour installer Azure Network Policy Manager :

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy azure

Exemple de commande pour installer Calico :

Avertissement

Cet avertissement s’applique à la mise à niveau de clusters Kubenet avec Calico activé vers une superposition Azure CNI avec Calico activé.

Dans les clusters Kubenet avec Calico activé, Calico est utilisé à la fois comme moteur de stratégie réseau et comme CNI.
Dans les clusters Azure CNI, Calico est utilisé uniquement pour l’application de la stratégie réseau, et non comme CNI. Cela peut entraîner un court délai entre le démarrage du pod et le moment où Calico autorise le trafic sortant du pod.

Nous vous recommandons d’utiliser Cilium plutôt que Calico pour éviter ce problème. En savoir plus sur Cilium sur Azure CNI avec Cilium

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy calico

Mettre à niveau un cluster existant sur lequel Azure NPM ou Calico est installé vers Azure CNI avec Cilium

Pour mettre à niveau un cluster existant sur lequel un moteur de stratégie réseau est installé vers Azure CNI avec Cilium, consultez Mettre à niveau un cluster existant vers Azure CNI avec Cilium.

Vérifier la configuration de la stratégie réseau

Quand le cluster est prêt, configurez kubectl pour vous connecter à votre cluster Kubernetes au moyen de la commande az aks get-credentials. Cette commande télécharge les informations d’identification et configure l’interface CLI Kubernetes pour les utiliser :

az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

Pour commencer la vérification de la stratégie réseau, créez un exemple d’application et définissez des règles de trafic.

Tout d’abord, créez un espace de noms appelé demo pour exécuter les exemples de pods :

kubectl create namespace demo

Créez maintenant deux pods dans le cluster nommés client et server.

Remarque

Si vous souhaitez planifier le client ou le serveur sur un nœud particulier, ajoutez le bit suivant avant l’argument --command dans la commande kubectl run de création de pod :

--overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux|windows"}}}'

Créez un pod server. Ce pod sert sur le port TCP 80 :

kubectl run server -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --labels="app=server" --port=80 --command -- /agnhost serve-hostname --tcp --http=false --port "80"

Créez un pod client. La commande suivante exécute Bash sur le pod client :

kubectl run -it client -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --command -- bash

À présent, dans une fenêtre distincte, exécutez la commande suivante pour obtenir l’adresse IP du serveur :

kubectl get pod --output=wide -n demo

La sortie doit ressembler à :

NAME     READY   STATUS    RESTARTS   AGE   IP            NODE             NOMINATED NODE   READINESS GATES
server   1/1     Running   0          30s   10.224.0.72   akswin22000001   <none>           <none>

Tester la connectivité sans stratégie réseau

Dans l’interpréteur de commandes du client, exécutez la commande suivante pour vérifier la connectivité avec le serveur. Remplacez server-ip à l’aide de l’adresse IP trouvée dans la sortie de l’exécution de la commande précédente. Si la connexion aboutit, il n’y a pas de sortie.

/agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp

Tester la connectivité avec une stratégie réseau

Pour ajouter des stratégies réseau, créez un fichier nommé demo-policy.yaml et collez le manifeste YAML suivant :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: demo-policy
  namespace: demo
spec:
  podSelector:
    matchLabels:
      app: server
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: client
    ports:
    - port: 80
      protocol: TCP

Spécifiez le nom de votre manifeste YAML et appliquez-le à l’aide de kubectl apply :

kubectl apply –f demo-policy.yaml

À présent, dans l’interpréteur de commandes du client, vérifiez la connectivité avec le serveur en exécutant la commande /agnhost suivante :

/agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp

La connectivité avec le trafic est bloquée, car le serveur est étiqueté avec app=server, alors que le client n’est pas étiqueté. La commande de connexion précédente génère cette sortie :

TIMEOUT

Exécutez la commande suivante pour étiqueter client et vérifier la connectivité avec le serveur. La sortie ne doit rien retourner.

kubectl label pod client -n demo app=client

Désinstaller Azure Network Policy Manager ou Calico

Conditions requises :

Azure CLI version 2.63 ou ultérieure

Remarque

Le processus de désinstallation ne supprime pas les définitions de ressources personnalisées (CRD) et les ressources personnalisées (CR) utilisées par Calico. Ces CRD et ces CR ont toutes des noms se terminant par « projectcalico.org » ou « tigera.io ». Ces CRD et les CR associées peuvent être supprimées manuellement après la désinstallation de Calico (la suppression des CRD avant la suppression de Calico interrompt le cluster).
La mise à niveau ne supprime aucune ressource NetworkPolicy dans le cluster, mais après la désinstallation ces stratégies ne sont plus appliquées.

Avertissement

Pour supprimer Azure Network Policy Manager ou Calico d’un cluster, exécutez la commande suivante :

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy none

Nettoyer les ressources

Dans cet article, vous avez créé un espace de noms et deux pods, et appliqué une stratégie réseau. Pour nettoyer ces ressources, utilisez la commande kubectl delete et spécifiez le nom des ressources :

kubectl delete namespace demo

Étapes suivantes

Pour plus d’informations sur les ressources réseau, voir Concepts de réseau pour les applications dans AKS (Azure Kubernetes Service).

Pour plus d’informations sur les stratégies, consultez l’article Kubernetes network policies (Stratégies réseau Kubernetes).

Partager via

Sécuriser le trafic entre les pods avec des stratégies réseau dans AKS

Présentation de la stratégie réseau

Options de stratégie réseau dans AKS

Différences entre les moteurs de stratégie réseau : Cilium, Azure NPM et Calico

Limites du Gestionnaire de stratégies réseau Azure

Modification ou suppression de stratégies réseau

Avant de commencer

Créer un cluster AKS et activer la stratégie réseau

Créer un cluster AKS avec Azure Network Policy Manager activé - Linux uniquement

Créer un cluster AKS avec Azure Network Policy Manager activé – Windows Server 2022 (préversion)

Installer l’extension Azure CLI aks-preview

Inscrire l’indicateur de fonctionnalité WindowsNetworkPolicyPreview

Créer le cluster AKS

Créer un cluster AKS avec Calico activé

Installer Azure Network Policy Manager ou Calico sur un cluster existant

Mettre à niveau un cluster existant sur lequel Azure NPM ou Calico est installé vers Azure CNI avec Cilium

Vérifier la configuration de la stratégie réseau

Tester la connectivité sans stratégie réseau

Tester la connectivité avec une stratégie réseau

Désinstaller Azure Network Policy Manager ou Calico

Nettoyer les ressources

Étapes suivantes

Ressources supplémentaires