Exposición de Azure Spring Apps mediante un proxy inverso

Cuando hospeda sus aplicaciones o microservicios en Azure Spring Apps, no siempre quiere publicarlas directamente en Internet. En su lugar, puede exponerlos mediante un proxy inverso. Este enfoque le permite colocar un servicio delante de las aplicaciones. El servicio puede definir funcionalidades transversales, como las funcionalidades de firewall de aplicaciones web (WAF) para ayudar a proteger las aplicaciones, el equilibrio de carga, el enrutamiento, el filtrado de solicitudes y la limitación de velocidad.

Al implementar un servicio de proxy inverso común como Azure Application Gateway o Azure Front Door delante de Azure Spring Apps, debe asegurarse de que solo se pueda acceder a las aplicaciones mediante el proxy inverso. Esta medida de seguridad ayuda a evitar que usuarios malintencionados intenten omitir el WAF o sortear los límites.

Azure DDoS Protection, combinado con los procedimientos recomendados de diseño de aplicaciones, proporciona características mejoradas de mitigación de DDoS para ofrecer una mejor defensa frente a los ataques DDoS. Debe habilitar Azure DDOS Protection en cualquier red virtual perimetral.

Este artículo describe cómo aplicar restricciones de acceso para que las aplicaciones hospedadas en Azure Spring Apps solo sean accesibles mediante el servicio de proxy inverso. La manera recomendada de aplicar estas restricciones depende de cómo implemente la instancia de Azure Spring Apps y de qué proxy inverso use. Hay diferentes puntos que se deben tener en cuenta según si se implementa dentro o fuera de una red virtual. En este artículo se proporciona información sobre cuatro escenarios.

• Implementación de Azure Spring Apps en una red virtual y Acceso a una aplicación en una red privada.

  • Tiene control sobre la red virtual en la que se ejecutan las aplicaciones. Use características de redes nativas de Azure como los grupos de seguridad de red (NSG) para bloquear el acceso y permitir solo el proxy inverso.

  • Puede exponer las aplicaciones públicamente a Internet mediante Azure Application Gateway y, después, aplicar las restricciones de acceso adecuadas para bloquearlas. Este enfoque se describe en el Escenario 1 más adelante en este artículo.

  • No puede usar Azure Front Door directamente, ya que no puede acceder a la instancia de Azure Spring Apps en la red virtual privada. Azure Front Door puede conectarse a los back-end solo mediante una dirección IP pública o mediante servicios que usan un punto de conexión privado. Cuando tiene una implementación de varias regiones de Azure Spring Apps y requiere equilibrio de carga global, todavía puede exponer las instancias de Azure Spring Apps mediante Application Gateway. Para lograr este escenario, colocará Azure Front Door delante de Application Gateway. Este enfoque se describe en el Escenario 2 más adelante en este artículo.

• Implementación de Azure Spring Apps fuera de una red virtual y publicación de aplicaciones directamente en Internet, si se les asigna un punto de conexión.

  • No controla la red y no puede usar los NSG para restringir el acceso. Permitir que solo el proxy inverso acceda a las aplicaciones requiere un enfoque dentro del propio Azure Spring Apps.

  • Como las aplicaciones se pueden acceder de forma pública, puede usar Application Gateway o Azure Front Door como proxy inverso. El enfoque de Application Gateway se describe en el Escenario 3 más adelante en este artículo. El enfoque de Azure Front Door se describe en el Escenario 4 más adelante en este artículo.

  • Puede usar una combinación de ambos enfoques, según sea necesario. Si usa tanto Application Gateway como Azure Front Door, use las mismas restricciones de acceso que se usan en el Escenario 2 entre los dos servidores proxy inversos.

Comparación de escenarios

En esta tabla se proporciona una breve comparación de los cuatro escenarios de configuración de proxy inverso para Azure Spring Apps. Para obtener los detalles completos sobre cada escenario, consulte la sección adecuada de este artículo.

Implementación dentro de la red virtual

Cuando Azure Spring Apps se implementa en una red virtual, usa dos subredes:

• Una subred runtime de servicio que contiene los recursos de red pertinentes
• Una subred de aplicaciones que hospeda el código

Como la subred del entorno de ejecución del servicio contiene el equilibrador de carga para conectarse a las aplicaciones, puede definir un grupo de seguridad de red en esta subred del entorno de ejecución del servicio para permitir solo el tráfico desde el proxy inverso. Cuando se bloquea el resto del tráfico, nadie de la red virtual puede acceder a las aplicaciones sin pasar por el proxy inverso.

Cada aplicación que quiera exponer mediante el proxy inverso debe tener un punto de conexión asignado para que el proxy inverso pueda acceder a la aplicación en la red virtual. Para cada aplicación, también debe asignar los dominios personalizados que usa para evitar reemplazar el encabezado HTTP Host en el proxy inverso y mantener intacto el nombre de host original. Este método evita problemas como cookies rotas o direcciones URL de redireccionamiento que no funcionan correctamente. Para más información, consulte Conservación del nombre de host HTTP original entre un proxy inverso y su aplicación web de back-end.

Escenario 1: Uso de Application Gateway como proxy inverso

El Escenario 1 describe cómo exponer las aplicaciones públicamente a Internet mediante Application Gateway y, después, aplicar las restricciones de acceso adecuadas para bloquearlas.

En este diagrama se muestra la arquitectura del Escenario 1:

Descargue un archivo Visio de esta arquitectura.

Cuando Application Gateway se encuentra delante de la instancia de Azure Spring Apps, se usa el punto de conexión asignado de la aplicación de Spring Cloud Gateway como grupo de back-end. Punto de conexión de ejemplo myspringcloudservice-myapp.private.azuremicroservices.io. Este punto de conexión se resuelve como una dirección IP privada en la subred del runtime del servicio. Por lo tanto, para restringir el acceso, puede colocar un grupo de seguridad de red en la subred del entorno de ejecución del servicio con las siguientes reglas de seguridad de entrada (lo que da a la regla de denegación la prioridad más baja):

La configuración del Escenario 1 garantiza que la subred del runtime del servicio solo permite el tráfico desde estos orígenes:

• La subred dedicada de Application Gateway
• La subred de las aplicaciones (se requiere comunicación bidireccional entre las dos subredes de Azure Spring Apps).
• El equilibrador de carga de Azure (que es un requisito general de la plataforma Azure)

El resto del tráfico está bloqueado.

Escenario 2: Uso de Azure Front Door y Application Gateway como proxy inverso

Como se indicó anteriormente, no puede colocar Azure Front Door directamente delante de Azure Spring Apps porque no puede acceder a la red virtual privada. (Azure Front Door Estándar o Premium pueden conectarse a puntos de conexión privados de una red virtual, pero Azure Spring Apps no ofrece actualmente compatibilidad con puntos de conexión privados). Si todavía quiere usar Azure Front Door, por ejemplo, cuando se necesita equilibrio de carga global entre varias instancias de Azure Spring Apps en diferentes regiones de Azure, todavía puede exponer las aplicaciones mediante Application Gateway. Para lograr este escenario, colocará Azure Front Door delante de Application Gateway.

En este diagrama se muestra la arquitectura del Escenario 2:

Descargue un archivo Visio de esta arquitectura.

La configuración del Escenario 2 implementa restricciones de acceso entre Application Gateway y Azure Spring Apps de la misma manera que el Escenario 1. Coloque un NSG en la subred del runtime del servicio con las reglas adecuadas.

En el Escenario 2, también tiene que asegurarse de que Application Gateway acepte solo el tráfico procedente de la instancia de Azure Front Door. En la documentación de Azure Front Door, se explica cómo bloquear el acceso a un back-end para permitir solo el tráfico de Azure Front Door. Cuando el back-end es Application Gateway, puede implementar esta restricción de la siguiente manera:

• En la subred de Application Gateway, cree un grupo de seguridad de red que permita solo el tráfico que tenga la etiqueta de servicio AzureFrontDoor.Backend (nada excepto Azure Front Door puede acceder a Application Gateway). Asegúrese de incluir también otras etiquetas de servicio necesarias, como se describe en Restricciones de NSG para Application Gateway.
• Cree una regla de WAF personalizada en Application Gateway que compruebe que el encabezado HTTP X-Azure-FDID esté establecido en el id. de la instancia específica de Azure Front Door. Este método garantiza que ninguna instancia de Azure Front Door de otra organización que use los mismos intervalos IP pueda acceder a su instancia de Application Gateway.

Implementación fuera de la red virtual

Cuando se implementa Azure Spring Apps fuera de una red virtual, no se pueden usar las características de red nativas de Azure porque no tiene control sobre la red. En su lugar, tiene que aplicar las restricciones de acceso necesarias en las propias aplicaciones para permitir solo el tráfico desde el proxy inverso. Si tiene muchas aplicaciones, este enfoque puede agregar complejidad y existe el riesgo de que no todas las aplicaciones se puedan configurar correctamente.

Uso de Spring Cloud Gateway para exponer y ayudar a proteger las aplicaciones

Para quitar la responsabilidad del control de acceso a los desarrolladores de las aplicaciones individuales, puede aplicar restricciones transversales mediante Spring Cloud Gateway. Spring Cloud Gateway es un proyecto de Spring que se usa habitualmente y que se puede implementar en Azure Spring Apps como cualquier otra aplicación. Al usar Spring Cloud Gateway, puede mantener sus propias aplicaciones privadas dentro de la instancia de Azure Spring Apps y asegurarse de que solo se pueda acceder mediante la aplicación compartida de Spring Cloud Gateway. Después, configure esta aplicación con las restricciones de acceso necesarias mediante predicados de ruta, que son una característica integrada de Spring Cloud Gateway. Los predicados de ruta pueden usar atributos diferentes de la solicitud HTTP entrante para determinar si se debe enrutar la solicitud a la aplicación de back-end o rechazarla. El predicado puede usar atributos como la dirección IP del cliente, el método de solicitud o la ruta de acceso, los encabezados HTTP, etc.

Este patrón se usa normalmente. Para los fines de este artículo, se asume que expone las aplicaciones mediante Spring Cloud Gateway. Esperamos que use sus predicados de ruta para configurar las restricciones de acceso necesarias con el fin de asegurar que solo se admitan las solicitudes desde proxy inverso. Aunque no use Spring Cloud Gateway, se aplican los mismos principios generales. Pero tendrá que crear sus propias funcionalidades de filtrado de solicitudes en las aplicaciones en función del mismo encabezado HTTP X-Forwarded-For que se describe más adelante en este artículo.

La descripción del funcionamiento de Spring Cloud Gateway está fuera del ámbito de este artículo. Se trata de un servicio muy flexible que se puede personalizar mediante código o configuración. Para que todo sea sencillo, este artículo describe un enfoque basado en la configuración que no requiere cambios en el código. Puede implementar este enfoque incluyendo el archivo application.properties o application.yml tradicional en la aplicación de Spring Cloud Gateway implementada. También puede implementar el enfoque mediante una instancia de Config Server en Azure Spring Apps que externaliza el archivo de configuración en un repositorio de Git. En estos ejemplos, se implementa el enfoque con la sintaxis YAML application.yml, pero la sintaxis equivalente application.properties también funciona.

Enrutamiento de solicitudes a las aplicaciones

De manera predeterminada, cuando la aplicación de Azure Spring Apps no tiene un punto de conexión asignado o un dominio personalizado configurado para ella, no es accesible desde el exterior. Cuando una aplicación se registra con Spring Cloud Service Registry, Spring Cloud Gateway puede detectar la aplicación para que pueda usar reglas de enrutamiento para reenviar el tráfico a la aplicación de destino correcta.

Por lo tanto, la única aplicación que necesita tener un punto de conexión asignado en Azure Spring Apps es la aplicación de Spring Cloud Gateway. Este punto de conexión hace que sea accesible desde el exterior. No debe asignar un punto de conexión a ninguna otra aplicación. De lo contrario, se puede acceder a las aplicaciones directamente en lugar de mediante Spring Cloud Gateway, lo que a su vez permite omitir el proxy inverso.

Una manera fácil de exponer todas las aplicaciones registradas mediante Spring Cloud Gateway es con el localizador de definición de ruta DiscoveryClient, tal como se muestra aquí:

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true
          predicates:
          - Path="/"+serviceId+"/**" # Include the Path predicate to retain default behavior
          - (...)

Como alternativa, puede exponer de forma selectiva determinadas aplicaciones con Spring Cloud Gateway mediante la definición de rutas específicas de la aplicación:

spring:
  cloud:
    gateway:
      routes:
      - id: my_app1_route
        uri: lb://MY-APP1
        filters:
        - RewritePath=/myapp1(?<segment>/?.*), $\{segment}
        predicates:
        - (...)

Con el enfoque del localizador de detección y las definiciones de ruta explícitas, puede usar predicados de ruta para rechazar las solicitudes no válidas. En este caso, usaremos esa funcionalidad para bloquear las solicitudes que no proceden del proxy inverso esperado que se encuentra delante de Azure Spring Apps.

Restricción del acceso con el encabezado HTTP X-Forwarded-For

Al implementar una aplicación en Azure Spring Apps, el cliente HTTP o el proxy inverso no se conectan directamente a la aplicación. El tráfico de red pasa primero a través de un controlador de entrada interno.

Debido al servicio adicional, la dirección IP del cliente de red directa siempre es un componente interno de Azure Spring Apps. La dirección IP nunca es el cliente lógico, como el proxy inverso que espera que llame a su aplicación. No puede usar la dirección IP del cliente para las restricciones de acceso. Tampoco puede usar el predicado de ruta RemoteAddr integrado de Spring Cloud Gateway para el filtrado de solicitudes porque usa la dirección IP del cliente de manera predeterminada.

Afortunadamente, Azure Spring Apps agrega siempre la dirección IP del cliente lógico al encabezado HTTP X-Forwarded-For de la solicitud en la aplicación. El último valor (más a la derecha) del encabezado X-Forwarded-For siempre contiene la dirección IP del cliente lógico.

Para filtrar las solicitudes en función del encabezado X-Forwarded-For, puede usar el predicado de ruta XForwarded Remote Addr integrado. Este predicado le permite configurar una lista de las direcciones IP o los intervalos IP del proxy inverso que se permiten como el valor más a la derecha.

Configuración de la aplicación para ver el nombre de host y la dirección URL de solicitud correctos

Cuando se usa Spring Cloud Gateway, hay un factor importante que se debe tener en cuenta. Spring Cloud Gateway establece el encabezado HTTP Host en la solicitud saliente en la dirección IP interna de la instancia de la aplicación, como Host: 10.2.1.15:1025. El nombre de host de la solicitud que ve el código de la aplicación ya no es el nombre de host original de la solicitud que envió el explorador, como contoso.com. En algunos casos, este resultado puede provocar problemas como cookies rotas o direcciones URL de redireccionamiento que no funcionan correctamente. Para más información sobre estos tipos de problemas y cómo configurar un servicio de proxy inverso como Application Gateway o Azure Front Door para evitarlos, consulte Conservación del nombre de host HTTP original entre un proxy inverso y su aplicación web de back-end.

Spring Cloud Gateway proporciona el nombre de host original en el encabezado Forwarded. También establece otros encabezados como X-Forwarded-Port, X-Forwarded-Proto y X-Forwarded-Prefix para que la aplicación pueda usarlos para reconstruir la dirección URL de la solicitud original. En las aplicaciones de Spring Framework, puede conseguir esta configuración automáticamente al establecer la configuración server.forward-headers-strategy en FRAMEWORK en las propiedades de la aplicación. (No establezca este valor en NATIVE. Si lo hace, se usan otros encabezados que no tienen en cuenta el encabezado X-Forwarded-Prefix necesario). Para más información, consulte Ejecución detrás de un servidor proxy de front-end. Con esta configuración, el método HttpServletRequest.getRequestURL tiene en cuenta todos estos encabezados y devuelve la dirección URL exacta de la solicitud enviada por el explorador.

Escenario 3: Uso de Application Gateway con Spring Cloud Gateway

En el Escenario 3 se describe cómo usar Application Gateway como proxy inverso para aplicaciones accesibles públicamente mediante un punto de conexión de Spring Cloud Gateway.

En este diagrama se muestra la arquitectura del Escenario 3:

Descargue un archivo Visio de esta arquitectura.

Cuando Application Gateway se encuentra delante de la instancia de Azure Spring Apps, se usa el punto de conexión asignado de la aplicación de Spring Cloud Gateway como grupo de back-end. Punto de conexión de ejemplo myspringcloudservice-mygateway.azuremicroservices.io. Dado que Azure Spring Apps se ha implementado fuera de una red virtual, esta dirección URL se resuelve como una dirección IP pública. Cuando el grupo de back-end es un punto de conexión público, Application Gateway usa su dirección IP pública de front-end para llegar al servicio de back-end.

Para permitir que solo las solicitudes de la instancia de Application Gateway lleguen a Spring Cloud Gateway, puede configurar el predicado de ruta XForwarded Remote Addr. Configure el predicado para permitir solo las solicitudes de la dirección IP pública dedicada de Application Gateway como se muestra en este ejemplo:

(...)
predicates:
- XForwardedRemoteAddr="20.103.252.85"

Escenario 4: Uso de Azure Front Door con Spring Cloud Gateway

En el Escenario 4 se describe cómo usar Azure Front Door como proxy inverso para aplicaciones accesibles públicamente mediante un punto de conexión de Spring Cloud Gateway.

En este diagrama se muestra la arquitectura del Escenario 4:

Descargue un archivo Visio de esta arquitectura.

Parecido al Escenario 3, esta configuración usa la dirección URL pública de la aplicación de Spring Cloud Gateway como grupo de back-end u origen en Azure Front Door. Punto de conexión de ejemplo https://myspringcloudservice-mygateway.azuremicroservices.io.

Como Azure Front Door es un servicio global con muchas ubicaciones perimetrales, usa muchas direcciones IP para comunicarse con su grupo de back-end. En la documentación de Azure Front Door, se describe cómo bloquear el acceso a un back-end para permitir solo el tráfico de Azure Front Door. Pero en este escenario no se controla la red de Azure en la que se implementan las aplicaciones. Desafortunadamente, no puede usar la etiqueta de servicio AzureFrontDoor.Backend para obtener una lista completa de direcciones IP de Azure Front Door de salida que se garantice que estén actualizadas. En su lugar, tiene que descargar los intervalos IP y las etiquetas de servicio de Azure, buscar la sección AzureFrontDoor.Backend y copiar todos los intervalos IP de la matriz addressPrefixes en la configuración del predicado de ruta XForwarded Remote Addr.

Como los intervalos IP de Azure Front Door se comparten con otras organizaciones, también tiene que asegurarse de bloquear el acceso solo a la instancia específica de Azure Front Door, según el encabezado HTTP X-Azure-FDID que contiene el valor único de Front Door ID. Puede restringir el acceso mediante el predicado de ruta Header, que rechaza una solicitud a menos que el encabezado HTTP especificado tenga un valor determinado.

En este escenario, la configuración del predicado de ruta de Spring Cloud Gateway podría ser similar a la de este ejemplo:

(...)
predicates:
- XForwardedRemoteAddr="13.73.248.16/29","20.21.37.40/29","20.36.120.104/29","20.37.64.104/29", ...(and many more)...
- Header="X-Azure-FDID", "e483e3cc-e7f3-4e0a-9eca-5f2a62bde229"

Colaboradores

Microsoft se encarga del mantenimiento de este contenido. El colaborador siguiente desarrolló el contenido original.

Autor principal:

• Jelle Druyts | Ingeniero principal de clientes

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

Pasos siguientes

• Arquitectura de referencia de Azure Spring Apps
• Responsabilidades del cliente al ejecutar Azure Spring Apps en una red virtual

Recursos relacionados

• Conservación del nombre de host
• Opciones de equilibrio de carga
• Estilo de arquitectura de microservicios