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

Al crear y administrar clústeres en Azure Kubernetes Service (AKS), se 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:

• Comparar los modos de red kubenet y Azure Container Networking Interface (CNI) en AKS.
• Planear la conectividad y el direccionamiento IP necesarios.
• Distribuir el tráfico mediante equilibradores de carga, controladores de entrada o un firewall de aplicaciones web (WAF).
• Conectarse de forma segura a los nodos del clúster.

Elección del modelo de red adecuado

Guía de procedimientos recomendados

Use las redes de Azure CNI en AKS para la integración con redes virtuales existentes o redes 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:

• Conexión en red de Azure CNI: se implementa en una red virtual y usa el complemento Azure CNI de Kubernetes. Los pods reciben direcciones IP individuales que se pueden enrutar a otros servicios de red o recursos locales.
• Redes de kubenet: cuando el clúster se implementa y usa el complemento kubenet de Kubernetes, Azure administra los recursos de red virtual.

Azure CNI y kubenet son opciones válidas para las implementaciones de producción.

Redes de CNI

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

En particular, las redes de Azure CNI para producción permiten separar el 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 recursos de Azure existentes, recursos locales u otros servicios mediante direcciones IP asignadas a cada pod.

Al usar redes de Azure CNI, el recurso de red virtual se encuentra en un grupo de recursos independiente del 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 conexión en red de kubenet y de Azure CNI, cada nodo que se ejecuta tiene límites predeterminados del número de pods.
• Evite el uso de intervalos de direcciones IP que se superponen con los recursos de red existentes.
  • Es necesario para permitir la conectividad a redes locales o emparejadas en Azure.
• Para controlar los eventos de escalado horizontal o las actualizaciones de clúster, es necesario que haya otras direcciones IP disponibles en la subred asignada.
  • Este espacio de direcciones adicional es especialmente importante si usa contenedores de Windows Server, como aquellos grupos de nodos que 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 Actualización de un grupo de nodos en AKS.

Para calcular la dirección IP necesaria, consulte Configuración de redes de Azure CNI en AKS.

Cuando se crea un clúster con redes de Azure CNI, se especifican otros intervalos de direcciones para el clúster, como la dirección del puente de Docker, la IP del servicio DNS y el intervalo de direcciones de 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 detalles específicos sobre los límites y el tamaño de estos intervalos de direcciones, consulte Configuración de redes de Azure CNI en AKS.

Redes de kubenet

Aunque kubenet no requiere la configuración de las redes virtuales antes de la implementación del clúster, existen algunos inconvenientes al esperar, como:

• Puesto que los nodos y pods se colocan en subredes IP diferentes, el enrutamiento definido por el usuario (UDR) y el reenvío IP enruta el tráfico entre pods y nodos. Este enrutamiento adicional puede reducir el rendimiento de las redes.
• Las conexiones a redes locales existentes o el emparejamiento con otras redes virtuales de Azure pueden ser complejos.

Dado que no crea la red virtual y las subredes por separado del clúster de AKS, Kubenet es ideal para los siguientes escenarios:

• Cargas de trabajo pequeñas de desarrollo o pruebas.
• Sitios web sencillos con poco tráfico.
• Elevación y desplazamiento de cargas de trabajo a contenedores.

En las implementaciones de producción, tanto kubenet como Azure CNI son opciones válidas. Los entornos en los que se necesita separar el control y la administración, Azure CNI puede ser la opción preferida. Además, kubenet es adecuado para entornos solo de Linux en los que la conservación del intervalo de direcciones IP es una prioridad.

También puede configurar sus propios intervalos de direcciones IP y redes virtuales con kubenet. De forma similar a la conexión en red de Azure CNI, estos intervalos de direcciones no deben superponerse entre sí ni con las redes asociadas al clúster (las redes virtuales, las subredes, las redes locales y las redes emparejadas).

Para obtener detalles específicos sobre los límites y el tamaño de estos intervalos de direcciones, consulte Uso de redes kubenet con sus propios intervalos de direcciones IP en 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 el 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 de Azure puede distribuir el tráfico de cliente a las aplicaciones en el clúster de AKS, su conocimiento sobre ese tráfico es limitado. 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 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 analizar 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. 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, Open Web Application Security Project (OWASP) detecta ataques, como el scripting entre sitios o el envenenamiento de cookies. Azure Application Gateway (actualmente en versión preliminar en AKS) es una solución WAF que se integra con los clústeres de AKS, lo que bloquea estas características de seguridad antes de que el tráfico llegue al clúster y a 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. Application Gateway se puede administrar de manera centralizada como controlador de entrada con definición de recurso. Para empezar, cree un controlador de entrada de Application Gateway.

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 la directiva de red, habilite la característica al crear un clúster de AKS. No se puede habilitar la directiva de red en un clúster de AKS existente. Planee con antelación la habilitación de la directiva de red en los clústeres necesarios.

Nota

La directiva de red solo se debe usar para los pods y los nodos basados en Linux 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 usar directivas, consulte Protección del tráfico entre pods mediante directivas de red en Azure Kubernetes Service (AKS).

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.

La mayoría de las operaciones en AKS puede realizarse con 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 Azure ExpressRoute o VPN Gateway 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 redes de aplicaciones en Azure Kubernetes Service (AKS).