Protección del tráfico entre pods mediante directivas de red en AKS

Al ejecutar aplicaciones modernas basadas en microservicios en Kubernetes, con frecuenta querrá controlar qué componentes pueden comunicarse entre sí. El principio de privilegios mínimos debe aplicarse a cómo puede fluir el tráfico entre pods en un clúster Azure Kubernetes Service (AKS). Supongamos que quiere bloquear el tráfico directamente a las aplicaciones de back-end. La característica Directiva de red de Kubernetes permite definir las reglas de tráfico de entrada y salida entre los pods de un clúster.

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. Las directivas de red se pueden usar para nodos y pods basados en Linux o Windows en AKS.

Información general sobre la directiva de red

De forma predeterminada, todos los pods de un clúster de AKS pueden enviar y recibir tráfico sin limitaciones. Para mejorar la seguridad, puede definir reglas que controlen el flujo de tráfico. A menudo, las aplicaciones de back-end solo se exponen a los servicios front-end necesarios, por ejemplo. Además, los componentes de base de datos solo son accesibles para las capas de aplicación que se conectan a ellos.

Una directiva de red es una especificación de Kubernetes que define las directivas de acceso para la comunicación entre pods. Cuando se usan directivas de red, se define un conjunto ordenado de reglas para enviar y recibir tráfico. Las reglas se aplican a una colección de pods que coinciden con uno o varios selectores de etiquetas.

Las reglas de las directivas de red se definen como manifiestos de YAML. 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.

Opciones de directivas de red en AKS

Azure proporciona tres motores de directivas de red para aplicar directivas de red:

• Cilium para clústeres de AKS que usan Azure CNI con tecnología de Cilium.
• Azure Network Policy Manager.
• Calico, una solución de seguridad de red y red de código abierto fundada por Tigera.

Cilium es nuestro motor de directivas de red recomendado. Cilium aplica la directiva de red en el tráfico mediante el filtro de paquetes de Berkeley (BPF) de Linux, que generalmente es más eficaz que "IPTables". Consulte más detalles en la Documentación de Azure CNI con tecnología de Cilium.
Para aplicar las directivas especificadas, Azure Network Policy Manager para Linux usa IPTables de Linux. Azure Network Policy Manager para Windows usa ACLPolicies del servicio de red de host (HNS). Las directivas se traducen en conjuntos de pares de IP permitidas y no permitidas. Después, estos pares se programan como reglas de filtro de IPTable o HNS ACLPolicy.

Diferencias entre los motores de directivas de red: Cilium, Azure NPM y Calico

Funcionalidad	Azure Network Policy Manager	Calico	Cilium
Plataformas compatibles	Linux, Windows Server 2022 (versión preliminar).	Linux, Windows Server 2019 y 2022.	Linux.
Opciones de redes admitidas	Azure Container Networking Interface (CNI).	Azure CNI (Linux, Windows Server 2019 y 2022) y kubenet (Linux).	Azure CNI
Compatibilidad con la especificación de Kubernetes	Se admiten todos los tipos de directiva.	Se admiten todos los tipos de directiva.	Se admiten todos los tipos de directiva.
Otras características	Ninguno.	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. 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.	Ninguno.
Soporte técnico	Compatible con el soporte técnico de Azure y el equipo de ingeniería.	Compatible con el soporte técnico de Azure y el equipo de ingeniería.	Compatible con el soporte técnico de Azure y el equipo de ingeniería.

Limitaciones de Azure Network Policy Manager

Nota:

Con Azure NPM para Linux, no se permite el escalado más allá de 250 nodos y 20 000 pods. Si intenta escalar más allá de estos límites, puede experimentar errores de memoria insuficiente (OOM). Para mejorar la escalabilidad y la compatibilidad con IPv6, y si las siguientes limitaciones son motivo de preocupación, se recomienda usar o actualizar a Azure CNI Powered by Cilium para usar Cilium como motor de directivas de red.

Azure NPM no admite IPv6. De lo contrario, es totalmente compatible con las especificaciones de directiva de red en Linux.

En Windows, Azure NPM no admite las siguientes características de las especificaciones de directiva de red:

• Puertos con nombre.
• El protocolo de transmisión de control de flujo (SCTP).
• Etiquetas de coincidencia negativa o selectores de espacios de nombres. Por ejemplo, todas las etiquetas excepto debug=true.
• Bloques except de enrutamiento de interdominios sin clases (CIDR) (CIDR con excepciones).

Nota:

Los registros de pods de Azure Network Policy Manager registran un error si se crea una directiva de red no compatible.

Edición o eliminación de directivas de red

En algunos casos excepcionales, existe la posibilidad de que se produzca una condición de carrera que podría dar lugar a una conectividad temporal e inesperada para las nuevas conexiones a o desde pods en cualquier nodo afectado al editar o eliminar una directiva de red "suficientemente grande". Alcanzar esta condición de carrera nunca afecta a las conexiones activas.

Si se produce esta condición de carrera para un nodo, el pod de Azure NPM en ese nodo entra en un estado en el que no puede actualizar las reglas de seguridad, lo que podría provocar una conectividad inesperada para nuevas conexiones a o desde pods en el nodo afectado. Para mitigar el problema, el pod de Azure NPM se reinicia automáticamente aproximadamente 15 segundos después de entrar en este estado. Mientras Azure NPM se reinicia en el nodo afectado, elimina todas las reglas de seguridad y, a continuación, vuelve a aplicar las reglas de seguridad para todas las directivas de red. Mientras se vuelven a aplicar todas las reglas de seguridad, existe la posibilidad de que se produzca una conectividad temporal e inesperada para nuevas conexiones a o desde pods en el nodo afectado.

Para limitar la posibilidad de alcanzar esta condición de carrera, puede reducir el tamaño de la directiva de red. Este problema es más probable que se produzca para una directiva de red con varias secciones ipBlock. Es menos probable que una directiva de red con cuatro o menos secciones ipBlock alcance el problema.

Antes de empezar

Es preciso que esté instalada y configurada la versión 2.0.61 de la CLI de Azure u otra versión posterior. Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.

Creación de un clúster de AKS y habilitación de la directiva de red

Para ver las directivas de red en acción, cree un clúster de AKS que admita la directiva de red y, después, trabaje en la adición de directivas.

Para usar Azure Network Policy Manager, debe usar el complemento de Azure CNI. Calico se puede usar con un complemento de Azure CNI o con el complemento de CNI de Kubenet.

El siguiente script de ejemplo crea un clúster de AKS con identidad asignada por el sistema y habilita la directiva de red mediante Azure Network Policy Manager.

Nota:

Calico se puede usar con los parámetros --network-plugin azure o --network-plugin kubenet.

En lugar de usar una identidad asignada por el sistema, también puede usar una identidad asignada por el usuario. Para más información, consulte Uso de identidades administradas.

Creación de un clúster de AKS con Azure Network Policy Manager habilitado: solo Linux

En esta sección, creará un clúster con grupos de nodos de Linux y Azure Network Policy Manager habilitado.

Para empezar, reemplace los valores de las variables $RESOURCE_GROUP_NAME y $CLUSTER_NAME.

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

Cree el clúster de AKS y especifique azure para network-plugin y network-policy.

Use el comando siguiente para crear un clúster:

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

Creación de un clúster de AKS con Azure Network Policy Manager habilitado: Windows Server 2022 (versión preliminar)

En esta sección, creará un clúster con grupos de nodos de Windows y Azure Network Policy Manager habilitado.

Nota:

Azure Network Policy Manager con nodos de Windows solo está disponible en Windows Server 2022.

Instalación de la versión preliminar de la extensión de la CLI de Azure en versión preliminar de AKS

Importante

Las características en versión preliminar de AKS están disponibles como opción de participación y autoservicio. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y garantía limitada. Las versiones preliminares de AKS reciben cobertura parcial del soporte al cliente en la medida de lo posible. Por lo tanto, estas características no están diseñadas para su uso en producción. Para más información, consulte los siguientes artículos de soporte:

• Directivas de soporte técnico para AKS
• Preguntas más frecuentes de Soporte técnico de Azure

Para instalar la extensión aks-preview, ejecute el siguiente comando:

az extension add --name aks-preview

Para actualizar a la versión más reciente de la extensión publicada, ejecute el siguiente comando:

az extension update --name aks-preview

Registro de la marca de característica WindowsNetworkPolicyPreview

Registre la marca de la característica WindowsNetworkPolicyPreview con el comando WindowsNetworkPolicyPreview, como se muestra en el siguiente ejemplo:

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

Tarda unos minutos en que el estado muestre Registrado. Para comprobar el estado de registro se usa el comandoaz feature show:

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

Cuando el estado se muestre como Registrado, actualice el registro del proveedor de recursos Microsoft.ContainerService mediante el comando az provider register:

az provider register --namespace Microsoft.ContainerService

Creación del clúster de AKS

Ahora, reemplace los valores de las variables $RESOURCE_GROUP_NAME, $CLUSTER_NAME y $WINDOWS_USERNAME.

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

Cree un nombre de usuario para usarlo como credenciales de administrador para los contenedores de Windows Server en el clúster. El comando siguiente le solicita un nombre de usuario. Establézcalo en $WINDOWS_USERNAME. Recuerde que los comandos de este artículo se han agregado a un shell de Bash.

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

Use el comando siguiente para crear un clúster:

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 operación de creación del clúster tarda unos minutos. De manera predeterminada, el clúster se crea solo con un grupo de nodos de Linux. Si quiere usar grupos de nodos de Windows, puede agregar uno. Este es un ejemplo:

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

Creación de un clúster de AKS con Calico habilitado

Cree el clúster de AKS y especifique --network-plugin azure y --network-policy calico. Especificar --network-policy calico habilita Calico en grupos de nodos de Linux y Windows.

Si planea agregar grupos de nodos de Windows al clúster, incluya los parámetros windows-admin-username y windows-admin-passwordque cumplan los requisitos de contraseña de Windows Server.

Importante

En estos momentos, el uso de directivas de red de Calico con nodos de Windows está disponible en los clústeres nuevos usando la versión 1.20 o posterior de Kubernetes con Calico 3.17.2, y requiere el uso de redes de Azure CNI. Los nodos de Windows en clústeres de AKS con Calico habilitado también tienen habilitada la dirección IP flotante de forma predeterminada.

En el caso de los clústeres que solo tienen grupos de nodos de Linux que ejecutan Kubernetes 1.20 con versiones anteriores de Calico, la versión de Calico se actualiza automáticamente a la versión 3.17.2.

Cree un nombre de usuario para usarlo como credenciales de administrador para los contenedores de Windows Server en el clúster. El comando siguiente le solicita un nombre de usuario. Establézcalo en $WINDOWS_USERNAME. Recuerde que los comandos de este artículo se han agregado a un shell de 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 operación de creación del clúster tarda unos minutos. De manera predeterminada, el clúster se crea solo con un grupo de nodos de Linux. Si quiere usar grupos de nodos de Windows, puede agregar uno. Por ejemplo:

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

Instalación de Azure Network Policy Manager o Calico en un clúster existente

También se admite la instalación de Azure Network Policy Manager o Calico en clústeres de AKS existentes.

Advertencia

El proceso de actualización desencadena que se vuelva a crear la imagen inicial de cada grupo de nodos simultáneamente. No se admite la actualización de cada grupo de nodos por separado. Las interrupciones en las redes de clúster son similares a una actualización de imagen de nodo o a una actualización de la versión de Kubernetes en la que se volverá a crear la imagen de cada nodo de un grupo de nodos.

Comando de ejemplo para instalar Azure Network Policy Manager:

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

Comando de ejemplo para instalar Calico:

Advertencia

Esta advertencia se aplica a la actualización de clústeres de Kubenet con Calico habilitado para Superposición de Azure CNI con Calico habilitado.

• En clústeres de Kubenet con Calico habilitado, Calico se usa como motor de directivas de red y CNI.
• En los clústeres de Azure CNI, Calico solo se usa para la aplicación de directivas de red, no como CNI. Esto puede provocar un breve retraso entre cuando se inicia el pod y cuando Calico permite el tráfico saliente desde el pod.

Se recomienda usar Cilium en lugar de Calico para evitar este problema. Más información sobre Cilium en Azure CNI con tecnología de Cilium

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

Actualización de un clúster existente con Azure NPM o Calico instalado en Azure CNI con tecnología de Cilium

Para actualizar un clúster existente que tenga instalado el motor de directivas de red en Azure CNI con tecnología de Cilium, consulte Actualización de un clúster existente a Azure CNI con tecnología de Cilium

Comprobación de la configuración de directivas de red

Cuando el clúster esté listo, configure kubectl para conectarse a su clúster de Kubernetes con el comando az aks get-credentials. Con este comando se descargan las credenciales y se configura la CLI de Kubernetes para usarlas:

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

Para comenzar la comprobación de la directiva de red, creará una aplicación de ejemplo y establecerá reglas de tráfico.

Primero, cree un espacio de nombres llamado demo para ejecutar los pods de ejemplo:

kubectl create namespace demo

Ahora cree dos pods en el clúster denominados client y server.

Nota:

Si quiere programar el cliente o el servidor en un nodo determinado, agregue el siguiente bit antes del argumento --command en el comando kubectl run de creación de pods:

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

Cree un pod server. Este pod usa el puerto 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"

Cree un pod client. El siguiente comando ejecuta Bash en el pod client:

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

Ahora, en una ventana independiente, ejecute el siguiente comando para obtener la dirección IP del servidor:

kubectl get pod --output=wide -n demo

La salida debe ser similar a la siguiente:

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

Prueba de la conectividad sin directiva de red

En el shell del cliente, ejecute el siguiente comando para comprobar la conectividad con el servidor. Reemplace server-ip por la dirección IP que se proporciona en la salida de la ejecución del comando anterior. Si la conexión se realiza correctamente, no hay ninguna salida.

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

Prueba de la conectividad con directiva de red

Para agregar directivas de red, cree un archivo denominado demo-policy.yaml y pegue el siguiente manifiesto de YAML:

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

Especifique el nombre del manifiesto YAML y aplíquelo mediante kubectl apply:

kubectl apply –f demo-policy.yaml

Ahora, en el shell del cliente, ejecute el siguiente comando /agnhost para comprobar la conectividad con el servidor:

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

La conectividad con el tráfico se bloquea porque el servidor está etiquetado con app=server, pero el cliente no está etiquetado. El comando connect anterior produce esta salida:

TIMEOUT

Ejecute el siguiente comando para etiquetar el client y comprobar la conectividad con el servidor. La salida no debe devolver nada.

kubectl label pod client -n demo app=client

Desinstalación de Azure Network Policy Manager o Calico

Requisitos:

• CLI de Azure, versión 2.63 o posterior

Nota:

• El proceso de desinstalación no quita definiciones de recursos personalizados (CRD) ni recursos personalizados (RC) usados por Calico. Todos estos CRD y RC tienen nombres que terminan con "projectcalico.org" o "tigera.io". Estos CRD y los RC asociados se pueden eliminar manualmente después de que Calico se desinstale correctamente (eliminar los CRD antes de quitar Calico interrumpe el clúster).
• La actualización no quitará ningún recurso de NetworkPolicy en el clúster, pero después de la desinstalación estas directivas ya no se aplican.

Advertencia

El proceso de actualización desencadena que se vuelva a crear la imagen inicial de cada grupo de nodos simultáneamente. No se admite la actualización de cada grupo de nodos por separado. Las interrupciones en las redes de clúster son similares a una actualización de imagen de nodo o a una actualización de la versión de Kubernetes en la que se volverá a crear la imagen de cada nodo de un grupo de nodos.

Para quitar Azure Network Policy Manager o Calico de un clúster, ejecute el siguiente comando:

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

Limpieza de recursos

En este artículo, ha creado un espacio de nombres y dos pods, y ha aplicado una directiva de red. Para limpiar estos recursos, use el comando kubectl delete y especifique el nombre de recurso:

kubectl delete namespace demo

Pasos siguientes

Para obtener más información sobre los recursos red, consulte Conceptos de redes de aplicaciones en Azure Kubernetes Service (AKS).

Para más información sobre las directivas, consulte las directivas de red de Kubernetes.