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

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

Limites du Gestionnaire de stratégies réseau Azure

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).

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.

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é.

Installer l’extension Azure CLI aks-preview

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.

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

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

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. Par exemple :

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.

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 :

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.

--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

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).