Procedimientos recomendados para la conectividad de red y la seguridad en Azure Kubernetes Service (AKS)

A medida que crea y administra clústeres en Azure Kubernetes Service (AKS), proporciona conectividad de red para los nodos y las aplicaciones. Estos recursos de red incluyen los intervalos de direcciones IP, los equilibradores de carga y los controladores de entrada.

Este artículo de procedimientos recomendados se centra en la conectividad de red y la seguridad para los operadores del clúster. En este artículo aprenderá a:

Elección del modelo de red adecuado

Guía de procedimientos recomendados

Use Azure CNI Overlay en la mayoría de los escenarios. Si las cargas de trabajo requieren acceso directo a la IP del pod desde las redes conectadas, utilice una red plana con Azure CNI Pod Subnet.

Las redes virtuales proporcionan conectividad básica para que los nodos de AKS y los clientes accedan a las aplicaciones. Hay dos maneras diferentes de implementar los clústeres de AKS en redes virtuales:

• Red de superposición: Azure CNI Overlay asigna direcciones IP a los pods desde un CIDR independiente para pods. El tráfico que sale del clúster se traduce a la dirección IP del nodo y los pods no son accesibles directamente por sus direcciones IP privadas desde redes conectadas.
• Red plana: Azure CNI Pod Subnet o Azure CNI Node Subnet heredado asigna direcciones IP a los pods desde el espacio de la red virtual. Se puede acceder a los pods mediante sus direcciones IP privadas desde redes conectadas.

Para obtener más información sobre cómo seleccionar un modelo de red, consulte Planificación de redes de pods para AKS.

Introducción a las redes de CNI de Azure

Azure CNI proporciona administración de direcciones IP (IPAM) y conectividad para pods y nodos. La opción IPAM es independiente del plano de datos de red. Por ejemplo, puede usar Azure CNI basado en Cilium con Azure CNI Overlay o una opción de red plana.

En el diagrama siguiente se muestran dos nodos de AKS, cada uno conectado a través de un puente de red a una red virtual compartida Azure.

La red de Azure CNI permite separar el control y la gestión de los recursos. Desde una perspectiva de seguridad, se suele preferir que distintos equipos administren y protejan los recursos. Las características de conectividad dependen del modelo de red. Los pods superpuestos inician conexiones a la red virtual y a los recursos locales a través de la dirección IP del nodo. Los pods de red plana pueden comunicarse directamente con los recursos conectados a través de sus direcciones IP privadas.

Cuando usas redes de Azure CNI, el recurso de red virtual se encuentra en un grupo de recursos independiente con respecto al clúster de AKS. Delegue permisos en la identidad de clúster de AKS para acceder y administrar estos recursos. La identidad de clúster que usa el clúster de AKS debe tener como mínimo permisos de Colaborador de la red en la subred de la red virtual.

Si quiere definir un rol personalizado en lugar de usar el rol integrado de colaborador de red, se requieren los permisos siguientes:

De manera predeterminada, AKS utiliza una identidad administrada para su identidad de clúster. Sin embargo, puede usar una entidad de servicio en su lugar.

• Para obtener más información sobre la delegación en entidad de servicio de AKS, consulte Delegación del acceso a otros recursos de Azure.
• Para más información sobre las identidades administradas, consulte Uso de identidades administradas en Azure Kubernetes Service.

Planee intervalos de direcciones en función del modelo de red. Tenga en cuenta los siguientes criterios:

• Con Azure CNI Overlay, dimensiona la subred de nodos para los nodos y utiliza un CIDR privado independiente para los pods. Cada nodo recibe un /24 espacio de direcciones del CIDR del pod.
• Con una red plana, dimensione las subredes de la red virtual tanto para los nodos como para los pods. La subred de pods de Azure CNI usa subredes independientes para los nodos y los pods, mientras que la versión heredada de la subred de nodos de Azure CNI usa una sola subred para ambos.
• Evite el uso de intervalos de direcciones IP que se superponen con los recursos de red existentes.
  • Es necesario permitir la conectividad a redes locales o emparejadas en Azure.
• Para controlar eventos de escalabilidad horizontal o actualizaciones de clúster, necesita direcciones IP adicionales disponibles en la subred asignada.
  • Este espacio de direcciones adicional es especialmente importante si usa contenedores de Windows Server, ya que esos grupos de nodos requieren una actualización para aplicar las revisiones de seguridad más recientes. Para obtener más información sobre los nodos de Windows Server, consulte Upgrade a node pool in AKS.

Para calcular el espacio de direcciones IP necesario, consulte Planeamiento de direcciones IP para clústeres de AKS.

Al crear un clúster con redes de Azure CNI, se especifican otros rangos de direcciones para el clúster, como la dirección IP del servicio DNS y el rango de direcciones del servicio. En general, asegúrese de que estos intervalos de direcciones no se superponen entre sí ni las redes asociadas al clúster, incluidas las redes virtuales, las subredes, las redes locales y las redes emparejadas.

Para más información sobre los modelos de redes, los límites y el dimensionamiento de direcciones, consulte Introducción a las redes de Azure CNI.

Distribución del tráfico de entrada

Guía de procedimientos recomendados

Para distribuir el tráfico HTTP o HTTPS a las aplicaciones, use los recursos y los controladores de entrada. En comparación con un equilibrador de carga de Azure, los controladores de entrada proporcionan características adicionales y se pueden administrar como recursos nativos de Kubernetes.

Aunque un equilibrador de carga Azure puede distribuir el tráfico de los clientes a las aplicaciones del clúster de AKS, se limita a comprender ese tráfico. Un recurso de equilibrador de carga funciona en la capa 4 y distribuye el tráfico en función de protocolos o puertos.

La mayoría de las aplicaciones web que usan HTTP o HTTPS deben usar recursos y controladores de entrada de Kubernetes, que funcionan en la capa 7. En la entrada se puede distribuir el tráfico en función de la dirección URL de la aplicación y administrar la terminación TLS/SSL. La entrada también reduce el número de direcciones IP que se exponen y se asignan.

Con un equilibrador de carga, cada aplicación normalmente necesita una dirección IP pública asignada y a ella y al servicio del clúster de AKS. Con un recurso de entrada, una única dirección IP puede distribuir tráfico a varias aplicaciones.

En el diagrama se muestra una única dirección IP pública que recibe tráfico externo y un controlador de entrada que distribuye ese tráfico a varios servicios en el clúster de AKS.

Ingress tiene dos componentes: un recurso Ingress y un controlador Ingress.

Recurso de entrada

El recurso de entrada es un manifiesto YAML de kind: Ingress. Define el host, los certificados y las reglas para enrutar el tráfico a los servicios que se ejecutan en el clúster de AKS.

En el siguiente manifiesto YAML de ejemplo se usa la clase Ingress de NGINX administrada por el complemento de enrutamiento de aplicaciones. Distribuye el tráfico de myapp.com a uno de los dos servicios, blogservice o storeservice, y dirige al cliente a un servicio u otro en función de la dirección URL a la que acceden.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  tls:
  - hosts:
    - myapp.com
    secretName: myapp-secret
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /blog
        pathType: Prefix
        backend:
          service:
            name: blogservice
            port:
              number: 80
      - path: /store
        pathType: Prefix
        backend:
          service:
            name: storeservice
            port:
              number: 80

El ingressClassName campo selecciona la clase de entrada y debe coincidir con una clase configurada en un controlador de entrada del clúster. El valor webapprouting.kubernetes.azure.com selecciona el controlador de entrada NGINX administrado proporcionado por el complemento de enrutamiento de aplicaciones. Reemplácelo por el nombre de clase del controlador de entrada si usa una implementación diferente.

Controlador de entrada

Un controlador de entrada hospedado en clúster se ejecuta como una carga de trabajo en un nodo de AKS y supervisa las solicitudes entrantes. A continuación, el tráfico entrante se distribuye en función de las reglas definidas en el recurso de entrada asociado a ese controlador. Aunque el controlador de entrada más común se basa en NGINX, AKS no le restringe a un controlador específico. Puede usar Application Gateway para contenedores, Contour, HAProxy, Traefik y otros.

Debe programar controladores de entrada hospedados en clúster en un nodo de Linux. Indique que el recurso debe ejecutarse en un nodo basado en Linux mediante un selector de nodos en el manifiesto de YAML o la implementación del gráfico de Helm. Para obtener más información, consulte Uso de selectores de nodo para controlar dónde se programan los pods en AKS.

Ingress con el complemento de enrutamiento de aplicaciones

El complemento de enrutamiento de aplicaciones proporciona implementaciones de entrada administradas para AKS. Para despliegues nuevos y de larga duración, use la implementación de la API Gateway para el enrutamiento de aplicaciones si cumple sus requisitos. Gateway API es el estándar a largo plazo para Ingress de Kubernetes y la gestión del tráfico de capa 7.

La implementación de NGINX administrada proporciona las siguientes características:

• Configuración sencilla de controladores de entrada NGINX administrados basados en controlador de entrada NGINX de Kubernetes.
• Integración con Azure DNS para la administración de zonas públicas y privadas.
• Terminación SSL con certificados almacenados en Azure Key Vault.

Para obtener más información, consulte Configurar ingress con la API Gateway de Application Routing y Ingress de NGINX administrado con el complemento Application Routing.

Protección del tráfico con un firewall de aplicaciones web (WAF)

Guía de procedimientos recomendados

Para examinar el tráfico entrante para detectar posibles ataques, use un firewall de aplicaciones web (WAF), como Barracuda WAF para Azure o Azure Web Application Firewall en Application Gateway for Containers. Application Gateway para contenedores enruta el tráfico de inferencia HTTP, HTTPS, gRPC, WebSocket y AI y admite la terminación TLS.

Un controlador de entrada hospedado en clúster se ejecuta como una carga de trabajo de Kubernetes en el clúster de AKS y distribuye el tráfico a servicios y aplicaciones. Consume algunos de los recursos del nodo, como cpu, memoria y ancho de banda de red. En entornos más grandes, es posible que desee tener en cuenta lo siguiente:

• Descargar algo de tráfico mediante el enrutamiento o la terminación TLS a un recurso de red externo al clúster de AKS.
• Analizar el tráfico entrante en busca de posibles ataques.

En el diagrama se muestra el tráfico externo que pasa por Azure Application Gateway para contenedores. Cuando se configura la protección de WAF, las reglas de WAF filtran las solicitudes antes de que Application Gateway for Containers reenvíe el tráfico permitido a los servicios del clúster de AKS.

Para esa capa adicional de seguridad, un firewall de aplicaciones web (WAF) filtra el tráfico entrante. Las reglas administradas y personalizadas protegen contra ataques como scripting entre sitios e inyección de código SQL. Application Gateway for Containers es un servicio de equilibrio de carga y administración de tráfico de nivel 7 que admite Azure WAF.

La protección de WAF no se habilita solo con implementar Application Gateway for Containers. Debe crear una directiva de WAF y completar las dos configuraciones siguientes antes de que WAF inspeccione el tráfico:

• Cree un recurso secundario de Azure SecurityPolicy que haga referencia a la directiva de WAF.
• Aplique un recurso personalizado de Kubernetes WebApplicationFirewallPolicy que haga referencia a la misma directiva de WAF y que tenga como destino el Gateway recurso o HTTPRoute que se va a proteger.

Después de completar ambas configuraciones, compruebe el estado de los recursos personalizados y los registros de WAF antes de confiar en la directiva para la protección. Para más información, consulte Azure Web Application Firewall en Application Gateway for Containers.

Dado que otras soluciones de terceros también realizan estas funciones, puede seguir usando las inversiones existentes o la experiencia en su producto preferido.

Los recursos de entrada o el equilibrador de carga continúan ejecutándose en el clúster de AKS y mejoran la distribución del tráfico. Azure Application Gateway for Containers se puede administrar centralmente como un controlador de entrada con una definición de recurso. Para empezar, cree una instancia de Application Gateway for Containers y, a continuación, configure la protección de WAF por separado.

Control del flujo de tráfico con directivas de red

Guía de procedimientos recomendados

Use directivas de red para permitir o denegar el tráfico a los pods. De forma predeterminada, se permite todo el tráfico entre los pods dentro de un clúster. Para mejorar la seguridad, defina reglas que limiten la comunicación del pod.

La directiva de red es una característica de Kubernetes disponible en AKS que permite controlar el flujo de tráfico entre pods. Según la configuración se permite o deniega el tráfico al pod, como, por ejemplo, etiquetas asignadas, espacio de nombres o puerto de tráfico. Las directivas de red son una manera nativa de nube para controlar el flujo de tráfico de los pods. Como los pods se crean dinámicamente en un clúster de AKS, se pueden aplicar automáticamente las directivas de red necesarias.

Para usar directivas de red en AKS, seleccione un motor de directivas de red que admita los sistemas operativos de nodo y el plano de datos de red. Puede habilitar un motor de directivas durante la creación del clúster o en un clúster compatible existente.

En el caso de los grupos de nodos de Linux, use Azure CNI con tecnología de Cilium y su aplicación integrada de directivas de red de Cilium. Cilium no es compatible con los grupos de nodos de Windows. Para cargas de trabajo de Windows, use Calico.

Se crea una directiva de red como un recurso de Kubernetes mediante un manifiesto YAML. Las directivas se aplican a pods definidos, con reglas de entrada o salida que definen el flujo de tráfico.

El ejemplo siguiente aplica una directiva de red a los pods que tienen la etiqueta app: backend. La regla de entrada solo permite el tráfico desde los pods con la etiqueta app: frontend.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Para empezar a trabajar con directivas, consulte Tráfico seguro entre pods mediante directivas de red en Azure Kubernetes Service (AKS).

Optimización de la resolución DNS con LocalDNS

Guía de procedimientos recomendados

Use LocalDNS para mejorar el rendimiento y la confiabilidad de DNS y reducir la carga en pods de CoreDNS centralizados. LocalDNS está preconfigurado en AKS Automatic. En AKS Standard, habilite y configure LocalDNS por grupo de nodos.

LocalDNS implementa un proxy DNS como systemd servicio en cada nodo para controlar las consultas DNS localmente. De forma predeterminada, los pods envían todas las consultas DNS a pods de CoreDNS centralizados. A escala, la centralización de estas consultas puede crear un cuello de botella, mientras que la resolución local reduce los saltos de red y la latencia.

LocalDNS también elimina entradas de tabla de conntrack para tráfico DNS, lo que evita el agotamiento de la tabla de conntrack y las condiciones de carrera que pueden provocar la pérdida de conexiones. Las conexiones de la caché local a CoreDNS se actualizan a TCP, lo que permite el reequilibrio de conexión y una limpieza más rápida de las entradas de seguimiento.

En el caso de las cargas de trabajo que requieren alta disponibilidad de DNS, LocalDNS admite el servicio de respuestas almacenadas en caché obsoletas durante una duración configurable cuando el DNS ascendente no está disponible. Esta funcionalidad de mejor esfuerzo puede ayudar a mantener la conectividad de los pods y la fiabilidad del servicio durante interrupciones temporales del DNS, pero no garantiza que haya disponible un registro desactualizado.

En AKS Estándar, al habilitar LocalDNS en un grupo de nodos existente, se vuelven a crear las imágenes de sus nodos. Planee el lanzamiento para tener en cuenta esta interrupción.

Para obtener más información sobre la arquitectura y las funcionalidades de LocalDNS, consulte Resolución dns en AKS. Para obtener instrucciones de configuración, consulte Configuración de LocalDNS.

Conexión segura a nodos

Guía de procedimientos recomendados

No exponga la conectividad remota a los nodos de AKS. Para solucionar problemas de nodos de Linux rutinarios, use kubectl debug a través de la API de Kubernetes. Cuando necesite acceso SSH, conéctese a través de redes privadas o Azure Bastion.

Puede completar la mayoría de las operaciones en AKS mediante las herramientas de administración de Azure o el servidor de la API de Kubernetes. Los nodos de AKS solo están disponibles en una red privada y no están conectados a la red pública de Internet. Para los nodos de Linux, use kubectl debug para iniciar un contenedor de depuración con privilegios a través de la API de Kubernetes. Este enfoque no requiere conectividad SSH directa al nodo.

Si el acceso a la API de Kubernetes no es adecuado o necesita SSH, use la dirección IP privada del nodo desde una red conectada. Azure Bastion puede proporcionar conectividad privada sin exponer una dirección IP pública en el nodo. Para los nodos de Windows, utilice un contenedor de proceso de host o conéctese a través de un nodo proxy Linux. Azure Bastion es una alternativa si el nodo proxy no está disponible. Para más información, consulte Conexión a nodos de clúster de AKS para mantenimiento o solución de problemas.

En el diagrama se muestra una red virtual de administración que contiene un host de bastión que encamina las conexiones a través de un enlace de emparejamiento seguro hacia la red virtual del clúster de AKS.

Si usa un host de bastión o un jump box, colóquelo en una red virtual de administración independiente con emparejamiento seguro. Proteja la red de administración mediante Azure ExpressRoute o una puerta de enlace de VPN para conectarse a una red local y controlar el acceso con grupos de seguridad de red.

Pasos siguientes

Este artículo se centra en la conectividad de red y la seguridad. Para obtener más información sobre los conceptos básicos de red en Kubernetes, consulte Conceptos de red para aplicaciones en Azure Kubernetes Service (AKS)