Uso del controlador de entrada de Application Gateway con un clúster multiinquilino de Azure Kubernetes Service

Esta solución usa Azure Web Application Firewall (WAF) para ayudar a proporcionar protección centralizada para las aplicaciones web que se implementan en un clúster de Azure Kubernetes Service (AKS) multiinquilino. WAF ayuda a proteger contra vulnerabilidades y vulnerabilidades comunes.

Puede usar una directiva de WAF en App de Azure lication Gateway para ayudar a proteger las aplicaciones web frente a ataques malintencionados, como la inyección de CÓDIGO SQL y el scripting entre sitios. Este método ayuda a proteger las aplicaciones web que se ejecutan en un clúster de AKS y se exponen a través del controlador de entrada de Application Gateway (AGIC). La directiva waf en Application Gateway está preconfigurada con el conjunto de reglas principal (CRS) Open Worldwide Application Security Project (OWASP) y admite otras versiones crS de OWASP. También puede crear reglas personalizadas.

Arquitectura

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

• Esta arquitectura usa una plantilla complementaria de Azure Resource Manager (plantilla de ARM) para implementar una nueva red virtual que tenga cuatro subredes:

  • AksSubnet hospeda el clúster de AKS.
  • VmSubnet hospeda una máquina virtual jumpbox y puntos de conexión privados.
  • AppGatewaySubnet hospeda el nivel WAF2 de Application Gateway.
  • AzureBastionSubnet hospeda Azure Bastion.

• El clúster de AKS usa una identidad administrada definida por el usuario para crear más recursos, como equilibradores de carga y discos administrados, en Azure. Puede usar la plantilla de ARM para implementar un clúster de AKS que tenga las siguientes características:

  • Controladores de Container Storage Interface (CSI) para discos de Azure y Azure Files
  • Integración de Microsoft Entra administrada por AKS
  • Control de acceso basado en roles (RBAC) de Azure para la autorización de Kubernetes
  • Una identidad administrada en lugar de una entidad de servicio
  • Id. de carga de trabajo de Microsoft Entra
  • Directivas de red de Azure
  • Complemento de Azure Monitor Container Insights
  • Complemento AGIC
  • Asignación dinámica de direcciones IP y compatibilidad mejorada con subredes

• El clúster de AKS tiene los siguientes grupos de nodos:

  • El grupo de nodos del sistema hospeda solo los pods y servicios críticos del sistema. Los nodos de trabajo tienen taint de nodo que impide que los pods de aplicación se programe en este grupo de nodos.
  • El grupo de nodos de usuario hospeda cargas de trabajo y artefactos de usuario.

• Una máquina virtual se implementa en la misma red virtual que hospeda el clúster de AKS. Al implementar AKS como un clúster privado, los administradores del sistema pueden usar esta máquina virtual para administrar el clúster por medio de la herramienta de línea de comandos de Kubernetes. Los registros de diagnósticos de arranque de la máquina virtual se almacenan en una cuenta de Azure Storage.

• Un host de Azure Bastion proporciona conectividad segura y sin problemas de Secure Shell (SSH) a la máquina virtual jumpbox, directamente en Azure Portal a través de Capa de sockets seguros (SSL). Esta solución usa Azure Container Registry para compilar, almacenar y administrar imágenes y artefactos de contenedor, como gráficos de Helm.

• La arquitectura incluye una puerta de enlace de aplicaciones que usa el controlador de entrada. La puerta de enlace de aplicaciones se implementa en una subred dedicada y se expone a la red pública de Internet a través de una dirección IP pública que comparten todas las cargas de trabajo de inquilino. Una directiva de WAF ayuda a proteger las cargas de trabajo de inquilino frente a ataques malintencionados.

  La directiva waf está asociada a la puerta de enlace de aplicaciones en el nivel raíz y en el nivel de escucha HTTP. La directiva se configura en modo de prevención y usa OWASP 3.1 para bloquear intrusiones y ataques que detectan las reglas. El atacante recibe una excepción de acceso no autorizado 403 y se cierra la conexión. El modo de prevención registra estos ataques en los registros del WAF.

• Las cargas de trabajo que se ejecutan en AKS usan un almacén de claves como almacén de secretos para recuperar claves, certificados y secretos a través de una biblioteca cliente, el controlador CSI del almacén de secretos o Dapr. Azure Private Link permite que las cargas de trabajo de AKS accedan a soluciones de plataforma como servicio (PaaS) de Azure, como Azure Key Vault, a través de un punto de conexión privado en la red virtual.

• Esta arquitectura incluye puntos de conexión privados a los siguientes componentes:

  • La cuenta de Azure Blob Storage
  • Container Registry
  • Key Vault
  • El servidor de API del clúster de Kubernetes, si usa un clúster de AKS privado.

• La arquitectura también incluye zonas DNS privadas para resolver el nombre de dominio completo (FQDN) de un servicio PaaS a la dirección IP privada de su punto de conexión privado asociado. Esta arquitectura incluye zonas DNS privadas para resolver los puntos de conexión privados en los siguientes componentes:

  • La cuenta de Blob Storage
  • Container Registry
  • Key Vault
  • La API del servidor de Kubernetes, si implementa el clúster como privado.

• Existe un vínculo de red virtual entre la red virtual que hospeda el clúster de AKS y las zonas DNS privadas anteriores. Un área de trabajo de Log Analytics recopila los registros de diagnóstico y las métricas de los orígenes siguientes:

  • El clúster de AKS
  • La máquina virtual jumpbox
  • Application Gateway
  • Key Vault
  • Grupos de seguridad de red de Azure

Componentes

• Azure Container Registry es un servicio de Docker Registry privado administrado que se basa en Docker Registry 2.0 de código abierto. Puede usar registros de contenedor de Azure con las canalizaciones de implementación y desarrollo de contenedores existentes. O bien, use tareas de Container Registry para compilar imágenes de contenedor en Azure. Puede crear compilaciones a petición o totalmente automatizadas con desencadenadores, como confirmaciones de código fuente y actualizaciones de imágenes base.

• AKS simplifica la implementación de un clúster de Kubernetes administrado en Azure descargando la sobrecarga operativa en Azure. Al ser un servicio de Kubernetes hospedado, Azure controla tareas críticas como la supervisión del estado y el mantenimiento. Azure administra los nodos del plano de control de Kubernetes, por lo que solo se administran y mantienen los nodos del agente.

• Key Vault ayuda a almacenar y controlar de forma segura el acceso a secretos, como claves de API, contraseñas, certificados y claves criptográficas. Puede usar Key Vault para aprovisionar, administrar e implementar fácilmente certificados SSL o seguridad de la capa de transporte público y privado (TLS) o SSL, y usarlos con Azure y los recursos conectados internos.

• Application Gateway es un equilibrador de carga de tráfico web que puede usar para administrar el tráfico entrante que va a aplicaciones web de bajada y API REST. Los equilibradores de carga tradicionales funcionan en la capa de transporte, que es la capa 4 de interconexión de sistemas abiertos (OSI), para controlar el tráfico que usa el Protocolo de control de transmisión (TCP) y el Protocolo de datagramas de usuario (UDP). En función del puerto y la dirección IP de origen, estos enrutan el tráfico a un puerto y una dirección IP de destino. Una puerta de enlace de aplicaciones es un equilibrador de carga en la capa de aplicación, que es la capa de OSI 7.

• WAF es un servicio que ayuda a proporcionar protección centralizada de las aplicaciones web frente a vulnerabilidades y vulnerabilidades comunes. WAF se basa en reglas del CRS de OWASP. Puede usar WAF para crear reglas personalizadas que se evalúan para cada solicitud que pasa a través de una directiva. Estas reglas tienen una prioridad mayor que el resto de las reglas de los conjuntos de reglas administrados. Las reglas personalizadas contienen un nombre de regla, la prioridad de la regla y una matriz de condiciones de coincidencia. Si la solicitud cumple estas condiciones, WAF permite o bloquea la solicitud en función de la regla.

• Azure Bastion es una plataforma totalmente administrada como servicio (PaaS) que se aprovisiona en la red virtual. Azure Bastion ayuda a proporcionar conectividad SSH (RDP) y protocolo de escritorio remoto (RDP) segura y sin problemas a las máquinas virtuales de la red virtual, directamente desde Azure Portal a través de TLS.

• Azure Virtual Machines proporciona recursos informáticos escalables a petición que proporcionan la flexibilidad de virtualización sin tener que comprar y mantener el hardware físico.

• Azure Virtual Network es el bloque de creación fundamental para las redes privadas de Azure. Con Virtual Network, los recursos de Azure, como las máquinas virtuales, pueden comunicarse entre sí, con Internet y redes locales de forma más segura. Una red virtual de Azure se parece a una red tradicional local, pero incluye las ventajas de la infraestructura de Azure, como la escalabilidad, la disponibilidad y el aislamiento.

• Las interfaces de red virtual ayudan a establecer la comunicación entre las máquinas virtuales de Azure e Internet, Azure y los recursos locales. Puede agregar varias tarjetas de interfaz de red a una VM de Azure, de modo que las VM secundarias puedan tener sus propios dispositivos de interfaz de red y direcciones IP dedicados.

• Los discos administrados de Azure son volúmenes de almacenamiento de nivel de bloque que Azure administra en máquinas virtuales de Azure. Los tipos de disco incluyen Azure Ultra Disk Storage, SSD Premium de Azure, SSD estándar de Azure y HDD estándar de Azure.

• Blob Storage es una solución de almacenamiento de objetos de Microsoft para la nube. Blob Storage está optimizado para el almacenamiento de cantidades masivas de datos no estructurados. Los datos no estructurados son datos que no se adhieren a un modelo o definición de datos concretos, como datos de texto o datos binarios.

• Private Link proporciona un punto de conexión privado en la red virtual para que pueda acceder a los servicios PaaS de Azure, como Blob Storage y Key Vault, y acceder a servicios hospedados en Azure, propiedad del cliente o servicios asociados.

Alternativas

Cuando expone cargas de trabajo que hospeda en un clúster de AKS, tiene varias soluciones que se deben tener en cuenta. En lugar de usar AGIC, puede usar Application Gateway para contenedores o la entrada NGINX administrada con el complemento de enrutamiento de aplicaciones. Estas alternativas proporcionan diferentes funcionalidades para ayudar a administrar y proteger el tráfico al clúster de AKS.

Esta arquitectura instala AGIC a través del complemento AGIC para AKS. También puede instalar el AGIC a través de un gráfico de Helm. Al crear una nueva configuración, puede usar una línea de la CLI de Azure para implementar una nueva puerta de enlace de aplicaciones y un nuevo clúster de AKS. Este método habilita AGIC como complemento. El complemento es un servicio totalmente administrado, que proporciona ventajas adicionales, como actualizaciones automáticas y mayor soporte técnico. También se considera un complemento de primera clase, que proporciona una mejor integración con AKS. Microsoft admite ambos métodos de implementación para AGIC.

El complemento AGIC se implementa como un pod en el clúster de AKS. Pero hay algunas diferencias entre la versión de implementación de Helm y la versión del complemento de AGIC. En la lista siguiente se incluyen las diferencias entre las dos versiones:

• No se pueden modificar los valores de implementación de Helm en el complemento de AKS:

  • La propiedad usePrivateIp se establece en false de forma predeterminada. No se puede sobrescribir este valor a través de la use-private-ip anotación.
  • El complemento no admite la shared opción de configuración.

• El AGIC implementado por Helm admite ProhibitedTargets, lo que significa que AGIC puede configurar la puerta de enlace de aplicaciones específicamente para clústeres de AKS sin afectar a otros back-end existentes.

• El complemento AGIC es un servicio administrado, por lo que se actualiza automáticamente a la versión más reciente. Si implementa AGIC a través de Helm, debe actualizar manualmente el AGIC.

• Solo puede implementar un complemento de AGIC para cada clúster de AKS. Cada complemento de AGIC solo puede tener como destino una instancia de Application Gateway. En el caso de las implementaciones que requieren más de un AGIC para cada clúster o varios AGIC que tienen como destino una instancia de Application Gateway, puede usar el AGIC implementado por Helm.

Una sola instancia de AGIC puede ingerir eventos de varios espacios de nombres de Kubernetes. Si el administrador de AKS usa la puerta de enlace de aplicaciones como entrada, todos los espacios de nombres usan la misma instancia de Application Gateway. Una única instalación de AGIC supervisa los espacios de nombres accesibles y configura la puerta de enlace de aplicaciones a la que está asociada. Para obtener más información, consulte Habilitación de la compatibilidad con varios espacios de nombres en un clúster de AKS con AGIC.

Para habilitar la compatibilidad con varios espacios de nombres, siga estos pasos:

1. Modifique el archivo helm-config.yaml de una de las siguientes maneras:

• Elimine la watchNamespace clave por completo del archivo helm-config.yaml para permitir que AGIC observe todos los espacios de nombres.
• Establezca watchNamespace en una cadena vacía para permitir que AGIC observe todos los espacios de nombres.
• Agregue varios espacios de nombres separados por una coma, como watchNamespace: default,secondNamespace, para permitir que AGIC observe estos espacios de nombres exclusivamente.

2. Aplique los cambios de plantilla de Helm con este script: helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure.

Después de implementar AGIC con la capacidad de observar varios espacios de nombres, AGIC realiza las siguientes acciones:

1. Enumera los recursos de entrada de todos los espacios de nombres accesibles.
2. Filtra los recursos de entrada anotados con kubernetes.io/ingress.class: azure/application-gateway
3. Compone la configuración combinada de Application Gateway
4. Aplica la configuración a la puerta de enlace de aplicaciones asociada a través de Azure Resource Manager.

Detalles del escenario

Esta arquitectura comparte un clúster de Kubernetes multiinquilino entre varios usuarios y cargas de trabajo que normalmente se conocen como inquilinos. Esta definición incluye diferentes equipos o divisiones dentro de una organización que comparten clústeres de Kubernetes. También incluye clústeres que comparten las instancias por cliente de una aplicación de software como servicio (SaaS). El uso de varios inquilinos de clústeres es una alternativa a la administración de muchos clústeres dedicados de un solo inquilino. Los operadores de un clúster de Kubernetes multiinquilino deben aislar los inquilinos entre sí. Este aislamiento minimiza el daño que un inquilino en peligro o malintencionado puede hacer al clúster y a otros inquilinos. Cuando varios usuarios o equipos comparten el mismo clúster que tiene un número fijo de nodos, un equipo podría usar más recursos de los que necesitan. Los administradores pueden usar cuotas de recursos para solucionar este problema.

Al planear la compilación de un clúster de AKS multiinquilino, debe tener en cuenta las capas de aislamiento de recursos que proporciona Kubernetes, incluido el clúster, el espacio de nombres, el nodo, el pod y el aislamiento del contenedor. También debe tener en cuenta las implicaciones de seguridad de compartir distintos tipos de recursos entre varios inquilinos. Por ejemplo, si programa pods de distintos inquilinos en el mismo nodo, puede reducir el número de máquinas que necesita en el clúster. Por otro lado, es posible que tenga que evitar que se coloquen determinadas cargas de trabajo. Por ejemplo, es posible que no permita que el código que no sea de confianza de fuera de la organización se ejecute en el mismo nodo que los contenedores que procesan información confidencial. Puede usar Azure Policy para que solo los registros de confianza se puedan implementar en AKS.

Kubernetes no puede garantizar un aislamiento perfectamente seguro entre inquilinos, pero ofrece características que proporcionan seguridad suficiente para casos de uso específicos. Como procedimiento recomendado, debe separar cada inquilino y sus recursos de Kubernetes en sus propios espacios de nombres. Después, puede usar RBAC de Kubernetes y directivas de red para ayudar a aplicar el aislamiento de inquilinos. Por ejemplo, en el diagrama siguiente se muestra un modelo de proveedor de SaaS típico que hospeda varias instancias de la misma aplicación en el mismo clúster, una para cada inquilino. Cada aplicación está en un espacio de nombres independiente. Cuando los inquilinos necesitan un mayor nivel de aislamiento físico y rendimiento garantizado, sus cargas de trabajo se pueden implementar en un conjunto dedicado de nodos, un grupo dedicado o incluso un clúster dedicado.

AGIC es una aplicación de Kubernetes, por lo que los clientes de AKS pueden usar una puerta de enlace de aplicaciones para exponer sus aplicaciones en contenedores a Internet. AGIC supervisa el clúster de Kubernetes en el que se hospeda y actualiza continuamente una puerta de enlace de aplicaciones para que los servicios seleccionados se expongan a Internet. El AGIC se ejecuta en su propio pod en la instancia de AKS del cliente. AGIC supervisa un subconjunto de recursos de Kubernetes para ver los cambios. El estado del clúster de AKS se traduce a la configuración específica de Application Gateway y se aplica a Resource Manager. En esta arquitectura se describen prácticas probadas para implementar un clúster de AKS público o privado a través de una puerta de enlace de aplicaciones y un complemento AGIC.

Una sola instancia de AGIC puede ingerir eventos de y observar varios espacios de nombres. Si el administrador de AKS usa Application Gateway como entrada, todos los espacios de nombres usan la misma instancia de Application Gateway. Una única instalación de AGIC supervisa los espacios de nombres accesibles y configura la puerta de enlace de aplicaciones a la que está asociada.

Posibles casos de uso

Use AGIC para exponer y proteger las cargas de trabajo accesibles desde Internet que se ejecutan en un clúster de AKS en un entorno multiinquilino.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Algunas de estas consideraciones no pertenecen completamente al multiinquilino en AKS, pero son requisitos esenciales de esta solución. Estas consideraciones incluyen la seguridad, el rendimiento, la disponibilidad, la confiabilidad, el almacenamiento, el programador, la malla de servicio y las instrucciones de supervisión.

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.

Estas consideraciones de disponibilidad y confiabilidad no pertenecen completamente al multiinquilino en AKS, pero son requisitos esenciales de esta solución. Tenga en cuenta las siguientes maneras de optimizar la disponibilidad para el clúster y las cargas de trabajo de AKS.

Contenedores

• Use sondeos de estado de Kubernetes para comprobar que los contenedores están activos y en buen estado:

  • livenessProbe indica si el contenedor se está ejecutando. Si se produce un error en el sondeo de ejecución, kubelet finaliza el contenedor y el contenedor está sujeto a su directiva de reinicio.

  • readinessProbe indica si el contenedor está listo para responder a las solicitudes. Si se produce un error en el sondeo de preparación, el controlador de punto de conexión quita la dirección IP del pod de los puntos de conexión de todos los servicios que coinciden con el pod. Estado predeterminado de preparación antes de que se produzca un error en el retraso inicial.

  • StartupProbe indica si se inicia la aplicación dentro del contenedor. Si tiene un sondeo de inicio, todos los demás sondeos se deshabilitan hasta que el sondeo de inicio se realice correctamente. Si se produce un error en el sondeo de inicio, kubelet finaliza el contenedor y el contenedor está sujeto a su directiva de reinicio.

• La contención de recursos puede afectar a la disponibilidad del servicio. Defina restricciones de recursos para los contenedores, para que un único contenedor no pueda sobrecargar los recursos de memoria y CPU del clúster. Puede usar diagnósticos de AKS para identificar cualquier problema en el clúster.

• Use el límite de recursos para restringir el total de recursos asignados a un contenedor para que un contenedor no pueda privar a otros.

Container Registry

• Almacene imágenes de contenedor en Container Registry. Use la replicación geográfica de Container Registry para replicar geográficamente el registro en cada región de AKS. La replicación geográfica es una característica de Premium SKU Container Registry.

• Examine las imágenes de contenedor para detectar vulnerabilidades. Implemente solo imágenes que pasen la validación. Actualice regularmente las imágenes base y el entorno de ejecución de la aplicación y luego vuelva a implementar las cargas de trabajo en el clúster de AKS.

• Limite los registros de imágenes que pueden usar los pods y las implementaciones. Restrinja el acceso a los registros de confianza donde puede validar y controlar las imágenes que están disponibles.

• Examine las imágenes de contenedor para detectar vulnerabilidades como parte de una canalización de integración continua y entrega continua (CI/CD) antes de publicar imágenes en Container Registry. Al usar imágenes base para imágenes de aplicación, use la automatización para crear nuevas imágenes al actualizar la imagen base. Las imágenes base suelen incluir correcciones de seguridad, por lo que debe actualizar las imágenes de contenedor de aplicaciones de bajada. Se recomienda integrar Azure Defender for Containers en flujos de trabajo de CI/CD. Para más información, consulte Automatización de compilaciones de imágenes de contenedor.

• Use tareas de Container Registry para automatizar la aplicación de revisiones del sistema operativo y del marco para los contenedores de Docker. Las tareas de Container Registry admiten un proceso de compilación automatizado al actualizar la imagen base de un contenedor. Por ejemplo, puede aplicar revisiones al sistema operativo o al marco de la aplicación en una de las imágenes base.

Resistencia dentro de una región

• Considere la posibilidad de implementar los grupos de nodos del clúster de AKS en todas las zonas de disponibilidad de una región. Use Azure Standard Load Balancer o Application Gateway delante de los grupos de nodos. Esta topología proporciona una mejor resistencia si se produce una interrupción de un solo centro de datos. Este método distribuye los nodos de clúster entre varios centros de datos que residen en tres zonas de disponibilidad independientes dentro de una región.

• Habilite la redundancia de zona en Container Registry para lograr resistencia dentro de una región y alta disponibilidad.

• Use restricciones de propagación de topología de pod para controlar cómo se distribuyen los pods en el clúster de AKS entre dominios de error, como regiones, zonas de disponibilidad y nodos.

• Considere la posibilidad de usar un acuerdo de nivel de servicio (SLA) de tiempo de actividad para clústeres de AKS que hospedan cargas de trabajo críticas. Un Acuerdo de Nivel de Servicio de tiempo de actividad es una característica opcional para habilitar un Acuerdo de Nivel de Servicio con respaldo financiero y superior para un clúster. Un Acuerdo de Nivel de Servicio de tiempo de actividad garantiza una disponibilidad del 99,95 % del punto de conexión del servidor de API de Kubernetes para clústeres que usan zonas de disponibilidad. Garantiza una disponibilidad del 99,90 % para los clústeres que no usan zonas de disponibilidad. AKS usa réplicas de nodo del plano de control entre dominios de actualización y error para ayudar a cumplir los requisitos del Acuerdo de Nivel de Servicio.

Recuperación ante desastres y continuidad empresarial

• Considere la posibilidad de implementar la solución en al menos dos regiones de Azure emparejadas dentro de una geografía. También debe adoptar un equilibrador de carga global, como Azure Traffic Manager o Azure Front Door. Combine el equilibrador de carga con un método de enrutamiento activo/activo o activo/pasivo para ayudar a garantizar la continuidad empresarial y la recuperación ante desastres.

• Cree scripts, documente y pruebe periódicamente los procesos de conmutación por error regionales en un entorno de control de calidad. Los procesos de conmutación por error ayudan a evitar problemas imprevisibles si una interrupción en la región primaria afecta a un servicio principal.

• Use pruebas de proceso de conmutación por error para comprobar si el enfoque de recuperación ante desastres cumple los objetivos de objetivo de punto de recuperación (RPO) y de tiempo de recuperación (RTO). Incluya procesos manuales e intervenciones en la verificación.

• Pruebe los procedimientos de conmutación por recuperación para asegurarse de que funcionan según lo previsto.

• Almacene las imágenes de contenedor en Container Registry. Replique geográficamente el registro en cada región de AKS. Para más información, consulte Replicación geográfica en Container Registry.

• Evite almacenar el estado del servicio dentro de un contenedor, siempre que sea posible. En su lugar, use una plataforma como servicio de Azure que admita la replicación en varias regiones.

• Prepare y pruebe cómo migrar el almacenamiento de la región primaria a la región de copia de seguridad si usa Azure Storage.

• Considere la posibilidad de usar GitOps para implementar la configuración del clúster. GitOps proporciona uniformidad entre los clústeres de recuperación ante desastres y principal y también proporciona una manera rápida de recompilar un nuevo clúster si pierde uno.

• Considere la posibilidad de realizar copias de seguridad y restauración de la configuración del clúster mediante herramientas como copias de seguridad de AKS o Velero.

Malla de servicio

• Considere la posibilidad de usar una malla de servicio de código abierto, como Istio, Linkerd o Consul, en el clúster de AKS. Una malla de servicio usa TLS mutuo para ayudar a mejorar la observabilidad, la confiabilidad y la seguridad de los microservicios. También puede implementar estrategias de división de tráfico, como implementaciones azules o verdes e implementaciones controladas. Una malla de servicio es una capa de infraestructura dedicada que ayuda a que la comunicación entre servicios sea más segura, rápida y confiable. Para obtener más información, consulte Complemento de AKS de malla de servicio istio.

• Considere la posibilidad de adoptar Dapr para crear aplicaciones basadas en microservicios resistentes, tanto si son sin estado como si tienen estado. Puede usar cualquier lenguaje de programación y marco de desarrollo.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para obtener más información, consulte Lista de comprobación de revisión de diseño para seguridad.

Las consideraciones de seguridad no pertenecen completamente al multiinquilino en AKS, pero son requisitos esenciales de esta solución.

Multiinquilino

• Diseñe clústeres de AKS para el uso de varios inquilinos. Kubernetes proporciona características que puede usar para aislar lógicamente equipos y cargas de trabajo en el mismo clúster. Proporcione el menor número de privilegios a los recursos que necesita cada equipo. Un espacio de nombres en Kubernetes crea un límite de aislamiento lógico.

• Use el aislamiento lógico para separar los equipos y proyectos. Minimice el número de clústeres de AKS físicos que implemente para aislar equipos o aplicaciones. Normalmente, la separación lógica de los clústeres proporciona una mayor densidad de pods que los clústeres aislados físicamente.

• Use grupos de nodos dedicados o clústeres de AKS dedicados siempre que necesite implementar un aislamiento físico estricto. Por ejemplo, puede dedicar un grupo de nodos de trabajo o un clúster completo a un equipo o un inquilino en un entorno multiinquilino.

  Use una combinación de taints y tolerations para controlar la implementación de pods en un grupo de nodos específico. Solo puede taint un nodo en AKS en el momento de la creación del grupo de nodos. Como alternativa, puede usar etiquetas y selectores nodePool para implementar la carga de trabajo solo en grupos de nodos específicos.

Seguridad de las redes

• Cree un punto de conexión privado para cualquier servicio PaaS que usen las cargas de trabajo de AKS, como Key Vault, Azure Service Bus o Azure SQL Database. Un punto de conexión privado ayuda a garantizar que el tráfico entre las aplicaciones y estos servicios no esté expuesto a la red pública de Internet. Para obtener más información, consulte ¿Qué es Private Link?

• Configure el recurso de entrada de Kubernetes para exponer cargas de trabajo a través de HTTPS. Use un subdominio independiente y un certificado digital para cada inquilino. AGIC configura automáticamente el agente de escucha de Application Gateway para la terminación SSL.

• Configure Application Gateway para usar una directiva de WAF para ayudar a proteger las cargas de trabajo orientadas al público que se ejecutan en AKS frente a ataques malintencionados.

• Use redes de Azure CNI en AKS para integrarse con redes virtuales existentes o redes locales. Este modelo de red también permite mayor separación de los recursos y los controles en un entorno empresarial.

• Use directivas de red para segregar y proteger las comunicaciones entre servicios mediante el control de qué componentes pueden comunicarse entre sí. De manera predeterminada, todos los pods de un clúster de Kubernetes pueden enviar y recibir tráfico sin limitaciones. Para mejorar la seguridad, puede usar directivas de red de Azure o directivas de red de Calico para definir reglas que controlen el flujo de tráfico entre varios microservicios. Para obtener más información, consulte Directiva de red.

• No exponga la conectividad remota a los nodos de AKS. Cree un host bastión o jumpbox 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.

• Considere la posibilidad de usar intervalos de direcciones IP autorizados en AKS para crear un clúster de AKS privado en el entorno de producción. Si no puede usar un clúster de AKS privado, al menos un acceso seguro al servidor de API.

• Combine Azure DDoS Protection con procedimientos recomendados de diseño de aplicaciones para proporcionar características mejoradas de mitigación de DDoS y defensa adicional contra ataques DDoS. Habilite DDoS Protection en redes virtuales perimetrales.

Autenticación y autorización

• Implementación de clústeres de AKS con integración de Microsoft Entra. Para más información, consulte Integración de Microsoft Entra administrado por AKS. Microsoft Entra ID centraliza el componente de administración de identidades.

• Use RBAC de Kubernetes para definir los permisos que los usuarios o grupos tienen en relación con los recursos del clúster. Use roles o ClusterRoles y enlaces para definir el ámbito de los usuarios o grupos al menor número de permisos necesarios. Integre RBAC de Kubernetes con el identificador de Entra de Microsoft para que cualquier cambio en el estado de usuario o la pertenencia a grupos actualice automáticamente el acceso a los recursos del clúster. Para más información, consulte RBAC de Kubernetes.

• Use Azure RBAC para definir los permisos mínimos necesarios que los usuarios o grupos tienen para recursos de AKS en una o más suscripciones. Para más información, consulte Uso de la autorización de Azure RBAC para Kubernetes.

• Use Id. de carga de trabajo de Microsoft Entra para asignar una identidad administrada a microservicios individuales para el acceso a recursos de Azure. A continuación, el microservicio puede acceder a los recursos administrados, como Key Vault, SQL Database, Service Bus y Azure Cosmos DB. El microservicio no necesita almacenar y recuperar cadena de conexión o credenciales de secretos de Kubernetes.

• Use el controlador CSI del almacén de secretos para Key Vault para acceder a secretos, como credenciales y cadenas de conexiones, desde Key Vault en lugar de secretos de Kubernetes.

• Combine el bloque de creación del almacén de secretos de Dapr con el almacén de Key Vault e identidades administradas en Kubernetes para recuperar secretos, como credenciales y cadena de conexión s, desde Key Vault.

Carga de trabajo y clúster

• Protección del acceso al servidor de API de Kubernetes para ayudar a proteger el clúster. Integre RBAC de Kubernetes con Microsoft Entra ID para controlar el acceso al servidor de API. Use estos controles para ayudar a proteger AKS de la misma manera que para el acceso a la suscripción de Azure.

• Limite el acceso a las acciones que los contenedores pueden realizar. Use la característica De admisión de seguridad de pods para habilitar la autorización específica de la creación y las actualizaciones del pod. Proporcione el menor número de permisos, y evite el uso de la raíz o de elevación de privilegios. Para más información, consulte Protección del acceso de pod a los recursos.

• Evite ejecutar contenedores como usuario raíz siempre que sea posible.

• Use el módulo de seguridad del kernel AppArmor de Linux para limitar las acciones que pueden realizar los contenedores.

• Actualice los clústeres de AKS a la versión más reciente de Kubernetes periódicamente para aprovechar las nuevas características y correcciones de errores.

• Use el demonio kured para buscar reinicios pendientes, acordonar y purgar nodos, y aplicar actualizaciones. AKS descarga e instala automáticamente correcciones de seguridad en cada uno de los nodos Linux, pero no reinicia el nodo automáticamente en caso de que sea necesario. Para los nodos de Windows Server, ejecute periódicamente una operación de actualización de AKS para acordonar y drenar los pods de forma segura, e implemente los nodos actualizados.

• Considere la posibilidad de usar protocolos de transporte seguros https y gRPC para todas las comunicaciones dentro del pod. Y use un mecanismo de autenticación más avanzado que no requiera que envíe las credenciales sin formato en cada solicitud, como Open Authorization (OAuth) o JSON Web Tokens (JWT). Establezca una comunicación intraservicio más segura mediante una malla de servicio, como Istio, Linkerd o Consul. O bien, puede usar Dapr.

Container Registry

Examine las imágenes de contenedor para detectar vulnerabilidades e implemente solo imágenes que superen la validación. Actualice periódicamente las imágenes base y el entorno de ejecución de la aplicación. A continuación, vuelva a implementar cargas de trabajo en el clúster de AKS. El flujo de trabajo de implementación de CI/CD debe incluir un proceso para examinar imágenes de contenedor. Puede usar la seguridad de Microsoft Defender para DevOps para examinar el código de las vulnerabilidades de las canalizaciones automatizadas durante las fases de compilación e implementación. Como alternativa, puede usar herramientas como Prisma Cloud o Aqua para examinar y permitir que solo se implementen imágenes verificadas.

Optimización de costos

La optimización de costes trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.

El costo de esta arquitectura depende de los aspectos de configuración, como los siguientes componentes:

• Niveles de servicio
• Escalabilidad o el número de instancias que los servicios asignan dinámicamente para admitir una demanda determinada
• Scripts de automatización
• El nivel de recuperación ante desastres.

Después de evaluar estos aspectos, use la calculadora de precios de Azure para calcular los costos. Para obtener más información, consulte los principios del marco bien diseñado de optimización de costos.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.

Storage

• Considere la posibilidad de implementar el clúster de AKS con discos de sistema operativo efímeros que proporcionan una latencia de lectura y escritura más baja, junto con el escalado de nodos más rápido y las actualizaciones del clúster.

• Comprenda las necesidades de la aplicación para elegir el almacenamiento adecuado. Use almacenamiento respaldado por SSD de alto rendimiento para cargas de trabajo de producción. Planee un sistema de almacenamiento basado en red, como Azure Files, cuando varios pods necesiten acceder simultáneamente a los mismos archivos. Para más información, consulte Opciones de almacenamiento para aplicaciones en AKS.

• Planee las demandas de la aplicación para implementar el tamaño adecuado de los nodos. Cada tamaño de nodo tiene un límite máximo de discos. Los diferentes tamaños de nodos también proporcionan distintas cantidades de almacenamiento local y de ancho de banda de red.

• Use el aprovisionamiento dinámico. Para reducir la sobrecarga de administración y habilitar el escalado, no cree ni asigne volúmenes persistentes estáticamente. En las clases de almacenamiento, defina la directiva de reclamación adecuada para minimizar los costos de almacenamiento innecesarios después de eliminar pods.

DevOps

• Use un sistema de DevOps, como Acciones de GitHub o Azure DevOps, para implementar las cargas de trabajo en AKS a través de un gráfico de Helm en una canalización de CI/CD. Para más información, consulte Compilación e implementación en AKS.

• Introduzca las implementaciones controladas y pruebas A/B en la administración del ciclo de vida de la aplicación para probar correctamente una aplicación antes de presentarla a todos los usuarios. Hay varias técnicas que puede usar para dividir el tráfico entre distintas versiones del mismo servicio.

• Como alternativa, puede usar las funcionalidades de administración del tráfico que proporciona una malla de servicio. Para más información, consulte Administración del tráfico de Istio.

• Use Container Registry u otro almacén de registros, como Docker Hub, para catalogar y servir las imágenes privadas de Docker que implemente en el clúster. AKS puede usar su identidad de Microsoft Entra para autenticarse con Container Registry.

• Si necesita cambiar la configuración en Application Gateway, realice el cambio mediante la configuración expuesta en el controlador de entrada u otros objetos de Kubernetes, como el uso de anotaciones admitidas. Después de vincular una puerta de enlace de aplicaciones al AGIC, el controlador de entrada sincroniza y controla casi todas las configuraciones de esa puerta de enlace. Si configura Application Gateway de forma imperativa o a través de la infraestructura como código, el controlador de entrada finalmente sobrescribe esos cambios.

Supervisión

• Considere las opciones de supervisión integradas de Azure para supervisar el estado de mantenimiento del clúster de AKS y las cargas de trabajo.

• Configure todos los servicios PaaS, como Container Registry y Key Vault, para recopilar registros y métricas de diagnóstico y enviarlos a Log Analytics.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

Las consideraciones de rendimiento no pertenecen completamente al multiinquilino en AKS, pero son requisitos esenciales de esta solución:

• Para cargas de trabajo de baja latencia, considere la posibilidad de implementar un grupo de nodos dedicado en un grupo de selección de ubicación por proximidad. Al implementar la aplicación en Azure, las instancias de máquina virtual que se distribuyen entre regiones o zonas de disponibilidad crean latencia de red, lo que podría afectar al rendimiento general de la aplicación. Un grupo de selección de ubicación por proximidad es una agrupación lógica que puede usar para asegurarse de que los recursos de proceso de Azure se encuentran físicamente cerca entre sí. Algunos casos de uso, como juegos, simulaciones de ingeniería y trading de alta frecuencia, requieren baja latencia y tareas que se completan rápidamente. Para escenarios informáticos de alto rendimiento, como estos, considere la posibilidad de usar grupos de selección de ubicación de proximidad para los grupos de nodos del clúster.

• Use siempre imágenes de contenedor más pequeñas porque puede crear compilaciones más rápidas. Las imágenes más pequeñas también son menos vulnerables a los vectores de ataque debido a una superficie expuesta a ataques reducida.

• Use el escalado automático de Kubernetes para escalar horizontalmente dinámicamente el número de nodos de trabajo de un clúster de AKS cuando aumenta el tráfico. Con horizontal Pod Autoscaler y un escalador automático de clústeres, los volúmenes de nodos y pods se ajustan dinámicamente en tiempo real para que coincidan con la condición de tráfico y para evitar tiempos de inactividad que provocan problemas de capacidad. Para más información, consulte Uso de la escalabilidad automática en AKS.

Scheduler

• Revise e implemente procedimientos recomendados para que los operadores de clúster y los desarrolladores de aplicaciones compilen y ejecuten aplicaciones correctamente en AKS.

• Planee y aplique cuotas de recursos en el nivel de espacio de nombres para todos los espacios de nombres. Si los pods no definen solicitudes y límites de recursos, rechace la implementación. Supervise el uso de recursos y ajuste las cuotas según sea necesario. Cuando varios equipos o inquilinos comparten un clúster de AKS que tiene un número fijo de nodos, puede usar cuotas de recursos para asignar un recurso compartido justo de recursos a cada equipo o inquilino.

• Adopte intervalos de límite para restringir las asignaciones de recursos a pods o contenedores en un espacio de nombres, en términos de CPU y memoria.

• Defina explícitamente las solicitudes de recursos y los límites para el uso de CPU y memoria para los pods en los manifiestos de YAML o gráficos de Helm que se usan para implementar aplicaciones. Al especificar la solicitud de recursos para contenedores en un pod, el programador de Kubernetes usa esta información para decidir en qué nodo colocar el pod. Cuando se especifica un límite de recursos para un contenedor, como la CPU o la memoria, kubelet aplica esos límites para que el contenedor en ejecución no pueda usar más de ese recurso que el límite establecido.

• Mantenga la disponibilidad de las aplicaciones mediante la definición de presupuestos de interrupciones de pods para asegurarse de que hay un número mínimo de pods disponibles en el clúster.

• Use clases de prioridad para indicar la importancia de un pod. Si el programador no puede programar un pod, intenta adelantar o expulsar pods de prioridad inferior para que pueda programar el pod pendiente.

• Use taints y tolerations de Kubernetes para colocar aplicaciones intensivas en recursos en nodos específicos y para evitar problemas ruidosos de vecinos. Mantenga los recursos de nodo disponibles para las cargas de trabajo que las requieran. No permita que otras cargas de trabajo se programe en los nodos.

• Use selectores de nodos, afinidad de nodo o afinidad entre pods para controlar la programación de pods en los nodos. Use la afinidad entre pods y la configuración de antiafinidad para colocar pods que tengan comunicaciones de chatty, para colocar pods en distintos nodos y para evitar ejecutar varias instancias del mismo tipo de pod en el mismo nodo.

Implementación de este escenario

El código fuente de este escenario está disponible en GitHub. En el diagrama siguiente se muestra una aplicación de demostración que puede encontrar en el repositorio de GitHub multiinquilino de AKS AGIC.

Descargue un archivo Visio de esta arquitectura.

Requisitos previos

En el caso de las implementaciones en línea, tiene que tener ya una cuenta de Azure. Si no la tiene, cree una cuenta gratuita de Azure antes de empezar.

Implementación en Azure

1. Asegúrese de que tiene a mano la información de su suscripción de Azure.

2. Clone el repositorio de GitHub de workbench:

   git clone https://github.com/Azure-Samples/aks-agic.git
   

3. Siga las instrucciones proporcionadas en el archivo README.md.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

• Paolo Salvatori | Ingeniero de servicio principal

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

• Procedimientos recomendados para clústeres de AKS
• Procedimientos recomendados para las características básicas del programador en AKS
• Creación de un clúster privado de AKS
• Creación de directivas waf para Application Gateway
• Diferencia entre una implementación de Helm y el complemento de AKS
• Funcionamiento de una instancia de Application Gateway

Recursos relacionados

• Arquitectura de línea de base para un clúster de AKS