Sécuriser le trafic entre les pods avec des stratégies réseau dans Azure Kubernetes Service (AKS)Secure traffic between pods using network policies in Azure Kubernetes Service (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.When you run modern, microservices-based applications in Kubernetes, you often want to control which components can communicate with each other. Le principe des privilèges minimum doit être appliqué à la manière dont le trafic peut transiter entre les pods dans un cluster Azure Kubernetes Service (AKS).The principle of least privilege should be applied to how traffic can flow between pods in an Azure Kubernetes Service (AKS) cluster. Supposons que vous souhaitiez bloquer le trafic directement vers les applications principales.Let's say you likely want to block traffic directly to back-end applications. 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.The Network Policy feature in Kubernetes lets you define rules for ingress and egress traffic between pods in a 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.This article shows you how to install the network policy engine and create Kubernetes network policies to control the flow of traffic between pods in AKS. 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.

Avant de commencerBefore you begin

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.You need the Azure CLI version 2.0.61 or later installed and configured. Exécutez  az --version pour trouver la version.Run az --version to find the version. Si vous devez effectuer une installation ou une mise à niveau, consultez  Installer Azure CLI.If you need to install or upgrade, see Install Azure CLI.

Conseil

Si vous utilisiez la fonctionnalité de stratégie réseau disponible dans la préversion, nous vous recommandons de créer un autre cluster.If you used the network policy feature during preview, we recommend that you create a new cluster.

Si vous souhaitez continuer à utiliser les clusters de test existants qui utilisaient une stratégie réseau de la préversion, mettez à niveau votre cluster vers une nouvelle version de Kubernetes pour la dernière version en disponibilité générale, puis déployez le manifeste YAML ci-après pour corriger les incidents du server de métriques et du tableau de bord Kubernetes.If you wish to continue using existing test clusters that used network policy during preview, upgrade your cluster to a new Kubernetes versions for the latest GA release and then deploy the following YAML manifest to fix the crashing metrics server and Kubernetes dashboard. Ce correctif est uniquement requis pour les clusters qui utilisaient le moteur de stratégie réseau Calico.This fix is only required for clusters that used the Calico network policy engine.

Afin d’optimiser la sécurité, examinez le contenu de ce manifeste YAML pour connaître précisément les éléments qui sont déployés dans le cluster AKS.As a security best practice, review the contents of this YAML manifest to understand what is deployed into the AKS cluster.

kubectl delete -f https://raw.githubusercontent.com/Azure/aks-engine/master/docs/topics/calico-3.3.1-cleanup-after-upgrade.yaml

Présentation de la stratégie réseauOverview of network policy

Par défaut, tous les pods d’un cluster AKS peuvent envoyer et recevoir du trafic sans aucune limite.All pods in an AKS cluster can send and receive traffic without limitations, by default. Pour améliorer la sécurité, vous pouvez définir des règles qui contrôlent le flux du trafic.To improve security, you can define rules that control the flow of traffic. Par exemple, les applications principales ne sont généralement exposées qu’aux services frontaux requis.Back-end applications are often only exposed to required front-end services, for example. De même, les composants de base de données sont uniquement accessibles aux couches Application qui s’y connectent.Or, database components are only accessible to the application tiers that connect to them.

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.Network Policy is a Kubernetes specification that defines access policies for communication between Pods. Vous utilisez les stratégies réseau pour définir un jeu ordonné de règles régissant l’envoi et la réception du trafic, puis pour appliquer ces règles à une collection de pods qui correspondent à un ou plusieurs sélecteurs d’étiquette.Using Network Policies, you define an ordered set of rules to send and receive traffic and apply them to a collection of pods that match one or more label selectors.

Ces règles de stratégie réseau sont définies sous la forme de manifestes YAML.These network policy rules are defined as YAML manifests. Les stratégies réseau peuvent être intégrées à un manifeste plus vaste qui crée également un déploiement ou un service.Network policies can be included as part of a wider manifest that also creates a deployment or service.

Options de stratégie réseau dans AKSNetwork policy options in AKS

Azure vous permet d’implémenter une stratégie réseau de deux manières.Azure provides two ways to implement network policy. Vous choisissez une option de stratégie réseau lorsque vous créez un cluster AKS.You choose a network policy option when you create an AKS cluster. Une fois le cluster créé, l’option de stratégie n’est plus modifiable :The policy option can't be changed after the cluster is created:

  • implémentation propre à Azure, appelée stratégies réseau Azure ;Azure’s own implementation, called Azure Network Policies.
  • stratégies réseau Calico, une solution de réseau et de sécurité réseau open source conçue par Tigera.Calico Network Policies, an open-source network and network security solution founded by Tigera.

Ces deux implémentations appliquent les stratégies spécifiées à l’aide du logiciel Linux IPTables.Both implementations use Linux IPTables to enforce the specified policies. Les stratégies sont converties en ensembles de paires d’adresses IP autorisées et interdites.Policies are translated into sets of allowed and disallowed IP pairs. Ces paires sont ensuite programmées sous la forme de règles de filtre IPTable.These pairs are then programmed as IPTable filter rules.

Différences entre les stratégies Azure et Calico et leurs fonctionnalitésDifferences between Azure and Calico policies and their capabilities

FonctionnalitéCapability AzureAzure CalicoCalico
Plateformes prises en chargeSupported platforms LinuxLinux LinuxLinux
Options de mise en réseau prises en chargeSupported networking options Azure CNIAzure CNI Azure CNI et kubenetAzure CNI and kubenet
Conformité à la spécification KubernetesCompliance with Kubernetes specification Prise en charge de tous les types de stratégiesAll policy types supported Prise en charge de tous les types de stratégiesAll policy types supported
Fonctionnalités supplémentairesAdditional features AucunNone 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.Extended policy model consisting of Global Network Policy, Global Network Set, and Host Endpoint. 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.For more information on using the calicoctl CLI to manage these extended features, see calicoctl user reference.
SupportSupport Pris en charge par l’équipe d’ingénierie et de support AzureSupported by Azure support and Engineering team Support de la communauté CalicoCalico community support. Pour plus d’informations sur les offres de support payantes supplémentaires, consultez l’article présentant les options de support de Project Calico.For more information on additional paid support, see Project Calico support options.
JournalisationLogging Les règles ajoutées/supprimées dans IPTables sont journalisées sur chaque hôte sous /var/log/azure-npm.logRules added / deleted in IPTables are logged on every host under /var/log/azure-npm.log Pour plus d’informations, consultez les journaux de composant Calico.For more information, see Calico component logs

Créer un cluster AKS et activer la stratégie réseauCreate an AKS cluster and enable network policy

Pour voir les stratégies réseau en action, nous allons créer, puis développer une stratégie qui définit le flux de trafic :To see network policies in action, let's create and then expand on a policy that defines traffic flow:

  • Refuser tout trafic sur un pod.Deny all traffic to pod.
  • Autoriser le trafic en fonction des étiquettes de pod.Allow traffic based on pod labels.
  • Autoriser le trafic en fonction de l’espace de noms.Allow traffic based on namespace.

Commençons par créer un cluster AKS qui prend en charge les stratégies réseau.First, let's create an AKS cluster that supports network policy.

Important

La fonctionnalité de stratégie réseau n’est activable qu’une fois le cluster créé.The network policy feature can only be enabled when the cluster is created. 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.

Pour utiliser une stratégie réseau Azure, vous devez utiliser le plug-in Azure CNI et définir vos propre réseau et sous-réseaux virtuels.To use Azure Network Policy, you must use the Azure CNI plug-in and define your own virtual network and subnets. Pour de plus amples informations sur la façon de planifier les plages de sous-réseau nécessaires, consultez Configurer le réseau avancé.For more detailed information on how to plan out the required subnet ranges, see configure advanced networking. La stratégie réseau Calico peut être utilisée avec ce même plug-in Azure CNI ou avec le plug-in Kubenet CNI.Calico Network Policy could be used with either this same Azure CNI plug-in or with the Kubenet CNI plug-in.

L’exemple de script suivant :The following example script:

  • Crée un réseau virtuel et un sous-réseau.Creates a virtual network and subnet.
  • Crée un principal de service Azure Active Directory (Azure AD) pour une utilisation avec le cluster AKS.Creates an Azure Active Directory (Azure AD) service principal for use with the AKS cluster.
  • Assigne des autorisations Contributeur pour le principal du service du cluster AKS sur le réseau virtuel.Assigns Contributor permissions for the AKS cluster service principal on the virtual network.
  • Crée un cluster AKS dans le réseau virtuel défini et active la stratégie réseau.Creates an AKS cluster in the defined virtual network and enables network policy.
    • L’option de stratégie réseau azure est utilisée.The azure network policy option is used. Pour utiliser Calico en tant qu’option de stratégie réseau à la place, utilisez le paramètre --network-policy calico.To use Calico as the network policy option instead, use the --network-policy calico parameter. Remarque : Calico peut être utilisé avec --network-plugin azure ou --network-plugin kubenet.Note: Calico could be used with either --network-plugin azure or --network-plugin kubenet.

Fournissez votre propre SP_PASSWORD sécurisé.Provide your own secure SP_PASSWORD. Vous pouvez remplacer les variables RESOURCE_GROUP_NAME et CLUSTER_NAME :You can replace the RESOURCE_GROUP_NAME and CLUSTER_NAME variables:

RESOURCE_GROUP_NAME=myResourceGroup-NP
CLUSTER_NAME=myAKSCluster
LOCATION=canadaeast

# Create a resource group
az group create --name $RESOURCE_GROUP_NAME --location $LOCATION

# Create a virtual network and subnet
az network vnet create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name myVnet \
    --address-prefixes 10.0.0.0/8 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 10.240.0.0/16

# Create a service principal and read in the application ID
SP=$(az ad sp create-for-rbac --output json)
SP_ID=$(echo $SP | jq -r .appId)
SP_PASSWORD=$(echo $SP | jq -r .password)

# Wait 15 seconds to make sure that service principal has propagated
echo "Waiting for service principal to propagate..."
sleep 15

# Get the virtual network resource ID
VNET_ID=$(az network vnet show --resource-group $RESOURCE_GROUP_NAME --name myVnet --query id -o tsv)

# Assign the service principal Contributor permissions to the virtual network resource
az role assignment create --assignee $SP_ID --scope $VNET_ID --role Contributor

# Get the virtual network subnet resource ID
SUBNET_ID=$(az network vnet subnet show --resource-group $RESOURCE_GROUP_NAME --vnet-name myVnet --name myAKSSubnet --query id -o tsv)

# Create the AKS cluster and specify the virtual network and service principal information
# Enable network policy by using the `--network-policy` parameter
az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --generate-ssh-keys \
    --network-plugin azure \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --docker-bridge-address 172.17.0.1/16 \
    --vnet-subnet-id $SUBNET_ID \
    --service-principal $SP_ID \
    --client-secret $SP_PASSWORD \
    --network-policy azure

La création du cluster ne prend que quelques minutes.It takes a few minutes to create the cluster. Quand le cluster est prêt, configurez kubectl pour vous connecter à votre cluster Kubernetes au moyen de la commande az aks get-credentials.When the cluster is ready, configure kubectl to connect to your Kubernetes cluster by using the az aks get-credentials command. Cette commande télécharge les informations d’identification et configure l’interface CLI Kubernetes pour les utiliser :This command downloads credentials and configures the Kubernetes CLI to use them:

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

Refuser tout trafic entrant sur un podDeny all inbound traffic to a pod

Avant de définir des règles autorisant un trafic réseau particulier, commencez par créer une stratégie réseau pour refuser tout trafic.Before you define rules to allow specific network traffic, first create a network policy to deny all traffic. Cette stratégie vous donne un point de départ pour commencer à placer en liste verte uniquement le trafic souhaité.This policy gives you a starting point to begin to whitelist only the desired traffic. Vous pouvez aussi constater aisément que le trafic est ignoré lorsque la stratégie réseau est appliquée.You can also clearly see that traffic is dropped when the network policy is applied.

Pour l’exemple d’environnement d’application et de règles de trafic, commençons par créer un espace de noms nommé development (développement) pour l’exécution des exemples de pods :For the sample application environment and traffic rules, let's first create a namespace called development to run the example pods:

kubectl create namespace development
kubectl label namespace/development purpose=development

Créez un exemple de pod principal qui exécute NGINX.Create an example back-end pod that runs NGINX. Ce pod principal peut être utilisé pour simuler un exemple d’application web principale.This back-end pod can be used to simulate a sample back-end web-based application. Créez ce pod dans l’espace de noms development et ouvrez le port 80 pour gérer le trafic web.Create this pod in the development namespace, and open port 80 to serve web traffic. Étiquetez le pod avec app=webapp,role=backend de façon à pouvoir le cibler avec une stratégie réseau dans la section suivante :Label the pod with app=webapp,role=backend so that we can target it with a network policy in the next section:

kubectl run backend --image=nginx --labels app=webapp,role=backend --namespace development --expose --port 80 --generator=run-pod/v1

Créez un autre pod et attachez une session de terminal pour vérifier que vous accédez correctement à la page web NGINX par défaut :Create another pod and attach a terminal session to test that you can successfully reach the default NGINX webpage:

kubectl run --rm -it --image=alpine network-policy --namespace development --generator=run-pod/v1

À l’invite de l’interpréteur de commandes, utilisez wget pour vérifier que vous pouvez accéder à la page web NGINX par défaut :At the shell prompt, use wget to confirm that you can access the default NGINX webpage:

wget -qO- http://backend

L’exemple de sortie ci-après affiche la page web NGINX par défaut renvoyée :The following sample output shows that the default NGINX webpage returned:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Quittez la session de terminal attachée.Exit out of the attached terminal session. Le pod de test est automatiquement supprimé.The test pod is automatically deleted.

exit

Créer et appliquer une stratégie réseauCreate and apply a network policy

Maintenant que vous avez vérifié que vous pouvez utiliser la page web NGINX de base dans l’exemple de pod principal, créez une stratégie réseau destinée à refuser la totalité du trafic.Now that you've confirmed you can use the basic NGINX webpage on the sample back-end pod, create a network policy to deny all traffic. Créez un fichier nommé backend-policy.yaml et collez le manifeste YAML suivant.Create a file named backend-policy.yaml and paste the following YAML manifest. Ce manifeste utilise un élément podSelector pour attacher la stratégie aux pods dotés de l’étiquette app:webapp,role:backend, comme votre exemple de pod NGINX.This manifest uses a podSelector to attach the policy to pods that have the app:webapp,role:backend label, like your sample NGINX pod. Aucune règle n’est définie sous ingress (entrée), tout trafic entrant sur le pod est donc refusé :No rules are defined under ingress, so all inbound traffic to the pod is denied:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress: []

Appliquez la stratégie réseau à l’aide de la commande kubectl apply et précisez le nom de votre manifeste YAML :Apply the network policy by using the kubectl apply command and specify the name of your YAML manifest:

kubectl apply -f backend-policy.yaml

Tester la stratégie réseauTest the network policy

Voyons si vous pouvez réutiliser la page web NGINX sur le pod principal.Let's see if you can use the NGINX webpage on the back-end pod again. Créez un autre pod de test et attachez une session de terminal :Create another test pod and attach a terminal session:

kubectl run --rm -it --image=alpine network-policy --namespace development --generator=run-pod/v1

À l’invite de l’interpréteur de commandes, utilisez wget pour voir si vous pouvez accéder à la page web NGINX par défaut.At the shell prompt, use wget to see if you can access the default NGINX webpage. Cette fois, définissez une valeur de délai d’attente sur 2 secondes.This time, set a timeout value to 2 seconds. La stratégie réseau bloque à présent tout le trafic entrant, de sorte que la page ne peut pas être chargée, comme illustré dans l’exemple suivant :The network policy now blocks all inbound traffic, so the page can't be loaded, as shown in the following example:

$ wget -qO- --timeout=2 http://backend

wget: download timed out

Quittez la session de terminal attachée.Exit out of the attached terminal session. Le pod de test est automatiquement supprimé.The test pod is automatically deleted.

exit

Autoriser le trafic entrant en fonction d’une étiquette de podAllow inbound traffic based on a pod label

À la section précédente, nous avons planifié un pod NGINX principal et créé une stratégie réseau destinée à refuser la totalité du trafic.In the previous section, a back-end NGINX pod was scheduled, and a network policy was created to deny all traffic. Créons à présent un pod frontal et mettons à jour la stratégie réseau de manière à autoriser le trafic provenant de pods frontaux.Let's create a front-end pod and update the network policy to allow traffic from front-end pods.

Mettez à jour la stratégie réseau pour autoriser le trafic provenant des pods étiquetés app:webapp,role:frontend et dans n’importe quel espace de noms.Update the network policy to allow traffic from pods with the labels app:webapp,role:frontend and in any namespace. Modifiez le précédent fichier backend-policy.yaml en y ajoutant des règles d’entrée matchLabels afin que votre manifeste ressemble à l’exemple suivant :Edit the previous backend-policy.yaml file, and add matchLabels ingress rules so that your manifest looks like the following example:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: webapp
          role: frontend

Notes

Cette stratégie de réseau utilise un élément namespaceSelector et un élément podSelector pour la règle d’entrée.This network policy uses a namespaceSelector and a podSelector element for the ingress rule. Pour que les règles d’entrée soient additives, la syntaxe YAML a une grande importance.The YAML syntax is important for the ingress rules to be additive. Dans cet exemple, les deux éléments doivent correspondre pour que la règle d’entrée soit appliquée.In this example, both elements must match for the ingress rule to be applied. Les versions de Kubernetes antérieures à 1.12 risquent de ne pas interpréter correctement ces éléments et de ne pas limiter le trafic réseau comme vous le souhaitez.Kubernetes versions prior to 1.12 might not interpret these elements correctly and restrict the network traffic as you expect. Pour plus d’informations sur ce comportement, consultez l’article Behavior of to and from selectors (Comportement des sélecteurs to et from).For more about this behavior, see Behavior of to and from selectors.

Appliquez la stratégie réseau mise à jour à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML :Apply the updated network policy by using the kubectl apply command and specify the name of your YAML manifest:

kubectl apply -f backend-policy.yaml

Planifiez un pod portant l’étiquette app=webapp,role=frontend et attachez une session de terminal :Schedule a pod that is labeled as app=webapp,role=frontend and attach a terminal session:

kubectl run --rm -it frontend --image=alpine --labels app=webapp,role=frontend --namespace development --generator=run-pod/v1

À l’invite de l’interpréteur de commandes, utilisez wget pour voir si vous pouvez accéder à la page web NGINX par défaut :At the shell prompt, use wget to see if you can access the default NGINX webpage:

wget -qO- http://backend

Étant donné que la règle d’entrée autorise le trafic avec les pods étiquetés app: webapp,role: frontend, le trafic provenant du pod frontal est autorisé.Because the ingress rule allows traffic with pods that have the labels app: webapp,role: frontend, the traffic from the front-end pod is allowed. L’exemple de sortie ci-après affiche la page web NGINX par défaut renvoyée :The following example output shows the default NGINX webpage returned:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Quittez la session de terminal attachée.Exit out of the attached terminal session. Le pod est automatiquement supprimé.The pod is automatically deleted.

exit

Tester un pod sans étiquette correspondanteTest a pod without a matching label

La stratégie réseau autorise le trafic provenant des pods étiquetés app: webapp,role: frontend, mais doit refuser tout autre trafic.The network policy allows traffic from pods labeled app: webapp,role: frontend, but should deny all other traffic. Vérifions si un autre pod dépourvu de cette étiquette peut ou non accéder au pod NGINX principal.Let's test to see whether another pod without those labels can access the back-end NGINX pod. Créez un autre pod de test et attachez une session de terminal :Create another test pod and attach a terminal session:

kubectl run --rm -it --image=alpine network-policy --namespace development --generator=run-pod/v1

À l’invite de l’interpréteur de commandes, utilisez wget pour voir si vous pouvez accéder à la page web NGINX par défaut.At the shell prompt, use wget to see if you can access the default NGINX webpage. La stratégie réseau bloque le trafic entrant, de sorte que la page ne peut pas être chargée, comme indiqué dans l’exemple suivant :The network policy blocks the inbound traffic, so the page can't be loaded, as shown in the following example:

$ wget -qO- --timeout=2 http://backend

wget: download timed out

Quittez la session de terminal attachée.Exit out of the attached terminal session. Le pod de test est automatiquement supprimé.The test pod is automatically deleted.

exit

Autoriser le trafic uniquement à partir d’un espace de noms définiAllow traffic only from within a defined namespace

Dans les exemples précédents, vous avez créé une stratégie réseau qui refusait tout trafic, puis vous avez mis à jour cette stratégie afin d’autoriser le trafic provenant de pods dotés d’une étiquette spécifique.In the previous examples, you created a network policy that denied all traffic, and then updated the policy to allow traffic from pods with a specific label. Par ailleurs, il se révèle souvent utile de limiter le trafic à un seul espace de noms.Another common need is to limit traffic to only within a given namespace. Si les précédents exemples se rapportaient au trafic dans un espace de noms development, vous allez à présent créer une stratégie réseau qui empêche le trafic provenant d’un autre espace de noms, tel que production, d’atteindre les pods.If the previous examples were for traffic in a development namespace, create a network policy that prevents traffic from another namespace, such as production, from reaching the pods.

En premier lieu, créez un espace de noms pour simuler un espace de noms de production :First, create a new namespace to simulate a production namespace:

kubectl create namespace production
kubectl label namespace/production purpose=production

Planifiez un pod de test dans l’espace de noms production qui est étiqueté en tant que app=webapp,role=frontend.Schedule a test pod in the production namespace that is labeled as app=webapp,role=frontend. Attachez une session de terminal :Attach a terminal session:

kubectl run --rm -it frontend --image=alpine --labels app=webapp,role=frontend --namespace production --generator=run-pod/v1

À l’invite de l’interpréteur de commandes, utilisez wget pour vérifier que vous pouvez accéder à la page web NGINX par défaut :At the shell prompt, use wget to confirm that you can access the default NGINX webpage:

wget -qO- http://backend.development

Dans la mesure où l’étiquette du pod correspond à ce qui est actuellement accordé dans la stratégie réseau, le trafic est autorisé.Because the labels for the pod match what is currently permitted in the network policy, the traffic is allowed. La stratégie réseau n’examine pas les espaces de noms, elle ne tient compte que des étiquettes de pod.The network policy doesn't look at the namespaces, only the pod labels. L’exemple de sortie ci-après affiche la page web NGINX par défaut renvoyée :The following example output shows the default NGINX webpage returned:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Quittez la session de terminal attachée.Exit out of the attached terminal session. Le pod de test est automatiquement supprimé.The test pod is automatically deleted.

exit

Mettre à jour la stratégie réseauUpdate the network policy

Mettons à jour la section namespaceSelector de la règle d’entrée de manière à n’autoriser que le trafic provenant de l’espace de noms development.Let's update the ingress rule namespaceSelector section to only allow traffic from within the development namespace. Modifiez le fichier manifeste backend-policy.yaml, comme indiqué dans l’exemple suivant :Edit the backend-policy.yaml manifest file as shown in the following example:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: development
      podSelector:
        matchLabels:
          app: webapp
          role: frontend

Dans des exemples plus complexes, vous pourriez définir plusieurs règles d’entrée, par exemple un élément namespaceSelector, puis un élément podSelector.In more complex examples, you could define multiple ingress rules, like a namespaceSelector and then a podSelector.

Appliquez la stratégie réseau mise à jour à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML :Apply the updated network policy by using the kubectl apply command and specify the name of your YAML manifest:

kubectl apply -f backend-policy.yaml

Tester la stratégie réseau mise à jourTest the updated network policy

Planifiez un autre pod dans l’espace de noms production et attachez une session de terminal :Schedule another pod in the production namespace and attach a terminal session:

kubectl run --rm -it frontend --image=alpine --labels app=webapp,role=frontend --namespace production --generator=run-pod/v1

À l’invite de l’interpréteur de commandes, utilisez wget pour vérifier que la stratégie réseau refuse désormais le trafic :At the shell prompt, use wget to see that the network policy now denies traffic:

$ wget -qO- --timeout=2 http://backend.development

wget: download timed out

Quittez le pod de test :Exit out of the test pod:

exit

En maintenant le refus sur le trafic provenant de l’espace de noms production, replanifiez un pod de test dans l’espace de noms development et attachez une session de terminal :With traffic denied from the production namespace, schedule a test pod back in the development namespace and attach a terminal session:

kubectl run --rm -it frontend --image=alpine --labels app=webapp,role=frontend --namespace development --generator=run-pod/v1

À l’invite de l’interpréteur de commandes, utilisez wget pour vérifier que la stratégie réseau autorise le trafic :At the shell prompt, use wget to see that the network policy allows the traffic:

wget -qO- http://backend

Le trafic est autorisé, car le pod est planifié dans l’espace de noms qui correspond à ce qui est autorisé dans la stratégie réseau.Traffic is allowed because the pod is scheduled in the namespace that matches what's permitted in the network policy. L’exemple de sortie ci-après affiche la page web NGINX par défaut renvoyée :The following sample output shows the default NGINX webpage returned:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Quittez la session de terminal attachée.Exit out of the attached terminal session. Le pod de test est automatiquement supprimé.The test pod is automatically deleted.

exit

Supprimer des ressourcesClean up resources

Dans cet article, nous avons créé deux espaces de noms et appliqué une stratégie réseau.In this article, we created two namespaces and applied a network policy. Pour nettoyer ces ressources, utilisez la commande kubectl delete et spécifiez les noms des ressources :To clean up these resources, use the kubectl delete command and specify the resource names:

kubectl delete namespace production
kubectl delete namespace development

Étapes suivantesNext steps

Pour plus d’informations sur les ressources réseau, consultez l’article Concepts de réseau pour les applications dans AKS (Azure Kubernetes Service).For more about network resources, see Network concepts for applications in Azure Kubernetes Service (AKS).

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