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

Utilizar red CNI de Azure en AKS para la integración con redes virtuales existentes o redes de instalaciones locales. Este modelo de red permite mayor separación de los recursos y los controles en un entorno empresarial.

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 Azure CNI: se despliega en una red virtual y usa el complemento Azure CNI Kubernetes. Los pods reciben direcciones IP individuales que se pueden enrutar a otros servicios de red o recursos locales.

Azure CNI es una opción válida para las implementaciones de producción.

Redes de CNI

Azure CNI es un protocolo neutral del proveedor que permite al entorno de ejecución del contenedor realizar solicitudes a un proveedor de red. Asigna direcciones IP a pods y nodos y proporciona características de administración de direcciones IP (IPAM) a medida que se conecta a redes virtuales de Azure existentes. Cada nodo y recurso de pod recibe una dirección IP en la red virtual Azure. No es necesario que el enrutamiento adicional se comunique con otros recursos o servicios.

En particular, Azure CNI Networking para entornos de producción permite la separación del control y la administración de los recursos. Desde una perspectiva de seguridad, se suele preferir que distintos equipos administren y protejan los recursos. Con las redes de Azure CNI, puede conectarse a los recursos existentes de Azure, a los recursos locales o a otros servicios directamente mediante direcciones IP que se asignan a cada pod.

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:

• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/read

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.

Como cada pod y cada nodo recibe su propia dirección IP, planee los intervalos de direcciones para las subredes de AKS. Tenga en cuenta los siguientes criterios:

• La subred debe ser lo suficientemente grande como para proporcionar direcciones IP para cada nodo, pod y recurso de red que implemente.
  • Con la red de Azure CNI, cada nodo en funcionamiento tiene límites predeterminados para el número de pods.
• 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 la dirección IP necesaria, consulte Configuración de redes CNI de Azure en AKS.

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

Para obtener información específica sobre los límites y el dimensionamiento de estos intervalos de direcciones, consulte Configurar la red de CNI en Azure AKS.

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 la entrada existen dos componentes:

1. un recurso de entrada
2. un controlador de entrada

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.

El siguiente manifiesto YAML de ejemplo distribuye el tráfico para 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: PublicIngress
 tls:
 - hosts:
   - myapp.com
   secretName: myapp-secret
 rules:
   - host: myapp.com
     http:
      paths:
      - path: /blog
        backend:
         service:
           name: blogservice
           port: 80
      - path: /store
        backend:
         service:
           name: storeservice
           port: 80

Controlador de entrada

Un controlador de entrada es un demonio que se ejecuta en un nodo de AKS y supervisa las solicitudes entrantes. A continuación, el tráfico se distribuye según las reglas definidas en el recurso de entrada. 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, etc.

El controlador de entrada también debe programarse en un nodo de Linux. Indique que el recurso debe ejecutarse en un nodo basado en Linux mediante un selector de nodo en el manifiesto YAML o una implementación de 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.

Entrada con el complemento de enrutamiento de aplicaciones

El complemento de enrutamiento de aplicaciones es la manera recomendada para configurar un controlador de entrada en AKS. El complemento de enrutamiento de aplicaciones es un controlador de entrada totalmente administrado para Azure Kubernetes Service (AKS) que 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 sobre el complemento de enrutamiento de aplicaciones, consulte Entrada administrada de NGINX con el complemento de enrutamiento de aplicaciones.

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

Guía de procedimientos recomendados

Para examinar el tráfico entrante en busca de posibles ataques, use un firewall de aplicaciones web (WAF), como Barracuda WAF para Azure o Azure Application Gateway for Containers. Estos recursos de red más avanzados también pueden enrutar el tráfico más allá de las conexiones HTTP y HTTPS sencillas o la terminación TLS básica.

Normalmente, un controlador de entrada es un recurso de Kubernetes en el clúster de AKS que distribuye el tráfico a servicios y aplicaciones. El controlador se ejecuta como demonio en un nodo de AKS y consume algunos de los recursos del nodo, como la CPU, la memoria y el 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.

Para esa capa adicional de seguridad, un firewall de aplicaciones web (WAF) filtra el tráfico entrante. Con un conjunto de reglas, el Proyecto de Seguridad de Aplicaciones Web Abiertas (OWASP) vigila ataques como scripting de sitios cruzados o envenenamiento de cookies. Azure Application Gateway for Containers es un WAF que se integra con clústeres de AKS, bloqueando estas características de seguridad antes de que el tráfico llegue al clúster y las aplicaciones de AKS.

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 Puerta de enlace de aplicaciones para contenedores.

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, la característica se puede habilitar durante la creación del clúster o en un clúster de AKS existente. Si planea usar directivas de red, asegúrese de que la característica está habilitada en el clúster de AKS.

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

Habilite LocalDNS en los grupos de nodos de AKS para mejorar el rendimiento y la confiabilidad del DNS, y reducir la carga en los pods centralizados de CoreDNS.

La resolución DNS es fundamental para la comunicación entre servicios en Kubernetes. De forma predeterminada, todas las consultas DNS de los pods se envían a los pods centralizados de CoreDNS, lo que puede convertirse en un cuello de botella a gran escala. AKS ofrece LocalDNS, que implementa un proxy DNS como systemd servicio en cada nodo. Este proxy controla las consultas DNS localmente, lo que reduce los saltos de red y la latencia de resolución.

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 ayuda a mantener la conectividad del pod y la confiabilidad del servicio durante interrupciones transitorias de DNS.

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 los nodos mediante una pasarela de aplicaciones

Guía de procedimientos recomendados

No exponga la conectividad remota a los nodos de AKS. Cree una pasarela de aplicaciones, o host jump, en una red virtual de administración. Utilice la pasarela de aplicaciones para enrutar el tráfico de forma segura en el clúster de AKS para las tareas de administración remota.

Puede completar la mayoría de las operaciones en AKS mediante las herramientas de administración de Azure o mediante el servidor de 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 conectarse a los nodos y proporcionar mantenimiento y soporte técnico, enrute las conexiones a través de un host bastión o jumpbox. Compruebe que este host se encuentre en una red virtual de administración independiente emparejada de forma segura a la red virtual del clúster de AKS.

También debe proteger la red de administración para el host bastión. Use una puerta de enlace Azure ExpressRoute o VPN para conectarse a una red local y controlar el acceso mediante 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)