Redes en el entorno de Azure Container Apps

  • Artículo

Azure Container Apps se ejecuta en el contexto de un entorno, con su propia red virtual (VNet).

De forma predeterminada, el entorno de Container Apps se crea con una red virtual que se genera automáticamente. Para que haya un control más exhaustivo de la red, puede usar una red virtual existente al crear un entorno. Una vez creado el entorno con una red virtual generada o existente, no es posible cambiar el tipo de red.

Las redes virtuales generadas adoptan las siguientes características.

Son las siguientes:

  • inaccesible para usted a medida que se crean en el inquilino de Microsoft
  • accesible públicamente a través de Internet
  • solo se puede acceder a los puntos de conexión accesibles a Internet

Además, solo admiten un subconjunto limitado de funcionalidades de red, como restricciones de IP de entrada y controles de entrada de nivel de aplicación de contenedor.

Use una red virtual existente si necesita más características de red de Azure, como:

  • Integración con Application Gateway
  • Grupos de seguridad de red
  • Comunicación con recursos detrás de puntos de conexión privados en la red virtual

Las características de red virtual disponibles dependen de la selección del entorno.

Selección de entorno

Container Apps tiene dos tipos de entorno de diferentes, que comparten muchas de las mismas características de red con algunas diferencias clave.

Tipo de entorno Descripción Tipos de plan admitidos
Perfiles de carga de trabajo Admite rutas definidas por el usuario (UDR) y salida a través de NAT Gateway. El tamaño mínimo necesario de subred es /27. Consumo, dedicado
Solo consumo No admite rutas definidas por el usuario (UDR), salida a través de NAT Gateway, emparejamiento a través de una puerta de enlace remota u otra salida personalizada. El tamaño mínimo necesario de subred es /23. Consumo

Niveles de accesibilidad

Puede configurar si la aplicación de contenedor permite la entrada pública o la entrada solo desde dentro de su red virtual a nivel de entorno.

Nivel de accesibilidad Descripción
Externo Permite que la aplicación de contenedor acepte solicitudes públicas. Los entornos externos se implementan con una dirección IP virtual en una dirección IP externa y pública.
Interno Los entornos internos no tienen puntos de conexión públicos y se implementan con una dirección IP virtual (VIP) asignada a una dirección IP interna. El punto de conexión interno es un equilibrador de carga interno (ILB) de Azure y las direcciones IP se emiten desde la lista de direcciones IP privadas de la red virtual personalizada.

Configuración de red virtual personalizada

A medida que cree una red virtual personalizada, tenga en cuenta las siguientes situaciones:

  • Si quiere que la aplicación de contenedor restrinja todo el acceso externo, cree un entorno interno de Container Apps.

  • Si usa su propia red virtual, debe proporcionar una subred dedicada exclusivamente al entorno de aplicación de contenedor que implemente. Esta subred no está disponible para otros servicios.

  • Las direcciones de red se asignan desde un intervalo de subred que se define a medida que se crea el entorno.

    • Puede definir el intervalo de subred que usa el entorno de Container Apps.

    • Puede restringir las solicitudes entrantes al entorno exclusivamente a la red virtual implementando el entorno como interno.

Nota:

Al proporcionar su propia red virtual, se crean recursos administrados adicionales. Estos recursos incurren en costos a sus tarifas asociadas.

A medida que empiece a diseñar la red en torno a la aplicación de contenedor, consulte Planear redes virtuales.

Diagram of how Azure Container Apps environments use an existing V NET, or you can provide your own.

Nota:

No se permite mover redes virtuales entre diferentes grupos de recursos o suscripciones si la red virtual está en uso por un entorno de Container Apps.

Comportamiento del proxy perimetral HTTP

Azure Container Apps usa el Envoy proxy como proxy HTTP perimetral. La seguridad de la capa de transporte (TLS) se finaliza en el perímetro y las solicitudes se enrutan en función de sus reglas de división de tráfico y enrutan el tráfico a la aplicación correcta.

Las aplicaciones HTTP se escalan en función del número de solicitudes y conexiones HTTP. Envoy enruta el tráfico interno dentro de clústeres.

Las conexiones descendentes admiten HTTP1.1 y HTTP2 y Envoy detecta y actualiza automáticamente las conexiones si la conexión de cliente requiere una actualización.

Las conexiones ascendentes se definen al establecer la propiedad transport en el objeto de entrada.

Configuración de entrada

En la sección entrada, puede configurar las siguientes opciones:

  • Nivel de accesibilidad: puede establecer la aplicación de contenedor como accesible externa o internamente en el entorno. Se usa una variable de entorno CONTAINER_APP_ENV_DNS_SUFFIX para resolver automáticamente el sufijo de nombre de dominio completo (FQDN) de su entorno. Al comunicarse entre aplicaciones de contenedor dentro del mismo entorno, también puede usar el nombre de la aplicación. Para más información sobre cómo acceder a las aplicaciones, consulte Entrada en Azure Container Apps.

  • Reglas de división de tráfico: puede definir reglas de división de tráfico entre diferentes revisiones de la aplicación. Para más información, consulte División del tráfico.

Para más información sobre los distintos escenarios de red, consulte Entrada en Azure Container Apps.

Dependencias del portal

Por cada aplicación en Azure Container Apps, hay dos direcciones URL.

El entorno de ejecución de Container Apps genera inicialmente un nombre de dominio completo (FQDN) que se usa para acceder a la aplicación. Consulte la dirección URL de la aplicación en la ventana Información general de la aplicación de contenedor en Azure Portal del FQDN de la aplicación de contenedor.

También se genera una segunda dirección URL automáticamente. Esta ubicación concede acceso al servicio de streaming de registros y a la consola. Si es necesario, es posible que tenga que agregar https://azurecontainerapps.dev/ a la lista de permitidos del firewall o proxy.

Direcciones IP y puertos

Los puertos siguientes se exponen para las conexiones entrantes.

Protocolo Puertos
HTTP/HTTPS 80, 443

Las direcciones IP se dividen en los siguientes tipos:

Tipo Descripción
Dirección IP pública de entrada Se usa para el tráfico de la aplicación en una implementación externa y para el tráfico de administración tanto en implementaciones externas como internas.
Dirección IP pública de salida Se usa como dirección IP de procedencia para las conexiones de salida que salen de la red virtual. Estas conexiones no se enrutan a una VPN. Las direcciones IP salientes pueden cambiar con el tiempo. El uso de una puerta de enlace NAT u otro proxy para el tráfico saliente desde un entorno de Container Apps solo se admite en un entorno de perfiles de carga de trabajo.
Dirección IP del equilibrador de carga interno Esta dirección solo existe en un entorno interno.

Subnet

La integración de red virtual depende de una subred dedicada. La forma en que se asignan las direcciones IP en una subred y qué tamaños de subred se admiten depende del plan que esté usando en Azure Container Apps.

Seleccione cuidadosamente el tamaño de la subred. Los tamaños de subred no se pueden modificar después de crear un entorno de Container Apps.

Los distintos tipos de entorno tienen requisitos de subred diferentes:

  • /27 es el tamaño mínimo de subred necesario para la integración de red virtual.

  • La subred deberá estar delegada a Microsoft.App/environments.

  • Cuando se usa un entorno externo con entrada externa, el tráfico entrante se enruta a través de la dirección IP pública de la infraestructura en lugar de a través de la subred.

  • Container Apps reserva automáticamente 12 direcciones IP para la integración con la subred. El número de direcciones IP necesarias para la integración de la infraestructura no varía en función de las demandas de escala del entorno. Las direcciones IP adicionales se asignan según las siguientes reglas dependiendo del tipo de perfil de carga de trabajo que esté utilizando se asignan más direcciones IP dependiendo del perfil de carga de trabajo de su entorno:

    • Perfil de carga de trabajo dedicado: a medida que la aplicación de contenedor se escala horizontalmente, cada nodo tiene asignada una dirección IP.

    • Perfil de carga de trabajo de consumo: cada dirección IP puede compartirse entre varias réplicas. Al planear el número de direcciones IP necesarias para la aplicación, planee 1 dirección IP por cada 10 réplicas.

  • Cuando se realiza un cambio a una revisión en modo de revisión única, el espacio de direcciones necesario se duplica durante un breve período de tiempo para admitir implementaciones de tiempo de inactividad cero. Esto afecta a las réplicas o nodos admitidos reales y disponibles para un tamaño de subred determinado. En la tabla siguiente se muestran las direcciones máximas disponibles por bloque CIDR y el impacto en la escala horizontal.

    Tamaño de la subred Direcciones IP disponibles1 Número máximo de nodos (perfil de carga de trabajo dedicado)2 Número máximo de réplicas (perfil de carga de trabajo de consumo)2
    /23 500 250 2,500
    /24 244 122 1220
    /25 116 58 580
    /26 52 26 260
    /27 20 10 100

    1 Las direcciones IP disponibles son el tamaño de la subred menos las 12 direcciones IP necesarias para la infraestructura de Azure Container Apps.
    2 Esto tiene en cuenta las aplicaciones en modo de revisión única.

Restricciones del intervalo de direcciones de subred

Los intervalos de direcciones de subred no se pueden superponer con los siguientes intervalos reservados por Azure Kubernetes Services:

  • 169.254.0.0/16
  • 172.30.0.0/16
  • 172.31.0.0/16
  • 192.0.2.0/24

Además, un entorno de perfiles de carga de trabajo reserva las siguientes direcciones:

  • 100.100.0.0/17
  • 100.100.128.0/19
  • 100.100.160.0/19
  • 100.100.192.0/19

Configuración de subred con la CLI

A medida que se crea un entorno de Container Apps, se proporcionan id. de recursos para una única subred.

Si usa la CLI, el parámetro para definir el identificador de recurso de subred es infrastructure-subnet-resource-id. La subred hospeda componentes de infraestructura y contenedores de aplicaciones de usuario.

Si usa la CLI de Azure con un entorno de solo consumo y se define el intervalo platformReservedCidr, ambas subredes no deben superponerse con el intervalo IP definido en platformReservedCidr.

Rutas

Rutas definidas por el usuario (UDR)

Las rutas definidas por el usuario (UDR) y la salida controlada a través de NAT Gateway se admiten en el entorno de perfiles de carga de trabajo. En el entorno de solo consumo, estas características no se admiten.

Nota:

Al usar UDR con Azure Firewall en Azure Container Apps, debe agregar determinadas etiquetas de servicio y FQDN a la lista de permitidos para el firewall. Para más información, consulte Configuración de UDR con Azure Firewall.

  • Puede utilizar una UDR con entornos de perfiles de carga de trabajo para restringir el tráfico saliente de la aplicación de contenedor a través de Azure Firewall o de otros dispositivos de red.

  • La configuración de UDR se realiza fuera del ámbito del entorno de Container Apps.

Diagram of how UDR is implemented for Container Apps.

Azure crea una tabla de rutas predeterminada para las redes virtuales al crearla. Al implementar una tabla de rutas definida por el usuario, puede controlar cómo se enruta el tráfico dentro de la red virtual. Por ejemplo, puede crear una UDR que enrute todo el tráfico al firewall.

Configuración de UDR con Azure Firewall

Las rutas definidas por el usuario solo se admiten en un entorno de perfiles de carga de trabajo. Las siguientes reglas de red y aplicación deben agregarse a la lista de permitidos del firewall en función de los recursos que use.

Nota:

Para obtener una guía sobre cómo configurar UDR con Container Apps para restringir el tráfico saliente con Azure Firewall, visite la Guía de instrucciones para Container Apps y Azure Firewall.

Reglas de aplicación

Las reglas de aplicación permiten o deniegan el tráfico en función del nivel de aplicación. Las siguientes reglas de aplicación de firewall de salida son necesarias en función del escenario.

Escenarios FQDNs Descripción
Todas las situaciones mcr.microsoft.com, *.data.mcr.microsoft.com Azure Container Apps usa estos FQDN para Microsoft Container Registry (MCR) y estas reglas de aplicación o las reglas de red para MCR deben agregarse a la lista de permitidos al usar Azure Container Apps con Azure Firewall.
Azure Container Registry (ACR) Your-ACR-address, *.blob.core.windows.net, login.microsoft.com Estos FQDN son necesarios al usar Azure Container Apps con ACR y Azure Firewall.
Azure Key Vault Your-Azure-Key-Vault-address, login.microsoft.com Estos FQDN son necesarios además de la etiqueta de servicio necesaria para la regla de red para Azure Key Vault.
Identidad administrada *.identity.azure.net, login.microsoftonline.com, , *.login.microsoftonline.com, *.login.microsoft.com Estos FQDN son necesarios cuando se usa la identidad administrada con Azure Firewall en Azure Container Apps.
Registro de Docker Hub hub.docker.com, , registry-1.docker.io, production.cloudflare.docker.com Si usa el registro de Docker Hub y quiere acceder a él a través del firewall, debe agregar estos FQDN al firewall.
Reglas de red

Las reglas de red permiten o deniegan el tráfico en función de la capa de red y transporte. Las siguientes reglas de red de firewall de salida son necesarias en función del escenario.

Escenarios Etiqueta de servicio Descripción
Todas las situaciones MicrosoftContainerRegistry, AzureFrontDoorFirstParty Azure Container Apps usa estas etiquetas de servicio para Microsoft Container Registry (MCR) y estas reglas de red o las reglas de aplicación para MCR deben agregarse a la lista de permitidos al usar Azure Container Apps con Azure Firewall.
Azure Container Registry (ACR) AzureContainerRegistry, AzureActiveDirectory Al usar ACR con Azure Container Apps, debe configurar estas reglas de aplicación usadas por Azure Container Registry.
Azure Key Vault AzureKeyVault, AzureActiveDirectory Estas etiquetas de servicio son necesarias además del FQDN para la regla de aplicación para Azure Key Vault.
Identidad administrada AzureActiveDirectory Al usar la identidad administrada con Azure Container Apps, deberá configurar estas reglas de aplicación usadas por la identidad administrada.

Nota:

Para los recursos de Azure que usa con Azure Firewall no aparece en este artículo, consulte la documentación de etiquetas de servicio.

Integración de NAT Gateway

Puede usar NAT Gateway para simplificar la conectividad saliente para el tráfico saliente de Internet en la red virtual en un entorno de perfiles de carga de trabajo.

Al configurar una NAT Gateway en la subred, proporciona una dirección IP pública estática para su entorno. Todo el tráfico saliente de la aplicación de contenedor se enruta a través de la dirección IP pública estática de la NAT Gateway.

Seguridad del entorno

Diagram of how to fully lock down your network for Container Apps.

Puede proteger completamente el entorno de perfiles de carga de trabajo de tráfico de red de entrada y salida mediante las siguientes acciones:

Cifrado de red de nivel de entorno (versión preliminar)

Azure Container Apps admite el cifrado de red de nivel de entorno mediante la seguridad de la capa de transporte mutua (mTLS). Cuando se requiere el cifrado de un extremo a otro, mTLS cifra los datos transmitidos entre aplicaciones dentro de un entorno.

Las aplicaciones dentro de un entorno de Container Apps se autentican automáticamente. Sin embargo, el entorno de ejecución de Container Apps no admite la autorización para el control de acceso entre aplicaciones mediante mTLS integrado.

Cuando las aplicaciones se comunican con un cliente fuera del entorno, se admite la autenticación bidireccional con mTLS. Para más información, consulte Configurar certificados de cliente.

Nota:

La habilitación de mTLS para las aplicaciones puede aumentar la latencia de respuesta y reducir el rendimiento máximo en escenarios de alta carga.

Puede habilitar mTLS mediante los siguientes comandos.

Al crear:

az containerapp env create \
    --name <environment-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-mtls

Para una aplicación contenedora existente:

az containerapp env update \
    --name <environment-name> \
    --resource-group <resource-group> \
    --enable-mtls

DNS

  • DNS personalizado: si la red virtual usa un servidor DNS personalizado en lugar del servidor DNS predeterminado que proporciona Azure, configure el servidor DNS para reenviar consultas de DNS sin resolver a 168.63.129.16. Los solucionadores recursivos de Azure usan esta dirección IP para resolver solicitudes. Al configurar el grupo de seguridad de red o el firewall, no bloquee la dirección 168.63.129.16; de lo contrario, el entorno de Container Apps no funcionará correctamente.

  • Entrada de ámbito de red virtual: si tiene previsto usar la entrada de ámbito de red virtual en un entorno interno, configure los dominios de una de las siguientes maneras:

    1. Dominios no personalizados: si no tiene previsto usar un dominio personalizado, cree una zona DNS privada que resuelva el dominio predeterminado del entorno de Container Apps en la dirección IP estática del entorno de Container Apps. Puede usar DNS privado de Azure o su propio servidor DNS. Si usa DNS privado de Azure, cree una zona DNS privada denominada como dominio predeterminado del entorno de aplicación de contenedor (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io), con un registro A. El registro A contiene el nombre *<DNS Suffix> y la dirección IP estática del entorno de Container Apps.

    2. Dominios personalizados: si tiene previsto usar dominios personalizados y usa un entorno externo de Container Apps, use un dominio que se pueda resolver públicamente para agregar un dominio personalizado y un certificado a la aplicación contenedora. Si usa un entorno interno de Container Apps, no habrá ninguna validación para la vinculación del DNS, ya que solo se puede acceder al clúster desde dentro de la red virtual. Además, cree una zona de DNS privado que resuelva el dominio apex en la dirección IP estática del entorno de Container Apps. Puede usar DNS privado de Azure o su propio servidor DNS. Si usa DNS privado de Azure, cree una zona DNS privada con el nombre del dominio apex, con un registro A que apunte a la dirección IP estática del entorno de Container Apps.

La dirección IP estática del entorno de Container Apps está disponible en Azure Portal en sufijo DNS personalizado de la página de la aplicación de contenedor o mediante el comando az containerapp env list de la CLI de Azure.

Recursos administrados

Al implementar un entorno interno o externo en su propia red, se crea un grupo de recursos en la suscripción de Azure donde se hospeda el entorno. Este grupo de recursos contiene componentes de infraestructura administrados por la plataforma Azure Container Apps. No modifique los servicios de este grupo ni el propio grupo de recursos.

Entorno de perfiles de carga de trabajo

El nombre del grupo de recursos creado en la suscripción de Azure donde se hospeda el entorno tiene el prefijo ME_ de forma predeterminada y el nombre del grupo de recursos se puede personalizar a medida que crea el entorno de la aplicación de contenedor.

Para entornos externos, el grupo de recursos contiene una dirección IP pública que se usa específicamente para la conectividad entrante con el entorno externo y un equilibrador de carga. En el caso de los entornos internos, el grupo de recursos solo contiene un equilibrador de carga.

Además de la facturación de Azure Container Apps estándar, se le facturará por lo siguiente:

Entorno de solo consumo

El nombre del grupo de recursos creado en la suscripción de Azure donde se hospeda el entorno tiene el prefijo MC_ de forma predeterminada y el nombre del grupo de recursos no se puede personalizar al crear el entorno de una aplicación de contenedor. El grupo de recursos contiene direcciones IP públicas que se usan específicamente para la conectividad saliente desde el entorno, así como un equilibrador de carga.

Además de la facturación de Azure Container Apps estándar, se le facturará por lo siguiente:

Pasos siguientes