Protección del tráfico entre pods mediante directivas de red en Azure Kubernetes Service (AKS)Secure traffic between pods using network policies in Azure Kubernetes Service (AKS)

Al ejecutar aplicaciones modernas basadas en microservicios en Kubernetes, con frecuenta querrá controlar qué componentes pueden comunicarse entre sí.When you run modern, microservices-based applications in Kubernetes, you often want to control which components can communicate with each other. El principio de privilegios mínimos debe aplicarse a la manera en que el tráfico puede fluir entre pods de un clúster de 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. Supongamos que quiere bloquear el tráfico directamente a las aplicaciones de back-end.Let's say you likely want to block traffic directly to back-end applications. La característica Directiva de red de Kubernetes permite definir las reglas de tráfico de entrada y salida entre pods de un clúster.The Network Policy feature in Kubernetes lets you define rules for ingress and egress traffic between pods in a cluster.

En este artículo se muestra cómo instalar el motor de directiva de red y cómo crear directivas de red de Kubernetes para controlar el flujo de tráfico entre pods en 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. La directiva de red solo se debe usar para los pods y los nodos basados en Linux de AKS.Network policy should only be used for Linux-based nodes and pods in AKS.

Antes de empezarBefore you begin

Es preciso que esté instalada y configurada la versión 2.0.61 de la CLI de Azure u otra versión posterior.You need the Azure CLI version 2.0.61 or later installed and configured. Ejecute  az --version para encontrar la versión.Run az --version to find the version. Si necesita instalarla o actualizarla, consulte  Install Azure CLI (Instalación de la CLI de Azure).If you need to install or upgrade, see Install Azure CLI.

Sugerencia

Si usó la característica de directiva de red en la versión preliminar, se recomienda que cree un clúster.If you used the network policy feature during preview, we recommend that you create a new cluster.

Si quiere seguir usando los clústeres de prueba existentes que usaban la directiva de red en la versión preliminar, actualice el clúster a una nueva versión de Kubernetes para la versión de disponibilidad general más reciente y, luego, implemente el siguiente manifiesto de YAML para corregir el bloqueo del servidor de métricas y del panel de 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. Esta corrección solo es necesaria para los clústeres que usaban el motor de directiva de red de Calico.This fix is only required for clusters that used the Calico network policy engine.

Como procedimiento recomendado de seguridad, revise el contenido de este manifiesto de YAML para entender qué se implementa en el clúster de 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

Información general sobre la directiva de redOverview of network policy

De forma predeterminada, todos los pods de un clúster de AKS pueden enviar y recibir tráfico sin limitaciones.All pods in an AKS cluster can send and receive traffic without limitations, by default. Para mejorar la seguridad, puede definir reglas que controlen el flujo de tráfico.To improve security, you can define rules that control the flow of traffic. A menudo, las aplicaciones de back-end solo se exponen a los servicios front-end necesarios, por ejemplo.Back-end applications are often only exposed to required front-end services, for example. Además, los componentes de base de datos solo son accesibles para las capas de aplicación que se conectan a ellos.Or, database components are only accessible to the application tiers that connect to them.

La directiva de red es una especificación de Kubernetes que define las directivas de acceso para la comunicación entre pods.Network Policy is a Kubernetes specification that defines access policies for communication between Pods. Con las directivas de red, puede definir un conjunto ordenado de reglas para enviar y recibir tráfico y aplicarlas a una colección de pods que coincidan con uno o varios selectores de etiqueta.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.

Estas reglas de las directivas de red se definen como manifiestos de YAML.These network policy rules are defined as YAML manifests. Las directivas de red se pueden incluir como parte de un manifiesto más amplio que también crea una implementación o un servicio.Network policies can be included as part of a wider manifest that also creates a deployment or service.

Opciones de directivas de red en AKSNetwork policy options in AKS

Azure ofrece dos maneras de implementar la directiva de red.Azure provides two ways to implement network policy. Debe elegir una opción de directiva de red al crear un clúster de AKS.You choose a network policy option when you create an AKS cluster. La opción de directiva no se puede cambiar una vez que se ha creado el clúster:The policy option can't be changed after the cluster is created:

  • La implementación propia de Azure, denominada directivas de red de Azure.Azure's own implementation, called Azure Network Policies.
  • Directivas de red de Calico, una solución de seguridad de red y redes de código abierto fundada por Tigera.Calico Network Policies, an open-source network and network security solution founded by Tigera.

Ambas implementaciones usan IPTables de Linux para aplicar las directivas especificadas.Both implementations use Linux IPTables to enforce the specified policies. Las directivas se traducen en conjuntos de pares de IP permitidas y no permitidas.Policies are translated into sets of allowed and disallowed IP pairs. Después, estos pares se programan como reglas de filtro de IPTable.These pairs are then programmed as IPTable filter rules.

Diferencias entre las directivas de Azure y Calico y sus funcionalidadesDifferences between Azure and Calico policies and their capabilities

CapacidadCapability AzureAzure CalicoCalico
Plataformas compatiblesSupported platforms LinuxLinux LinuxLinux
Opciones de redes admitidasSupported networking options CNI de AzureAzure CNI CNI de Azure y kubenetAzure CNI and kubenet
Compatibilidad con la especificación de KubernetesCompliance with Kubernetes specification Se admiten todos los tipos de directiva.All policy types supported Se admiten todos los tipos de directiva.All policy types supported
Características adicionalesAdditional features NoneNone Modelo de directiva extendida que consta de una directiva de red global, un conjunto de red global y un punto de conexión de host.Extended policy model consisting of Global Network Policy, Global Network Set, and Host Endpoint. Para más información sobre el uso de la CLI de calicoctl para administrar estas características extendidas, consulte la referencia de usuario de calicoctl.For more information on using the calicoctl CLI to manage these extended features, see calicoctl user reference.
Soporte técnicoSupport Compatible con el soporte técnico de Azure y el equipo de ingenieríaSupported by Azure support and Engineering team Soporte técnico de la comunidad de Calico.Calico community support. Para más información sobre el soporte técnico de pago adicional, consulte las opciones de soporte técnico del proyecto Calico.For more information on additional paid support, see Project Calico support options.
RegistroLogging Las reglas agregadas o eliminadas en IPTables se registran en cada host en /var/log/azure-npm.logRules added / deleted in IPTables are logged on every host under /var/log/azure-npm.log Para más información, consulte los registros de los componentes de Calico.For more information, see Calico component logs

Creación de un clúster de AKS y habilitación de la directiva de redCreate an AKS cluster and enable network policy

Para ver las directivas de red en acción, vamos a crear y luego expandir una directiva que define el flujo de tráfico:To see network policies in action, let's create and then expand on a policy that defines traffic flow:

  • Deniegue todo el tráfico al pod.Deny all traffic to pod.
  • Permita el tráfico en función de las etiquetas de pod.Allow traffic based on pod labels.
  • Permita el tráfico según el espacio de nombres.Allow traffic based on namespace.

En primer lugar, crearemos un clúster de AKS que admite la directiva de red.First, let's create an AKS cluster that supports network policy.

Importante

La característica de directiva de red solo se puede habilitar cuando se crea el clúster.The network policy feature can only be enabled when the cluster is created. No se puede habilitar la directiva de red en un clúster de AKS existente.You can't enable network policy on an existing AKS cluster.

Para usar la directiva de red de Azure, debe usar el complemento CNI de Azure y definir su propia red virtual y subredes.To use Azure Network Policy, you must use the Azure CNI plug-in and define your own virtual network and subnets. Para más información sobre cómo planear los rangos de subred requeridos, consulte la sección sobre cómo configurar redes avanzadas.For more detailed information on how to plan out the required subnet ranges, see configure advanced networking. La directiva de red de Calico se puede usar con este mismo complemento CNI de Azure o con el complemento CNI de Kubenet.Calico Network Policy could be used with either this same Azure CNI plug-in or with the Kubenet CNI plug-in.

En el ejemplo siguiente se invoca el script:The following example script:

  • Crea una red virtual y una subred.Creates a virtual network and subnet.
  • Crea una entidad de servicio de Azure Active Directory (Azure AD) para usarse con el clúster de AKS.Creates an Azure Active Directory (Azure AD) service principal for use with the AKS cluster.
  • Asigna permisos de colaborador para la entidad de servicio de clúster de AKS en la red virtual.Assigns Contributor permissions for the AKS cluster service principal on the virtual network.
  • Crea un clúster de AKS en la red virtual definida y habilita la directiva de red.Creates an AKS cluster in the defined virtual network and enables network policy.
    • Se usa la opción de directiva de Red de Azure.The Azure Network policy option is used. Para usar Calico como opción de directiva de red, use el parámetro --network-policy calico.To use Calico as the network policy option instead, use the --network-policy calico parameter. Nota: Calico se puede usar con --network-plugin azure o --network-plugin kubenet.Note: Calico could be used with either --network-plugin azure or --network-plugin kubenet.

Recuerde que en lugar de una entidad de servicio, puede usar una identidad administrada para los permisos.Note that instead of using a service principal, you can use a managed identity for permissions. Para más información, consulte Uso de identidades administradas.For more information, see Use managed identities.

Proporcione su propia variable segura SP_PASSWORD.Provide your own secure SP_PASSWORD. Puede reemplazar las variables RESOURCE_GROUP_NAME y 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 operación de creación del clúster tarda unos minutos.It takes a few minutes to create the cluster. Cuando el clúster esté listo, configure kubectl para conectarse a su clúster de Kubernetes con el comando 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. Con este comando se descargan las credenciales y se configura la CLI de Kubernetes para usarlas:This command downloads credentials and configures the Kubernetes CLI to use them:

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

Denegación de todo el tráfico entrante a un podDeny all inbound traffic to a pod

Antes de definir reglas para permitir el tráfico de red específico, primero cree una directiva de red para denegar todo el tráfico.Before you define rules to allow specific network traffic, first create a network policy to deny all traffic. Esta directiva proporciona un punto inicial para empezar a crear una lista de admisión solo para el tráfico deseado.This policy gives you a starting point to begin to create an allow list for only the desired traffic. También puede ver claramente que el tráfico se descarta cuando se aplica la directiva de red.You can also clearly see that traffic is dropped when the network policy is applied.

En lo que respecta al entorno de aplicación de ejemplo y a las reglas de tráfico, vamos a crear un espacio de nombres denominado development para ejecutar los pods de ejemplo: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

Cree un pod de back-end de ejemplo que ejecute NGINX.Create an example back-end pod that runs NGINX. Este pod de back-end puede usarse para simular una aplicación web de back-end de ejemplo.This back-end pod can be used to simulate a sample back-end web-based application. Cree este pod en el espacio de nombres development y abra el puerto 80 para atender el tráfico web.Create this pod in the development namespace, and open port 80 to serve web traffic. Etiquete el pod con app=webapp,role=backend para que podamos utilizarlo como destino con una directiva de red en la sección siguiente: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

Cree otro pod y asocie una sesión de terminal para probar que puede llegar correctamente a la página web de NGINX predeterminada: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

Cuando se encuentre en el símbolo del sistema del shell, use wget para confirmar que puede acceder a la página web de NGINX predeterminada:At the shell prompt, use wget to confirm that you can access the default NGINX webpage:

wget -qO- http://backend

La siguiente salida de ejemplo muestra que se devuelve la página web de NGINX predeterminada:The following sample output shows that the default NGINX webpage returned:

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

Salga de la sesión de terminal asociada.Exit out of the attached terminal session. El pod de prueba se elimina automáticamente.The test pod is automatically deleted.

exit

Creación y aplicación de una directiva de redCreate and apply a network policy

Ahora que ha confirmado que usar la página web de NGINX básica en el pod de back-end de ejemplo, cree una directiva de red para denegar todo el tráfico.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. Cree un archivo denominado backend-policy.yaml y pegue el siguiente manifiesto de YAML.Create a file named backend-policy.yaml and paste the following YAML manifest. Este manifiesto usa un elemento podSelector para asociar la directiva a los pods que tienen la etiqueta app:webapp,role:backend, como el pod de NGINX de ejemplo.This manifest uses a podSelector to attach the policy to pods that have the app:webapp,role:backend label, like your sample NGINX pod. No hay reglas definidas en ingress, por lo que se deniega todo el tráfico entrante en el pod: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: []

Vaya a https://shell.azure.com para abrir Azure Cloud Shell en el explorador.Go to https://shell.azure.com to open Azure Cloud Shell in your browser.

Aplique la directiva de red mediante el comando kubectl apply y especifique el nombre del manifiesto de 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

Prueba de la directiva de redTest the network policy

Comprobemos que puede usar la página web de NGINX en el pod de back-end de nuevo.Let's see if you can use the NGINX webpage on the back-end pod again. Cree otro pod de prueba y asocie una sesión de terminal:Create another test pod and attach a terminal session:

kubectl run --rm -it --image=alpine network-policy --namespace development

Cuando se encuentre en el símbolo del sistema del shell, use wget para ver si puede acceder a la página web de NGINX predeterminada.At the shell prompt, use wget to see if you can access the default NGINX webpage. Esta vez, establezca un valor de tiempo de expiración de 2 segundos.This time, set a timeout value to 2 seconds. Ahora, la directiva de red bloquea todo el tráfico entrante, por lo que no se puede cargar la página, tal como se muestra en el ejemplo siguiente: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

Salga de la sesión de terminal asociada.Exit out of the attached terminal session. El pod de prueba se elimina automáticamente.The test pod is automatically deleted.

exit

Tráfico entrante permitido en función de una etiqueta de podAllow inbound traffic based on a pod label

En la sección anterior, se programó un pod de NGINX de back-end y se creó una directiva de red para denegar todo el tráfico.In the previous section, a back-end NGINX pod was scheduled, and a network policy was created to deny all traffic. Vamos a crear un pod de front-end y actualizar la directiva de red para permitir el tráfico desde los pods de front-end.Let's create a front-end pod and update the network policy to allow traffic from front-end pods.

Actualice la directiva de red para permitir el tráfico desde los pods con las etiquetas app:webapp,role:frontend y en cualquier espacio de nombres.Update the network policy to allow traffic from pods with the labels app:webapp,role:frontend and in any namespace. Edite el anterior archivo backend-policy.yaml y agregue unas reglas de entrada matchLabels para que el manifiesto sea similar al ejemplo siguiente: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

Nota

Esta directiva de red usa un elemento namespaceSelector y un elemento podSelector para la regla de entrada.This network policy uses a namespaceSelector and a podSelector element for the ingress rule. La sintaxis YAML es importante para que las reglas de entrada sean aditivas.The YAML syntax is important for the ingress rules to be additive. En este ejemplo, ambos elementos deben coincidir para que se aplique la regla de entrada.In this example, both elements must match for the ingress rule to be applied. Puede que las versiones de Kubernetes anteriores a 1.12 no interpreten correctamente estos elementos y no restrinjan el tráfico de red según lo esperado.Kubernetes versions prior to 1.12 might not interpret these elements correctly and restrict the network traffic as you expect. Para más información sobre este comportamiento, consulte Behavior of to and from selectors (Comportamiento de los selectores to y from).For more about this behavior, see Behavior of to and from selectors.

Aplique la política de red actualizada mediante el comando kubectl apply y especifique el nombre del manifiesto de 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

Programe un pod que se etiquete como app=webapp,role=frontend y asocie una sesión 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

Cuando se encuentre en el símbolo del sistema del shell, use wget para ver si puede acceder a la página web de NGINX predeterminada:At the shell prompt, use wget to see if you can access the default NGINX webpage:

wget -qO- http://backend

Como la regla de entrada permite el tráfico con los pods que tengan las etiquetas app: webapp,role: frontend, se permite el tráfico desde el pod de front-end.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. La siguiente salida de ejemplo muestra que se devuelve la página web de NGINX predeterminada:The following example output shows the default NGINX webpage returned:

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

Salga de la sesión de terminal asociada.Exit out of the attached terminal session. El pod se elimina automáticamente.The pod is automatically deleted.

exit

Prueba de un pod sin una etiqueta coincidenteTest a pod without a matching label

La directiva de red permite el tráfico desde los pods con la etiqueta app: webapp,role: frontend, pero debe denegar todo el tráfico.The network policy allows traffic from pods labeled app: webapp,role: frontend, but should deny all other traffic. Vamos a realizar una prueba para ver si otro pod sin esas etiquetas puede acceder al pod de NGINX de back-end.Let's test to see whether another pod without those labels can access the back-end NGINX pod. Cree otro pod de prueba y asocie una sesión de terminal:Create another test pod and attach a terminal session:

kubectl run --rm -it --image=alpine network-policy --namespace development

Cuando se encuentre en el símbolo del sistema del shell, use wget para ver si puede acceder a la página web de NGINX predeterminada.At the shell prompt, use wget to see if you can access the default NGINX webpage. La directiva de red bloquea el tráfico entrante, por lo que no se puede cargar la página, tal como se muestra en el ejemplo siguiente: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

Salga de la sesión de terminal asociada.Exit out of the attached terminal session. El pod de prueba se elimina automáticamente.The test pod is automatically deleted.

exit

Tráfico permitido solo desde dentro de un espacio de nombres definidoAllow traffic only from within a defined namespace

En los ejemplos anteriores, creó una directiva de red que denegaba todo el tráfico y, después, actualizó la directiva para permitir el tráfico desde los pods con una etiqueta específica.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. Otra de las cosas que se suele necesitar es limitar el tráfico a solo dentro de un espacio de nombres especificado.Another common need is to limit traffic to only within a given namespace. Si los ejemplos anteriores eran para el tráfico en un espacio de nombres development, cree una directiva de red que impida que el tráfico de otro espacio de nombres, como production, llegue a los 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 primer lugar, cree un espacio de nombres para simular un espacio de nombres production:First, create a new namespace to simulate a production namespace:

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

Programe un pod de prueba en el espacio de nombres production que está etiquetado como app=webapp,role=frontend.Schedule a test pod in the production namespace that is labeled as app=webapp,role=frontend. Asocie una sesión de terminal:Attach a terminal session:

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

Cuando se encuentre en el símbolo del sistema del shell, use wget para confirmar que puede acceder a la página web de NGINX predeterminada:At the shell prompt, use wget to confirm that you can access the default NGINX webpage:

wget -qO- http://backend.development

Como las etiquetas del pod coinciden con lo que actualmente está permitido en la directiva de red, se permite el tráfico.Because the labels for the pod match what is currently permitted in the network policy, the traffic is allowed. La directiva de red no analiza los espacios de nombres, solo las etiquetas de pod.The network policy doesn't look at the namespaces, only the pod labels. La siguiente salida de ejemplo muestra que se devuelve la página web de NGINX predeterminada:The following example output shows the default NGINX webpage returned:

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

Salga de la sesión de terminal asociada.Exit out of the attached terminal session. El pod de prueba se elimina automáticamente.The test pod is automatically deleted.

exit

Actualización de la directiva de redUpdate the network policy

Vamos a actualizar la sección namespaceSelector de la regla de entrada para permitir únicamente el tráfico desde el espacio de nombres development.Let's update the ingress rule namespaceSelector section to only allow traffic from within the development namespace. Edite el archivo de manifiesto backend-policy.yaml, como se muestra en el ejemplo siguiente: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

En ejemplos más complejos, podría definir varias reglas de entrada, como un elemento namespaceSelector y, después, un elemento podSelector.In more complex examples, you could define multiple ingress rules, like a namespaceSelector and then a podSelector.

Aplique la política de red actualizada mediante el comando kubectl apply y especifique el nombre del manifiesto de 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

Prueba de la directiva de red actualizadaTest the updated network policy

Programe otro pod en el espacio de nombres production y asocie una sesión 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

Una vez en el símbolo del sistema del shell, use wget para ver que ahora la directiva de red deniega el tráfico: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

Salga del pod de prueba:Exit out of the test pod:

exit

Con el tráfico denegado desde el espacio de nombres production, programe de nuevo un pod de prueba en el espacio de nombres development y asocie una sesión 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

Una vez en el símbolo del sistema del shell, use wget para ver que la directiva de red permite el tráfico:At the shell prompt, use wget to see that the network policy allows the traffic:

wget -qO- http://backend

El tráfico se permite porque el pod está programado en el espacio de nombres que coincide con lo permitido en la directiva de red.Traffic is allowed because the pod is scheduled in the namespace that matches what's permitted in the network policy. En la siguiente salida de ejemplo se muestra que se devuelve la página web de NGINX predeterminada:The following sample output shows the default NGINX webpage returned:

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

Salga de la sesión de terminal asociada.Exit out of the attached terminal session. El pod de prueba se elimina automáticamente.The test pod is automatically deleted.

exit

Limpieza de recursosClean up resources

En este artículo, hemos creado dos espacios de nombres y hemos aplicado una directiva de red.In this article, we created two namespaces and applied a network policy. Para limpiar estos recursos, use el comando kubectl delete y especifique los nombres de recurso:To clean up these resources, use the kubectl delete command and specify the resource names:

kubectl delete namespace production
kubectl delete namespace development

Pasos siguientesNext steps

Para más información sobre los recursos red, consulte Conceptos de redes de aplicaciones en Azure Kubernetes Service (AKS).For more about network resources, see Network concepts for applications in Azure Kubernetes Service (AKS).

Para más información sobre las directivas, consulte las directivas de red de Kubernetes.To learn more about policies, see Kubernetes network policies.