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 la manera en que el tráfico puede fluir entre pods de un clúster de Azure Kubernetes Service (AKS). Supongamos que quiere bloquear el tráfico directamente a las aplicaciones de back-end. La característica de directiva de red de Kubernetes le permite definir reglas para el tráfico de entrada y salida entre 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 Powered by Cilium.
• Administrador de directivas de red de Azure.
• 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 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

Limitaciones de Azure Network Policy Manager

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

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 menosipBlock secciones alcance el problema.

Filtrado del equilibrador de carga o el tráfico de servicio

El enrutamiento del servicio Kubernetes para los servicios entrantes y salientes suele implicar la reescritura de las direcciones IP de origen y destino en el tráfico que se está procesando, incluido el tráfico que entra en el clúster desde un servicio LoadBalancer. Este comportamiento de reescritura significa que es posible que las directivas de red no procesen correctamente el tráfico que se recibe o se envía a un servicio externo (consulte la documentación de directivas de red de Kubernetes para obtener más detalles).

Para restringir qué orígenes pueden enviar tráfico a un servicio de equilibrador de carga, use el spec.loadBalancerSourceRanges para configurar el bloqueo de tráfico que se aplica antes de que se produzcan reescrituras. Puede encontrar más información en la documentación del equilibrador de carga estándar de AKS .

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. Para encontrar la versión, ejecute az --version. 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.

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

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

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 az feature register, 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 refleje Registrado, actualice el registro del Microsoft.ContainerService proveedor de recursos 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.

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.

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:

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.

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

Traslado a Calico autoadministrado

Como se muestra en las otras características de la tabla, AKS solo admite Calico para las directivas de red estándar de Kubernetes y no prueba otras características. Si quiere pasar a Calico autoadministrado, siga las instrucciones de Tiegra en Migración de Calico administrado por Azure a Calico autoadministrado. La documentación de Tiegra menciona que, para Calico autoadministrado, se establece --network-policy none como en la sección de desinstalación.

Desinstalación de Azure Network Policy Manager o Calico

Requirements:

• CLI de Azure, versión 2.63 o posterior

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 del recurso:

kubectl delete namespace demo

Pasos siguientes

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

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