Compartilhar via

Rede no ambiente de Aplicativos de Contêiner do Azure

  • Artigo

Os Aplicativos de Contêiner do Azure são executados no contexto de um ambiente com sua própria VNet (rede virtual).

Por padrão, seu ambiente de Aplicativo de Contêiner é criado com uma Rede Virtual gerada automaticamente para você. Para um controle refinado sobre sua rede, você pode fornecer uma VNet existente ao criar um ambiente. Depois de criar um ambiente com uma VNet gerada ou existente, o tipo de rede não poderá ser alterado.

As VNets geradas assumem as seguintes características.

São elas:

  • inacessíveis para você, pois são criadas no locatário da Microsoft
  • publicamente acessíveis pela Internet
  • só é possível alcançar pontos de extremidade acessíveis pela Internet

Além disso, elas só dão suporte a um subconjunto limitado de recursos de rede, como restrições de IP de entrada e controles de entrada no nível do aplicativo de contêiner.

Use uma VNet existente se precisar de mais recursos de rede do Azure, como:

  • Integração com o Gateway de Aplicativo
  • Grupos de segurança de rede
  • Comunicação com recursos por trás de pontos de extremidade privados em sua rede virtual

Os recursos de VNet disponíveis dependem da seleção do ambiente.

Seleção de ambiente

Os Aplicativos de Contêiner têm dois tipos de ambiente diferentes, que compartilham muitas das mesmas características de rede com algumas diferenças importantes.

Tipo de ambiente Descrição Tipos de plano com suporte
Perfis de carga de trabalho Dá suporte a UDR (rotas definidas pelo usuário) e saída por meio do Gateway da NAT. O tamanho mínimo da sub-rede necessária é /27. Consumo, Dedicado
Apenas consumo Não dá suporte a UDC (rotas definidas pelo usuário), saída por meio de Gateway da NAT, emparelhamento por meio de um gateway remoto ou outra saída personalizada. O tamanho mínimo da sub-rede necessária é /23. Consumo

Níveis de acessibilidade

Você pode configurar se seu aplicativo de contêiner permite a entrada pública ou apenas a entrada de dentro da VNet no nível do ambiente.

Nível de acessibilidade Descrição
Externo Permite que seu aplicativo de contêiner aceite solicitações públicas. Ambientes externos são implantados com um IP virtual em um endereço IP externo voltado para o público.
Interna Os ambientes internos não têm pontos de extremidade públicos e são implantados com um VIP (IP virtual) mapeado para um endereço IP interno. O ponto de extremidade interno é um ILB (balanceador de carga interno) do Azure e os endereços IP são emitidos da lista personalizada de endereços IP privados da VNET.

Configuração de VNet personalizada

Ao criar uma VNet personalizada, considere as seguintes situações:

  • Se você quer que o aplicativo de contêiner restrinja todo o acesso externo, crie um ambiente interno dos Aplicativos de Contêiner.

  • Se você usar sua própria VNet, será necessário fornecer uma sub-rede dedicada exclusivamente ao ambiente do aplicativo de contêiner implantado. Essa sub-rede não está disponível para outros serviços.

  • Os endereços de rede são atribuídos de um intervalo de sub-rede que você define quando o ambiente é criado.

    • Você pode definir o intervalo de sub-rede usado pelo ambiente dos Aplicativos de Contêiner.

    • Você pode restringir as solicitações de entrada no ambiente exclusivamente à VNet implantando o ambiente como interno.

Observação

Ao fornecer sua própria rede virtual, serão criados recursos gerenciados adicionais. Esses recursos incorrem em custos a suas taxas associadas.

Ao começar a projetar a rede em torno do seu aplicativo de contêiner, veja Planejar redes virtuais.

Diagrama de como ambientes dos Aplicativos de Contêiner do Azure usam uma VNET existente ou você pode fornecer a sua própria.

Observação

Não é permitido mover VNets entre diferentes grupos de recursos ou assinaturas se a VNet estiver em uso por um ambiente de Aplicativos de Contêiner.

Comportamento de proxy de borda HTTP

Os Aplicativos de Contêiner do Azure usam o proxy Envoy como um proxy HTTP de borda. O protocolo TLS é encerrado na borda e as solicitações são encaminhadas com base em suas regras de divisão de tráfego e encaminha o tráfego para o aplicativo correto.

Os aplicativos HTTP são dimensionados com base no número de solicitações e conexões HTTP. O Envoy encaminha o tráfego interno dentro de clusters.

As conexões downstream dão suporte a HTTP1.1 e HTTP2, e o Envoy detecta e atualiza automaticamente as conexões se a conexão do cliente exigir uma atualização.

As conexões upstream são definidas pela configuração da propriedade transport no objeto de entrada.

Configuração de entrada

Na seção ingress, você pode definir as seguintes configurações:

  • Nível de acessibilidade: você pode definir o aplicativo de contêiner como acessível externamente ou internamente no ambiente. Uma variável de ambiente CONTAINER_APP_ENV_DNS_SUFFIX é usada para resolver automaticamente o sufixo FQDN (nome de domínio totalmente qualificado) para seu ambiente. Ao se comunicar entre aplicativos de contêiner no mesmo ambiente, você também pode usar o nome do aplicativo. Para obter mais informações sobre como acessar seus aplicativos, confira Entrada nos Aplicativos de Contêiner do Azure.

  • Regras de divisão de tráfego: você pode definir regras de divisão de tráfego entre diferentes revisões do aplicativo. Para obter mais informações, confira Divisão de tráfego.

Para obter mais informações sobre diferentes cenários de rede, confira Entrada nos Aplicativos de Contêiner do Azure.

Dependências do portal

Para cada aplicativo nos Aplicativos de Contêiner do Azure, há duas URLs.

O runtime dos Aplicativos de Contêiner gera inicialmente um FQDN (nome de domínio totalmente qualificado) usado para acessar seu aplicativo. Confira a URL do Aplicativo na janela Visão Geral do aplicativo de contêiner no portal do Azure para obter o FQDN do aplicativo de contêiner.

Uma segunda URL também é gerada para você. Esse local concede acesso ao serviço de streaming de log e ao console. Se necessário, você pode incluir https://azurecontainerapps.dev/ na lista de permitidos do firewall ou do proxy.

Portas e endereços IP

As portas a seguir são expostas para conexões de entrada.

Protocolo Porta(s)
HTTP/HTTPS 80, 443

Os endereços IP são divididos nos seguintes tipos:

Tipo Descrição
Endereço IP público de entrada Usado para o tráfego de aplicativos em uma implantação externa e para o tráfego de gerenciamento em implantações internas e externas.
IP público de saída Usado como o IP "de origem" das conexões de saída que saem da rede virtual. Essas conexões não são roteadas por uma VPN. Os IPs de saída podem ser alterados ao longo do tempo. O uso de um gateway da NAT ou outro proxy para tráfego de saída de um ambiente de Aplicativos de Contêiner só tem suporte em um ambiente de perfis de carga de trabalho.
Endereço IP do balanceador de carga interno Esse endereço só existe em um ambiente interno.

Sub-rede

A integração de rede virtual depende de uma sub-rede dedicada. A forma como os endereços IP são alocados em uma sub-rede e os tamanhos de sub-rede com suporte dependem do plano que você está usando nos Aplicativos de Contêiner do Azure.

Selecione o tamanho da sub-rede com cuidado. Os tamanhos de sub-rede não podem ser modificados depois que você cria um ambiente de Aplicativos de Contêiner.

Diferentes tipos de ambiente têm diferentes requisitos de sub-rede:

  • /27 é o tamanho mínimo de sub-rede necessário para a integração de rede virtual.

  • A sub-rede deve ser delegada a Microsoft.App/environments.

  • Ao usar um ambiente externo com entrada externa, o tráfego de entrada é roteado pelo IP público da infraestrutura, e não pela sub-rede.

  • Os Aplicativos de Contêiner reservam automaticamente 12 endereços IP para integração com a sub-rede. O número de endereços IP necessários para a integração da infraestrutura não varia de acordo com as demandas de escala do ambiente. Os endereços IP adicionais são alocados de acordo com as regras a seguir, dependendo do tipo de perfil de carga de trabalho que você está usando, mais endereços IP são alocados dependendo do perfil de carga de trabalho do ambiente:

  • Ao fazer uma alteração em uma revisão no modo de revisão única, o espaço de endereço necessário é duplicado por um curto período de tempo para dar suporte a implantações sem tempo de inatividade. Isso afeta as réplicas ou os nós reais com suporte disponíveis para um determinado tamanho de sub-rede. A tabela a seguir mostra os endereços máximos disponíveis por bloco CIDR e o efeito na escala horizontal.

    Tamanho da sub-rede Endereços IP disponíveis1 Nós máximos (perfil de carga de trabalho dedicado)2 Máximo de réplicas (perfil de carga de trabalho de consumo)2
    /23 500 250 2\.500
    /24 244 122 1.220
    / 25 116 58 580
    / 26 52 26 260
    / 27 20 10 100

    1 Os endereços IP disponíveis são do tamanho da sub-rede menos os 12 endereços IP necessários para a infraestrutura de Aplicativos de Contêiner do Azure.
    2 Isso é a contabilização de aplicativos no modo de revisão única.

Restrições de intervalo de endereços de sub-rede

Os intervalos de endereços de sub-rede não podem se sobrepor aos seguintes intervalos reservados pelos Serviços de Kubernetes do Azure:

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

Além disso, um ambiente de perfis de carga de trabalho reserva os seguintes endereços:

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

Configuração de sub-rede com a CLI

Quando um ambiente de Aplicativos de Contêiner é criado, você fornece IDs de recurso para duas sub-redes diferentes.

Se você estiver usando a CLI, o parâmetro para definir a ID do recurso de sub-rede será infrastructure-subnet-resource-id. A sub-rede hospeda componentes de infraestrutura e contêineres de aplicativo de usuário.

Se você estiver usando a CLI do Azure com um ambiente somente de Consumo e o intervalo platformReservedCidr estiver definido, a sub-rede não pode se sobrepor ao intervalo de IP definido em platformReservedCidr.

Rotas

UDR (rotas definidas pelo usuário)

As Rotas Definidas pelo Usuário (UDR) e a saída controlada por meio do Gateway da NAT têm suporte no ambiente de perfis de carga de trabalho. No ambiente de somente Consumo, esses recursos não têm suporte.

Observação

Ao usar a UDR com o Firewall do Azure nos Aplicativos de Contêiner do Azure, será necessário adicionar determinadas marcas de serviço e FQDN à lista de permissões do firewall. Para saber mais, confira Configurar a UDR com o Firewall do Azure.

  • Você pode usar a UDR com ambientes de perfis de carga de trabalho para restringir o tráfego de saída do seu aplicativo de contêiner por meio do Firewall do Azure ou de outros dispositivos de rede.

  • A configuração da UDR é feita fora do escopo do ambiente de Aplicativos de Contêiner.

Diagrama de como o UDR é implementado para Aplicativos de Contêiner do Azure.

O Azure cria uma tabela de rotas padrão para suas redes virtuais após a criação. Ao implementar uma tabela de rotas definida pelo usuário, você pode controlar como o tráfego é roteado em sua rede virtual. Por exemplo, você pode criar uma UDR que roteia todo o tráfego para o firewall.

Configurar a UDR com o Firewall do Azure

As rotas definidas pelo usuário só têm suporte em um ambiente de perfis de carga de trabalho. As seguintes regras de aplicativos e de rede devem ser adicionadas à lista de permissões do firewall, dependendo dos recursos que você estiver usando.

Observação

Para obter um guia sobre como configurar a UDR com os Aplicativos de Contêiner para restringir o tráfego de saída com o Firewall do Azure, acesse Instruções sobre os Aplicativos de Contêiner e o Firewall do Azure.

Regras de aplicativo

As regras de aplicativo permitem ou negam o tráfego com base na camada do aplicativo. As seguintes regras de aplicativo de firewall de saída são necessárias com base no cenário.

Cenários FQDNs Descrição
Todos os cenários mcr.microsoft.com, *.data.mcr.microsoft.com Esses FQDNs do MCR (Registro de Contêiner da Microsoft) são usados pelos Aplicativos de Contêiner do Azure e essas regras de aplicativo ou as regras de rede do MCR devem ser adicionadas à lista de permissões ao usar os Aplicativos de Contêiner do Azure com o Firewall do Azure.
Registro de Contêiner do Azure (ACR) Your-ACR-address, *.blob.core.windows.net, login.microsoft.com Esses FQDNs são necessários ao usar Aplicativos de Contêiner do Azure com o ACR e o Firewall do Azure.
Azure Key Vault Your-Azure-Key-Vault-address, login.microsoft.com Esses FQDNs são necessários além da marca de serviço necessária para a regra de rede do Azure Key Vault.
Identidade Gerenciada *.identity.azure.net, login.microsoftonline.com, *.login.microsoftonline.com, *.login.microsoft.com Esses FQDNs são necessários ao usar a identidade gerenciada com o Firewall do Azure nos Aplicativos de Contêiner do Azure.
Registro do Docker Hub hub.docker.com, registry-1.docker.io, production.cloudflare.docker.com Se você estiver usando o registro do Docker Hub e quiser acessá-lo por meio do firewall, precisará adicionar esses FQDNs ao firewall.
Regras de rede

As regras de rede permitem ou negam o tráfego com base na camada de rede e transporte. As seguintes regras de rede de firewall de saída são necessárias com base no cenário.

Cenários Marca de serviço Descrição
Todos os cenários MicrosoftContainerRegistry, AzureFrontDoorFirstParty Essas marcas de serviço para o MCR (Registro de Contêiner da Microsoft) são usadas pelos Aplicativos de Contêiner do Azure e essas regras de rede ou as regras de aplicativo para MCR devem ser adicionadas à lista de permissões ao usar Aplicativos de Contêiner do Azure com o Firewall do Azure.
Registro de Contêiner do Azure (ACR) AzureContainerRegistry, AzureActiveDirectory Ao usar o ACR com os Aplicativos de Contêiner do Azure, será necessário configurar essas regras de aplicativo usadas pelo Registro de Contêiner do Azure.
Azure Key Vault AzureKeyVault, AzureActiveDirectory Essas marcas de serviço são necessárias além do FQDN para a regra de aplicativo do Azure Key Vault.
Identidade Gerenciada AzureActiveDirectory Ao usar a Identidade Gerenciada com Aplicativos de Contêiner do Azure, será necessário configurar essas regras de aplicativo usadas pela Identidade Gerenciada.

Observação

Para os recursos do Azure que você está usando com o Firewall do Azure não listado neste artigo, veja a documentação de marcas de serviço.

Integração do gateway da NAT

Você pode usar o Gateway da NAT para simplificar a conectividade de saída para o tráfego de saída da Internet em sua rede virtual em um ambiente de perfis de carga de trabalho.

Ao configurar um Gateway da NAT em sua sub-rede, o Gateway da NAT fornece um endereço IP público estático para seu ambiente. Todo o tráfego de saída do aplicativo de contêiner é roteado por meio do endereço IP público estático do Gateway da NAT.

Segurança do ambiente

Diagrama de como bloquear totalmente sua rede para Aplicativos de Contêiner do Azure.

Você pode proteger totalmente o ambiente de perfis de carga de trabalho de tráfego de rede de entrada e saída adotando as seguintes ações:

Criptografia ponto a ponto no ambiente de Aplicativos de Contêiner do Azure

Os Aplicativos de Contêiner do Azure dão suporte à criptografia TLS ponto a ponto no ambiente. A habilitação dessa funcionalidade encripta todo o tráfego de rede dentro do ambiente com um certificado privado válido dentro do âmbito do ambiente Aplicativos de Contêiner do Azure. Esses certificados são geridos automaticamente pelos Aplicativos de Contêiner do Azure.

Observação

Por padrão, a criptografia ponto a ponto está desabilitada. Habilitar a criptografia ponto a ponto para seus aplicativos pode aumentar a latência de resposta e reduzir a taxa de transferência máxima em cenários de alta carga.

O exemplo a seguir mostra um ambiente com criptografia ponto a ponto habilitada. Diagrama de como o tráfego é criptografado/descriptografado com a criptografia ponto a ponto habilitada.

1 O tráfego TLS de entrada é encerrado no proxy de entrada na borda do ambiente.

2 O tráfego de e para o proxy de entrada dentro do ambiente é criptografado por TLS com um certificado privado e descriptografado pelo receptor.

3 As chamadas feitas do aplicativo A para o FQDN do aplicativo B são enviadas primeiro para o proxy de entrada de borda e são criptografadas por TLS.

4 As chamadas feitas do aplicativo A para o aplicativo B usando o nome do aplicativo B são enviadas diretamente para o aplicativo B e são criptografadas por TLS.

Os aplicativos em um ambiente de Aplicativos de Contêiner são autenticados automaticamente. No entanto, o tempo de execução do Aplicativos de Contêiner do Azure não dá suporte à autorização para controle de acesso entre aplicativos usando a criptografia ponto a ponto integrada.

Quando seus aplicativos se comunicam com um cliente fora do ambiente, há suporte para a autenticação bidirecional com mTLS. Para saber mais, confira configurar certificados do cliente.

Você pode habilitar a criptografia ponto a ponto usando os comandos a seguir.

Ao criar:

az containerapp env create \
    --name <environment-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-peer-to-peer-encryption

Para um aplicativo de contêiner existente:

az containerapp env update \
    --name <environment-name> \
    --resource-group <resource-group> \
    --enable-peer-to-peer-encryption

DNS

  • DNS personalizado: se a VNET usar um servidor DNS personalizado em vez do servidor DNS padrão fornecido pelo Azure, configure o servidor DNS para encaminhar as consultas DNS não resolvidas para 168.63.129.16. Os resolvedores recursivos do Azure usam esse endereço IP para resolver as solicitações. Ao configurar seu NSG ou firewall, não bloqueie o endereço 168.63.129.16, caso contrário, seu ambiente de Aplicativos de Contêiner não funcionará corretamente.

  • Entrada de escopo da VNET: se você pretende usar a entrada de escopo da VNET em um ambiente interno dos Aplicativos de Contêiner, configure seus domínios usando uma das seguintes maneiras:

    1. Domínios não personalizados: se você não pretende usar um domínio personalizado, crie uma zona DNS privada que resolva o domínio padrão do ambiente dos Aplicativos de Contêiner para o endereço IP estático do ambiente dos Aplicativos de Contêiner. Use o DNS privado do Azure ou um servidor DNS próprio. Se você usar o DNS Privado do Azure, crie uma Zona DNS privada nomeada como o domínio padrão do ambiente do Aplicativo de Contêiner (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io), com um registro A. O registro A contém o nome *<DNS Suffix> e o endereço IP estático do ambiente dos Aplicativos de Contêiner.

    2. Domínios personalizados: se você pretende usar domínios personalizados e está usando um ambiente externo dos Aplicativos de Contêiner, use um domínio resolvível publicamente para adicionar um domínio personalizado e um certificado ao aplicativo contêiner. Se você estiver usando um ambiente interno de Aplicativos de Contêiner, não haverá validação para a associação DNS, pois o cluster só poderá ser acessado de dentro da rede virtual. Além disso, crie uma zona DNS privada que resolva o domínio apex para o endereço IP estático do ambiente dos Aplicativos de Contêiner. Use o DNS privado do Azure ou um servidor DNS próprio. Se você usar o DNS privado do Azure, crie uma zona DNS privada nomeada como o domínio apex, com um registro A que aponte para o endereço IP estático do ambiente dos Aplicativos de Contêiner.

O endereço IP estático do ambiente de Aplicativos de Contêiner está disponível no portal do Azure em Sufixo DNS personalizado da página do aplicativo de contêiner ou usando o comando az containerapp env list da CLI do Azure.

Recursos gerenciados

Ao implantar um ambiente interno ou externo em sua própria rede, um novo grupo de recursos é criado na assinatura do Azure em que seu ambiente está hospedado. Este grupo de recursos contém componentes de infraestrutura gerenciados pela plataforma de Aplicativos de Contêiner do Azure. Não modifique os serviços neste grupo ou no próprio grupo de recursos.

Ambiente de perfis de carga de trabalho

O nome do grupo de recursos criado na assinatura do Azure em que seu ambiente está hospedado é prefixado com ME_ por padrão e o nome do grupo de recursos pode ser personalizado ao criar seu ambiente de aplicativo de contêiner.

Para ambientes externos, o grupo de recursos contém um endereço IP público usado especificamente para conectividade de entrada com seu ambiente externo e um balanceador de carga. Para ambientes internos, o grupo de recursos contém apenas um balanceador de carga.

Além da cobrança dos Aplicativos de Contêiner do Azure, você será cobrado por:

  • Um IP estático padrão para saída, se estiver usando um ambiente interno ou externo, e um IP estático padrão para entrada, se estiver usando um ambiente externo. Se você precisar de mais IPs para saída devido a problemas de SNAT, abra um tíquete de suporte para solicitar uma substituição.

  • Um balanceador de carga de padrão.

  • Os custos de dados processados (em GBs) incluem a entrada e a saída das operações de gerenciamento.

Ambiente somente de consumo

O nome do grupo de recursos criado na assinatura do Azure onde seu ambiente está hospedado é prefixado com MC_ por padrão, e o nome do grupo de recursos não pode ser personalizado ao criar um aplicativo de contêiner. O grupo de recursos contém IPs usados especificamente para a conectividade de saída do ambiente e um balanceador de carga.

Além da cobrança dos Aplicativos de Contêiner do Azure, você será cobrado por:

Próximas etapas