Descrição geral do gateway autohospedado

APLICA-SE A: Developer | Premium

O gateway auto-hospedado é uma versão opcional e conteinerizada do gateway gerenciado padrão incluído em cada instância de Gerenciamento de API. É útil para cenários como a colocação de gateways nos mesmos ambientes em que você hospeda suas APIs. Use o gateway auto-hospedado para melhorar o fluxo de tráfego da API e atender aos requisitos de segurança e conformidade da API.

Este artigo explica como o recurso de gateway auto-hospedado do Gerenciamento de API do Azure habilita o gerenciamento de API híbrido e multicloud. Ele também apresenta a arquitetura de alto nível do recurso e descreve seus recursos.

Para obter uma visão geral das diferenças entre gateways gerenciados e auto-hospedados, consulte API gateway em Gerenciamento de API.

Gestão de API em ambientes híbridos e multicloud

O recurso de gateway auto-hospedado expande o suporte ao Gerenciamento de API para ambientes híbridos e multicloud e permite que você gerencie com eficiência e segurança APIs hospedadas no local e entre nuvens a partir de uma única instância de Gerenciamento de API no Azure.

Com o gateway auto-hospedado, você tem a flexibilidade de implantar uma versão em contêiner do componente de gateway de Gerenciamento de API nos mesmos ambientes em que hospeda suas APIs. Todos os gateways auto-hospedados são gerenciados a partir da instância de Gerenciamento de API com a qual são federados, proporcionando visibilidade e experiência de gerenciamento unificada em todas as APIs internas e externas.

Cada instância de Gerenciamento de API é composta pelos seguintes componentes principais:

Um plano de gerenciamento, exposto como uma API, usado para configurar o serviço por meio do portal do Azure, PowerShell e outras tecnologias com suporte
Um gateway (ou plano de dados), responsável por fazer proxy de solicitações de API, aplicar políticas e coletar telemetria
Um portal do desenvolvedor usado por desenvolvedores para descobrir, aprender e integrar o uso das APIs

Por padrão, todos esses componentes são implantados no Azure, fazendo com que todo o tráfego da API (mostrado como setas pretas sólidas na imagem a seguir) flua pelo Azure, independentemente de onde os back-ends que implementam as APIs estão hospedados. A simplicidade operacional deste modelo tem o custo de maior latência, problemas de conformidade e, em alguns casos, taxas extras de transferência de dados.

A implantação de gateways auto-hospedados nos mesmos ambientes onde as implementações de API de back-end estão hospedadas permite que o tráfego de API flua diretamente para as APIs de back-end, o que reduz a latência, otimiza os custos de transferência de dados e permite a conformidade, mantendo os benefícios de ter um único ponto de gerenciamento, observabilidade e descoberta para todas as APIs na organização, independentemente de onde suas implementações estão hospedadas.

Embalagem

O gateway autoalojado está disponível como uma imagem de contentor Docker baseada em Linux a partir do Registo de Artefatos da Microsoft. Ele pode ser implantado no Docker, Kubernetes ou qualquer outra solução de orquestração de contêineres em execução em um cluster de servidores no local, infraestrutura de nuvem ou, para fins de avaliação e desenvolvimento, em um computador pessoal. Também pode implementar o gateway autoalojado como extensão de cluster num cluster do Kubernetes compatível com o Azure Arc.

Imagens de container

Uma variedade de imagens de contentores para gateways autogeridos está disponível:

Convenção de tags	Recomendação	Exemplo	Etiqueta rolante	Recomendado para produção
`{major}.{minor}.{patch}`	Use essa tag para executar sempre a mesma versão do gateway.	`2.0.0`	❌	✔️
`v{major}`	Use essa tag para sempre executar uma versão principal do gateway com cada novo recurso e patch.	`v2`	✔️	❌
`v{major}-preview`	Use essa tag se quiser sempre executar a imagem de contêiner de visualização mais recente.	`v2-preview`	✔️	❌
`latest`	Use essa tag se quiser avaliar o gateway auto-hospedado.	`latest`	✔️	❌
`beta` ¹	Use essa tag se quiser avaliar as versões de pré-visualização do gateway auto-hospedado.	`beta`	✔️	❌

Você pode encontrar uma lista completa de tags disponíveis aqui.

1 As versões de pré-visualização não são oficialmente suportadas e destinam-se apenas a fins experimentais. Consulte as políticas de suporte do gateway autogerido.

Uso de tags em opções oficiais de implantação

As opções de implantação no portal do Azure utilizam a v2 tag que permite utilizar a versão mais recente da imagem de contentor v2 do gateway auto-hospedado, com todas as atualizações de funcionalidades e patches.

Nota

O comando e os trechos de YAML são fornecidos como referência. Você pode usar uma tag mais específica, se desejar.

Quando você instala um gateway com um gráfico Helm, a marcação de imagem é otimizada. A versão da aplicação do gráfico Helm fixa o gateway numa determinada versão e não depende de latest.

Para obter mais informações, consulte Instalar um gateway auto-hospedado de Gerenciamento de API no Kubernetes com Helm.

Risco da utilização de etiquetas rolantes

Tags rolantes são aquelas tags que são atualizadas quando uma nova versão da imagem de contentor é lançada. O uso desse tipo de tags permite que os usuários de contêiner recebam atualizações para a imagem de contêiner sem precisar atualizar suas implantações.

Ao usar esse tipo de tag, você pode executar versões diferentes em paralelo sem perceber, por exemplo, quando executa ações de dimensionamento após a v2 atualização da tag.

Exemplo: A v2 tag é liberada com a imagem do 2.0.0 contêiner. Quando 2.1.0 é liberado, o tag v2 será vinculado à imagem 2.1.0.

Importante

Considere o uso de uma tag de versão específica na produção para evitar atualizações não intencionais para uma versão mais recente.

Conectividade ao Azure

Os gateways autoalojados precisam de conectividade TCP/IP de saída para o Azure na porta 443. Cada gateway auto-hospedado deve ser associado a uma única instância de Gerenciamento de API e é configurado por meio de seu plano de gerenciamento. Um gateway autogerido utiliza a conectividade ao Azure para:

Relatando seu status enviando mensagens de batimento cardíaco a cada minuto.
Regularmente (a cada 10 segundos) verificando e aplicando atualizações de configuração sempre que estiverem disponíveis.
Enviar métricas para o Azure Monitor, se configurado para isso.
Envio de eventos para o Application Insights, se configurado para isso.

Dependências de Nome de Domínio Completo (FQDN)

Para operar corretamente, cada gateway auto-hospedado precisa de conectividade de saída na porta 443 para os seguintes pontos de extremidade associados à sua instância de Gerenciamento de API baseada em nuvem:

Ponto final	Necessário?	Notas
Nome do host do ponto de extremidade de configuração	`<api-management-service-name>.configuration.azure-api.net` ¹	Nomes de host personalizados também são suportados e podem ser usados em vez do nome de host padrão.
Endereço IP público da instância de Gerenciamento de API	✔️	O endereço IP do local principal é suficiente.
Endereços IP públicos da marca de serviço de Armazenamento do Azure	Opcional²	Os endereços IP devem corresponder ao local principal da instância de Gerenciamento de API.
Nome do host da conta de Armazenamento de Blobs do Azure	Opcional²	A conta associada à instância (`<blob-storage-account-name>.blob.core.windows.net`).
Nome do host da conta do Armazenamento de Tabela do Azure	Opcional²	A conta associada à instância (`<table-storage-account-name>.table.core.windows.net`).
Pontos de extremidade para o Azure Resource Manager	Opcional³	O ponto de extremidade necessário é `management.azure.com`.
Pontos de extremidade para integração com o Microsoft Entra	Opcional⁴	Os pontos finais necessários são `<region>.login.microsoft.com` e `login.microsoftonline.com`.
Pontos de extremidade para integração do Azure Application Insights	Opcional⁵	Os pontos finais mínimos necessários são `rt.services.visualstudio.com:443`, `dc.services.visualstudio.com:443`e `{region}.livediagnostics.monitor.azure.com:443`. Para obter mais informações, consulte a documentação do Azure Monitor.
Pontos de extremidade para integração com Hubs de Eventos	Opcional⁵	Para obter mais informações, consulte a documentação dos Hubs de Eventos do Azure.
Pontos de extremidade para integração de cache externo	Opcional⁵	Esse requisito depende do cache externo que está sendo usado.

^1ºPara obter informações sobre uma instância de Gerenciamento de API em uma rede virtual interna, consulte Conectividade em uma rede virtual interna.
2 Necessário apenas na v2 quando o inspetor de API ou as cotas são usados em políticas.
3 Necessário apenas quando se utiliza a autenticação da Microsoft Entra para verificar as permissões RBAC.
⁴Apenas necessário quando utiliza a autenticação da Microsoft Entra ou políticas relacionadas com a Microsoft Entra.
^5ºNecessário apenas quando o recurso é usado e requer informações públicas de endereço IP, porta e nome de host.

Importante

Os nomes de host DNS devem ser resolúveis para endereços IP e os endereços IP correspondentes devem ser acessíveis.
Os nomes de conta de armazenamento associados estão listados na página Status de conectividade de rede do serviço no portal do Azure.
Os endereços IP públicos subjacentes às contas de armazenamento associadas são dinâmicos e podem ser alterados sem aviso prévio.

Conectividade em uma rede virtual interna

Conectividade privada. Se o gateway autogerido for implementado numa rede virtual, habilite a conectividade privada para o endpoint de configuração v2 a partir do local do gateway autogerido, por exemplo, usando um DNS privado numa rede virtual associada.
Conectividade com a Internet. Se o gateway auto-hospedado precisar se conectar ao ponto de extremidade de configuração v2 pela Internet, configure um nome de host personalizado para o ponto de extremidade de configuração e exponha o ponto de extremidade usando o Gateway de Aplicativo do Azure.

Opções de autenticação

As definições de configuração do contêiner de gateway fornecem as seguintes opções para autenticar a conexão entre o gateway auto-hospedado e o ponto de extremidade de configuração da instância de Gerenciamento de API baseada em nuvem.

Opção	Considerações
Autenticação do Microsoft Entra	Configure um ou mais aplicativos Microsoft Entra para acesso ao gateway. Gerencie o acesso separadamente por aplicativo. Configure tempos de expiração mais longos para segredos de acordo com as políticas da sua organização. Use os procedimentos padrão do Microsoft Entra para atribuir ou revogar permissões de utilizador ou grupo para aplicativos e para rodar segredos.
Token de acesso ao gateway. (Também chamada de chave de autenticação.)	O token expira pelo menos a cada 30 dias e deve ser renovado nos contêineres. Apoiado por uma chave de gateway que pode ser girada independentemente (por exemplo, para revogar o acesso). A regeneração da chave do gateway invalida todos os tokens de acesso criados com ela.

Sugestão

Consulte Gestão de API do Azure como uma fonte do Event Grid para informações sobre eventos do Event Grid gerados por um gateway autohospedado quando um token de acesso do gateway está perto da expiração ou expirou. Use esses eventos para garantir que os gateways implantados sempre possam se autenticar com sua instância de Gerenciamento de API associada.

Falhas de conectividade

Quando a conectividade com o Azure é perdida, o gateway auto-hospedado não consegue receber atualizações de configuração, relatar seu status ou carregar telemetria.

O gateway auto-hospedado foi projetado para "falhar estático" e pode sobreviver à perda temporária de conectividade com o Azure. Ele pode ser implantado com ou sem backup de configuração local. Com o backup de configuração, os gateways auto-hospedados salvam regularmente uma cópia de backup da configuração baixada mais recente em um volume persistente anexado ao contêiner ou pod.

Quando o backup de configuração é desativado e a conectividade com o Azure é interrompida:

A execução de gateways auto-hospedados continua a funcionar usando uma cópia na memória da configuração.
Os gateways auto-hospedados parados não conseguirão ser reiniciados.

Quando o backup de configuração é ativado e a conectividade com o Azure é interrompida:

Gateways auto-hospedados em execução continuam a funcionar, utilizando uma cópia na memória da configuração.
Os gateways auto-hospedados interrompidos podem começar usando uma cópia de backup da configuração.

Quando a conectividade é restaurada, cada gateway auto-hospedado afetado pela interrupção se reconecta automaticamente com sua instância de Gerenciamento de API associada e baixa todas as atualizações de configuração que ocorreram enquanto o gateway estava offline.

Segurança

Limitações

A seguinte funcionalidade disponível em gateways gerenciados não está disponível em gateways auto-hospedados:

Reinício da sessão TLS.
Renegociação do certificado do cliente. Para usar a autenticação de certificado de cliente, os consumidores de API devem apresentar seus certificados como parte do handshake TLS inicial. Para garantir esse comportamento, habilite a configuração Negociação de certificado de cliente ao configurar um nome de domínio personalizado para um gateway auto-hospedado.

Segurança da Camada de Transporte (TLS)

Protocolos suportados

Os gateways auto-hospedados suportam TLS v1.2 por padrão.

Se você usar domínios personalizados, poderá habilitar o TLS v1.0 e/ou v1.1 no plano de controle.

Pacotes de codificação disponíveis

Os gateways auto-hospedados usam os seguintes pacotes de codificação para conexões de cliente e servidor:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA

Gerenciando pacotes de codificação

Com a v2.1.1 e posterior, você pode gerenciar as cifras que estão sendo usadas por meio da configuração:

net.server.tls.ciphers.allowed-suites permite definir uma lista separada por vírgulas de cifras a serem usadas para a conexão TLS entre o cliente de API e o gateway auto-hospedado.
net.client.tls.ciphers.allowed-suites permite definir uma lista separada por vírgulas de cifras a serem usadas para a conexão TLS entre o gateway auto-hospedado e o back-end.

Comentários

Esta página foi útil?

Last updated on 2025-10-30