Compartir a través de

Preparación para implementar la carga de trabajo de aplicaciones web de Amazon Web Services (AWS) en Azure

En este artículo se proporciona una guía completa sobre cómo implementar una infraestructura sólida y lista para producción para facilitar el hospedaje, la protección, el escalado y la supervisión de una aplicación web en la plataforma de Azure.

Implementación de Yelb en AWS

La aplicación web de muestra Yelb en AWS se implementa usando Bash, la CLI de AWS, eksctl, kubectl y Helm. La muestra complementaria contiene scripts de Bash y manifiestos YAML que puede usar para automatizar la implementación de la aplicación Yelb en AWS Elastic Kubernetes Service (EKS). Esta solución muestra cómo implementar un firewall de aplicaciones web mediante AWS WAF para proteger una aplicación web que se ejecuta en Amazon Elastic Kubernetes Service (EKS). Puede usar los scripts de Bash para crear un clúster EKS e implementar la aplicación Yelb. La aplicación web Yelb se expone a la Internet pública utilizando una instancia de Amazon Application Load Balancer (ALB) y se protege utilizando la Lista de control de acceso web (web ACL) de AWS WAF. Para obtener instrucciones detalladas, consulte Portabilidad de una aplicación web de AWS Elastic Kubernetes Service (EKS) a Azure Kubernetes Service (AKS).

Captura de pantalla de la interfaz del servicio Yelb.

Implementación de Yelb en Azure

En las siguientes secciones, aprenderá a implementar la aplicación web de muestra Yelb en un clúster de Azure Kubernetes Service (AKS) y a exponerla a través de un controlador de entrada como el controlador de entrada de NGINX. El servicio del controlador de entrada es accesible a través de un equilibrador de carga interno (o privado), que equilibra el tráfico dentro de la red virtual que contiene el clúster de AKS. También se puede acceder a un servidor front-end del equilibrador de carga desde una red local en un escenario híbrido. Para más información sobre el equilibrio de carga interno, consulte Uso de un equilibrador de carga interno con Azure Kubernetes Service (AKS).

La muestra complementaria permite instalar un controlador de entrada NGINX administrado con el complemento de enrutamiento de aplicaciones o un controlador de entrada NGINX no administrado utilizando el gráfico de Helm. El complemento de enrutamiento de aplicaciones con el controlador de entrada NGINX proporciona las siguientes características:

Para otras configuraciones:

Para mejorar la seguridad, la aplicación Yelb está protegida por un recurso de Azure Application Gateway. Este recurso se implementa en una subred dedicada dentro de la misma red virtual que el clúster de AKS o en una red virtual emparejada. Azure Web Application Firewall (WAF) protege el acceso a la aplicación web hospedada en Azure Kubernetes Service (AKS) y expuesta a través de Azure Application Gateway frente a vulnerabilidades comunes.

Prerrequisitos

Arquitectura

Esta muestra proporciona una colección de plantillas de Bicep, scripts de Bash y manifiestos de YAML para compilar un clúster de AKS, implementar la aplicación Yelb, exponer el servicio de interfaz de usuario mediante el controlador de entrada de NGINX y protegerlo con Azure Application Gateway y Azure Web Application Firewall (WAF).

Esta muestra también incluye dos archivos de parámetros Bicep separados y dos conjuntos de scripts de Bash y manifiestos YAML, cada uno orientado a implementar dos opciones de solución diferentes. Para más información sobre Bicep, consulte ¿Qué es Bicep?

Terminación TLS en Application Gateway e invocación de Yelb a través de HTTP

En esta solución, Azure Web Application Firewall (WAF) garantiza la seguridad del sistema bloqueando los ataques maliciosos. Azure Application Gateway recibe llamadas entrantes de aplicaciones cliente, realiza la terminación TLS y reenvía las solicitudes al servicio de yelb-ui hospedado en AKS. Esta comunicación se logra mediante el equilibrador de carga interno y el controlador de entrada NGINX mediante el protocolo de transporte HTTP. En el diagrama siguiente se muestra la arquitectura:

Diagrama de la solución basada en Application Gateway WAFv2 y el controlador de entrada NGINX a través de HTTP.

El flujo de mensajes es el siguiente:

Diagrama del flujo de mensajes de la solución basada en Application Gateway WAFv2 y el controlador de entrada NGINX a través de HTTP.

  1. Azure Application Gateway controla la terminación TLS y envía llamadas entrantes al servicio yelb-ui hospedado en AKS a través de HTTP.
  2. El agente de escucha de Application Gateway usa un certificado SSL obtenido de Azure Key Vault para garantizar una comunicación segura.
  3. La directiva de WAF de Azure asociada con el agente de escucha aplica reglas de OWASP y reglas personalizadas a las solicitudes entrantes, lo que impide de forma eficaz muchos tipos de ataques malintencionados.
  4. La configuración HTTP de back-end de Application Gateway invoca la aplicación Yelb a través de HTTP mediante el puerto 80.
  5. El grupo de back-end y el sondeo de estado de Application Gateway llaman al controlador de entrada NGINX a través del equilibrador de carga interno de AKS mediante el protocolo HTTP para la administración del tráfico.
  6. El controlador de entrada NGINX usa el equilibrador de carga interno de AKS para garantizar una comunicación segura dentro del clúster.
  7. Un objeto de entrada de Kubernetes usa el controlador de entrada NGINX para exponer la aplicación mediante HTTP a través del equilibrador de carga interno.
  8. El servicio yelb-ui con el tipo ClusterIP restringe su invocación al interior del clúster o a través del controlador de entrada NGINX.

Implementación de TLS de un extremo a otro mediante Azure Application Gateway

Finalización de TLS

Azure Application Gateway admite la terminación TLS en el nivel de puerta de enlace, lo que significa que el tráfico se descifra en la puerta de enlace antes de enviarse a los servidores back-end. Para configurar la terminación TLS, debe agregar un certificado TLS/SSL al agente de escucha. El certificado debe estar en formato de Intercambio de información personal (PFX), que contiene las claves privadas y públicas. Puede importar el certificado de Azure Key Vault a Application Gateway. Para más información, consulte Terminación TLS con certificados de Key Vault.

Modelo de seguridad de Confianza cero

Si adopta un modelo de seguridad de Confianza cero, debería evitar la comunicación no cifrada entre un proxy de servicio como Azure Application Gateway y los servidores de back-end. Con el modelo de seguridad de Confianza cero, la confianza no se concede automáticamente a ningún usuario o dispositivo que intente acceder a los recursos de una red. En su lugar, requiere la comprobación continua de la identidad y la autorización de cada solicitud, independientemente de la ubicación o la red del usuario. En nuestro escenario, la implementación del modelo de seguridad de Confianza cero implica el uso de Azure Application Gateway como proxy de servicio, que actúa como front-end para las solicitudes entrantes. Estas solicitudes se desplazan al controlador de entrada NGINX en Azure Kubernetes Service (AKS) en un formato cifrado.

TLS de un extremo a otro con Application Gateway

Puede implementar un enfoque de Confianza cero mediante la configuración de Azure Application Gateway para el cifrado TLS de un extremo a otro con los servidores back-end. El cifrado TLS de un extremo a otro le permite transmitir de forma segura datos confidenciales al back-end a la vez que aprovecha las características de equilibrio de carga de la capa 7 de Application Gateway, incluida la afinidad de sesión basada en cookies, el enrutamiento basado en URL, el enrutamiento basado en sitios y la capacidad de reescribir o inyectar encabezados X-Forwarded-*.

Cuando se configura con el modo de comunicación de TLS de un extremo a otro, Application Gateway finaliza las sesiones TLS en la puerta de enlace y descifra el tráfico de usuario. Después, aplica las reglas configuradas para seleccionar una instancia de grupo de back-end adecuada en la que enrutar el tráfico. Posteriormente, Application Gateway inicia una nueva conexión TLS al servidor back-end y vuelve a cifrar los datos mediante el certificado de clave pública del servidor back-end antes de transmitir la solicitud al back-end. La respuesta del servidor web sigue el mismo proceso antes de llegar al usuario final. Para habilitar TLS de un extremo a otro, debe establecer la configuración del protocolo en configuración HTTP de back-end en HTTPS y aplicarla a un grupo de back-end. Este enfoque garantiza que la comunicación con los servidores back-end esté protegida y conforme a sus requisitos.

Para más información, consulte Cifrado TLS de un extremo a otro de Application Gateway y Procedimientos recomendados para proteger su Application Gateway.

En esta solución, Azure Web Application Firewall (WAF) garantiza la seguridad del sistema bloqueando los ataques maliciosos. Azure Application Gateway controla las llamadas entrantes de las aplicaciones cliente, realiza la terminación TLS e implementa TLS de un extremo a otro invocando el servicio yelb-ui hospedado en AKS subyacente mediante el protocolo de transporte HTTPS a través del equilibrador de carga interno y el controlador de entrada NGINX. En el diagrama siguiente se muestra la arquitectura:

Diagrama de la solución basada en Application Gateway WAFv2 y controlador de entrada NGINX a través de HTTPS.

El flujo de mensajes es el siguiente:

  1. Azure Application Gateway controla la terminación TLS y se comunica con la aplicación back-end a través de HTTPS.
  2. El agente de escucha de Application Gateway usa un certificado SSL obtenido de Azure Key Vault.
  3. La directiva de WAF de Azure asociada con el agente de escucha ejecuta reglas de OWASP y reglas personalizadas en las solicitudes entrantes para bloquear ataques malintencionados.
  4. La configuración HTTP de back-end de Application Gateway está configurada para invocar el servicio yelb-ui hospedado en AKS a través de HTTPS en el puerto 443.
  5. El grupo de back-end y el sondeo de estado de Application Gateway llaman al controlador de entrada NGINX a través del equilibrador de carga interno de AKS mediante HTTPS.
  6. El controlador de entrada NGINX se implementa para usar el equilibrador de carga interno de AKS.
  7. El clúster de SAKS se configura con el proveedor de Azure Key Vault para el complemento del controlador de CSI del Almacén de secretos para recuperar secretos, certificados y claves de Azure Key Vault a través de un volumen de CSI.
  8. SecretProviderClass se usa para recuperar el certificado usado por Application Gateway desde Key Vault.
  9. Un objeto de entrada de Kubernetes usa el controlador de entrada NGINX para exponer la aplicación mediante HTTPS a través del equilibrador de carga interno de AKS.
  10. El servicio yelb-ui tiene un tipo ClusterIP, que restringe su invocación al interior del clúster o a través del controlador de entrada NGINX.

Para ayudar a garantizar la seguridad y la estabilidad del sistema, tenga en cuenta las siguientes recomendaciones:

  • Actualice periódicamente Azure WAF Policy con las reglas más recientes para garantizar una seguridad óptima.
  • Implemente mecanismos de supervisión y registro para realizar un seguimiento y analizar las solicitudes entrantes y los posibles ataques.
  • Realice periódicamente el mantenimiento y las actualizaciones del clúster de AKS, el controlador de entrada NGINX y Application Gateway para solucionar cualquier vulnerabilidad de seguridad y mantener una infraestructura segura.
  • Implemente mecanismos de supervisión y registro para realizar un seguimiento y analizar las solicitudes entrantes y los posibles ataques.
  • Realice periódicamente el mantenimiento y las actualizaciones del clúster de AKS, el controlador de entrada NGINX y Application Gateway para solucionar cualquier vulnerabilidad de seguridad y mantener una infraestructura segura.

Nombre de host

El agente de escucha de Application Gateway y la entrada de Kubernetes están configurados para usar el mismo nombre de host. Es importante usar el mismo nombre de host para un proxy de servicio y una aplicación web de back-end por los siguientes motivos:

  • Conservación del estado de sesión: cuando se usa un nombre de host diferente para el proxy y la aplicación de back-end, el estado de sesión se puede perder. Esto significa que es posible que las sesiones de usuario no se conserven correctamente, lo que da lugar a una mala experiencia del usuario y a una posible pérdida de datos.
  • Error de autenticación: si el nombre de host difiere entre el proxy y la aplicación de back-end, es posible que se produzca un error en los mecanismos de autenticación. Este enfoque puede provocar que los usuarios no puedan iniciar sesión o acceder a recursos seguros dentro de la aplicación.
  • Exposición involuntaria de direcciones URL: si no se conserva el nombre de host, existe el riesgo de que las direcciones URL de back-end se expongan a los usuarios finales. Esto puede provocar posibles vulnerabilidades de seguridad y acceso no autorizado a información confidencial.
  • Problemas de cookies: las cookies desempeñan un papel fundamental para mantener las sesiones de usuario y pasar información entre el cliente y el servidor. Cuando el nombre de host difiere, es posible que las cookies no funcionen según lo previsto, lo que provoca problemas como la autenticación con errores, el control de sesión incorrecto y la redirección incorrecta.
  • Requisitos de TLS/SSL de un extremo a otro: si se requiere TLS/SSL de un extremo a otro para una comunicación segura entre el proxy y el servicio de back-end, es necesario un certificado TLS coincidente para el nombre de host original. El uso del mismo nombre de host simplifica el proceso de administración de certificados y garantiza que la comunicación segura se establezca sin problemas.

Puede evitar estos problemas mediante el mismo nombre de host para el proxy de servicio y la aplicación web back-end. La aplicación de back-end ve el mismo dominio que el explorador web, lo que garantiza que el estado de sesión, la autenticación y el control de direcciones URL funcionen correctamente.

Flujo de mensajes

En el diagrama siguiente se muestran los pasos para el flujo de mensajes durante la implementación y el tiempo de ejecución.

Diagrama del flujo de mensajes de la solución basada en Application Gateway WAFv2 y controlador de entrada NGINX a través de HTTPS.

Flujo de trabajo de implementación

En los pasos siguientes se describe el proceso de implementación. Este flujo de trabajo corresponde a los números verdes del diagrama anterior.

  1. Un ingeniero de seguridad genera un certificado para el dominio personalizado que usa la carga de trabajo y lo guarda en un almacén de claves de Azure. Puede obtener un certificado válido de una entidad de certificación (CA) conocida.
  2. Un ingeniero de plataforma especifica la información necesaria en el archivo de parámetros main.bicepparams de Bicep e implementa las plantillas de Bicep para crear los recursos de Azure. La información necesaria incluye:
    • Prefijo para los recursos de Azure.
    • El nombre y el grupo de recursos de la instancia de Azure Key Vault existente que contiene el certificado TLS para el nombre de host de la carga de trabajo y el dominio personalizado del cliente de escucha de Application Gateway.
  3. Puede configurar el script de implementación para instalar los siguientes paquetes en el clúster de AKS. Para más información, consulte la sección de parámetros del módulo de Bicep.
  4. El agente de escucha de Application Gateway recupera el certificado TLS de Azure Key Vault.
  5. El objeto de entrada de Kubernetes utiliza el certificado obtenido del proveedor de Azure Key Vault para el controlador de CSI del Almacén de Secretos para exponer el servicio de la interfaz de usuario de Yelb a través de HTTPS.
  6. El agente de escucha de Application Gateway recupera el certificado TLS de Azure Key Vault.
  7. El objeto de entrada de Kubernetes utiliza el certificado obtenido del proveedor de Azure Key Vault para el controlador de CSI del Almacén de Secretos para exponer el servicio de la interfaz de usuario de Yelb a través de HTTPS.

Flujo de trabajo en tiempo de ejecución

  1. La aplicación cliente llama a la aplicación web de ejemplo mediante su nombre de host. La zona DNS asociada al dominio personalizado del agente de escucha de Application Gateway usa un registro de A para resolver la consulta de DNS con la dirección IP pública de Azure usada por la configuración de IP de front-end de Application Gateway.
  2. La solicitud se envía a la dirección IP pública de Azure que usa la configuración IP de front-end de Application Gateway.
  3. Application Gateway realiza las siguientes acciones:
    1. Application Gateway controla la terminación TLS y se comunica con la aplicación back-end a través de HTTPS.
    2. El agente de escucha de Application Gateway usa un certificado SSL obtenido de Azure Key Vault.
    3. La directiva de WAF de Azure asociada al agente de escucha ejecuta reglas de OWASP y reglas personalizadas en la solicitud entrante y bloquea los ataques malintencionados.
    4. La configuración HTTP de back-end de Application Gateway está configurada para invocar la aplicación web de ejemplo a través de HTTPS en el puerto 443.
  4. El grupo de back-end de Application Gateway llama al controlador de entrada NGINX a través del equilibrador de carga interno de AKS mediante HTTPS.
  5. La solicitud se envía a uno de los nodos del agente que hospeda un pod del controlador de entrada NGINX.
  6. Una de las réplicas del controlador de entrada NGINX controla la solicitud y envía la solicitud a uno de los puntos de conexión de servicio del servicio de yelb-ui.
  7. yelb-ui llama al servicio de yelb-appserver.
  8. yelb-appserver llama a los servicios de yelb-db y yelb-cache.
  9. yelb-ui llama al servicio de yelb-appserver.
  10. yelb-appserver llama a los servicios de yelb-db y yelb-cache.

Despliegue

De manera predeterminada, las plantillas de Bicep instalan el clúster de AKS con el complemento de red Azure CNI Overlay y el plano de datos Cilium. Puede usar un complemento de red alternativo. Además, el proyecto muestra cómo implementar un clúster de AKS con las siguientes extensiones y características:

En un entorno de producción, se recomienda encarecidamente implementar un clúster de AKS privado con el Acuerdo de Nivel de Servicio de tiempo de actividad. Para más información, consulte clúster de AKS privado con una dirección DNS pública.

Como alternativa, puede implementar un clúster de AKS público y proteger el acceso al servidor de API mediante intervalos de direcciones IP autorizados. Para obtener información detallada e instrucciones sobre cómo implementar la infraestructura en Azure mediante plantillas de Bicep, consulte la muestra de código complementaria de Azure.

En un entorno de producción, se recomienda encarecidamente implementar un clúster de AKS privado con el Acuerdo de Nivel de Servicio de tiempo de actividad. Para más información, consulte clúster de AKS privado con una dirección DNS pública. Como alternativa, puede implementar un clúster de AKS público y proteger el acceso al servidor de API mediante intervalos de direcciones IP autorizados. Para obtener información detallada e instrucciones sobre cómo implementar la infraestructura en Azure mediante plantillas de Bicep, consulte la muestra de código complementaria de Azure.

Paso siguiente

Implementación de una carga de trabajo de aplicación web de AWS en Azure

Colaboradores

Microsoft mantiene este artículo. Los siguientes colaboradores lo escribieron originalmente:

Autor principal:

Otros colaboradores:

  • Last updated on