Visão geral do gateway auto-hospedado

APLICA-SE A: Desenvolvedor | Premium

O gateway auto-hospedado é uma versão opcional e em contêineres do gateway gerenciado padrão incluído em todas as instâncias de Gerenciamento de API. É útil para cenários como colocar gateways nos mesmos ambientes em que você hospeda suas APIs. Use o gateway auto-hospedado para aprimorar o fluxo de tráfego de 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íbrida e multinuvem. 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 o gateway de API no Gerenciamento de API.

Gerenciamento de API híbrida e de várias nuvens

O recurso de gateway auto-hospedado expande o suporte ao Gerenciamento de API para ambientes híbridos e multinuvem e permite que você gerencie com eficiência e segurança AS APIs hospedadas localmente e entre nuvens 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êineres do componente do gateway de Gerenciamento de API nos mesmos ambientes em que hospeda suas APIs. Todos os gateways auto-hospedados são gerenciados da instância de Gerenciamento de API com a qual são federados, fornecendo assim a visibilidade e a experiência de gerenciamento unificado 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, do PowerShell e de 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 pelos desenvolvedores para descobrir, aprender e integrar para usar as APIs

Por padrão, todos esses componentes são implantados no Azure, fazendo com que todo o tráfego de 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 desse modelo traz o custo de maior latência, problemas de conformidade e, em alguns casos, valores extras de transferência de dados.

A implantação de gateways auto-hospedados nos mesmos ambientes em que as implementações da API de back-end sã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.

Empacotamento

O gateway auto-hospedado está disponível como uma imagem de contêiner do Docker baseada em Linux do Registro de Artefato da Microsoft. Ele pode ser implantado no Docker, no Kubernetes ou em qualquer outra solução de orquestração de contêiner em execução em um cluster de servidor no local, na infraestrutura de nuvem ou, para fins de avaliação e desenvolvimento, em um computador pessoal. Você também pode implantar o gateway auto-hospedado como uma extensão de cluster em um cluster do Kubernetes habilitado para Azure Arc.

Imagens de contêiner

Uma variedade de imagens de contêiner para gateways auto-hospedados está disponível:

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

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

¹ As versões prévias não têm suporte oficial e são apenas para fins experimentais. Confira as políticas de suporte do gateway auto-hospedado.

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

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

Observação

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

Ao instalar um gateway com um chart do Helm, a marcação de imagens é otimizada. A versão do aplicativo do Pacote do Helm fixa o gateway a uma determinada versão e não depende de latest.

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

Risco de usar marcas sem interrupção

Marcas sem interrupção são marcas que são potencialmente atualizadas quando uma nova versão da imagem de contêiner é liberada. O uso desse tipo de rótulo permite que os usuários do contêiner recebam atualizações da imagem do contêiner sem precisar atualizar seus ambientes.

Ao usar esse tipo de marca, você pode executar versões diferentes em paralelo sem perceber, por exemplo, quando executa ações de dimensionamento depois que a v2 marca é atualizada.

Exemplo: a v2 tag é lançada com a imagem do contêiner 2.0.0. Quando 2.1.0 for lançado, o rótulo v2 estará vinculado à imagem 2.1.0.

Importante

Considere usar uma marca de versão específica em produção para evitar atualizações não intencionais para uma versão mais recente.

Conectividade com o Azure

Gateways auto-hospedados exigem 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. O gateway auto-hospedado usa a conectividade com o Azure para:

Relatar o status enviando mensagens de pulsação 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 fazer isso.
Enviar eventos para o Application Insights, se configurado para fazer isso.

Dependências de 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	Obrigatório?	Observações
Nome do host do ponto de extremidade da configuração	`<api-management-service-name>.configuration.azure-api.net` ¹	Nomes de host personalizados também são compatíveis e podem ser usados em vez do nome do host padrão.
O endereço IP público da instância de Gerenciamento de API	✔️	O endereço IP do local primário é suficiente.
Endereços IP públicos da tag de serviço do 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 de Armazenamento de Tabelas 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`.
Endpoints para integração do Microsoft Entra	Opcional⁴	Os pontos de extremidade 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 de extremidade 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 dos Hubs de Eventos	Opcional⁵	Para obter mais informações, consulte a documentação dos Hubs de Evento do Azure.
Pontos de extremidade para integração de cache externo	Opcional⁵	Esse requisito depende do cache externo que está sendo usado.

¹Para obter informações sobre uma instância de Gerenciamento de API em uma rede virtual interna, consulte Conectividade em uma rede virtual interna.
¹ Necessário somente na v2 em que o inspetor de API ou cotas são usados em políticas.
³ Necessário somente ao usar a autenticação do Microsoft Entra para verificar permissões do RBAC.
⁴Necessário somente quando você usa a autenticação do Microsoft Entra ou políticas relacionadas ao Microsoft Entra.
⁵Necessário somente quando o recurso é usado e requer informações de endereço IP público, porta e nome do host.

Importante

Os nomes de host DNS devem ser resolvidos 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 de 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 auto-hospedado estiver implantado em uma rede virtual, habilite a conectividade privada com o ponto de extremidade de configuração v2 na localização do gateway auto-hospedado, por exemplo, usando um DNS privado em uma rede emparelhada.
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 configurações de configuração do contêiner do gateway oferecem 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 do Gerenciamento de API baseada em nuvem.

Opção	Considerações
Autenticação do Microsoft Entra	Configure um ou mais aplicativos do Microsoft Entra para acesso ao gateway. Gerenciar 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 usuário ou grupo a aplicativos e para girar segredos.
Token de acesso do gateway. (Também chamado 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.

Dica

Consulte o Gerenciamento de API do Azure como uma origem da Grade de Eventos para obter informações sobre eventos da Grade de Eventos que são gerados por um gateway autônomo quando um token de acesso do gateway está próximo de expirar ou já expirou. Use esses eventos para garantir que os gateways implantados sejam sempre capazes de se autenticar com a instância de Gerenciamento de API associada.

Falhas na conectividade

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

O gateway auto-hospedado é projetado para "falhar de forma estática" 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 última configuração baixada em um volume persistente anexado ao seu contêiner ou Pod.

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

Gateways auto-hospedados em execução continuam a funcionar usando uma cópia na memória da configuração.
Gateways auto-hospedados parados não poderão ser iniciados.

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

Gateways auto-hospedados em execução continuam a funcionar usando uma cópia da configuração na memória.
Gateways autogerenciados que foram interrompidos podem reiniciar 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:

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

Protocolo TLS

Protocolos com suporte

Gateways auto-hospedados dão suporte ao 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.

Conjuntos de criptografia disponíveis

Os gateways auto-hospedados usam os seguintes conjuntos de criptografia 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

Gerenciar pacotes de criptografia

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

net.server.tls.ciphers.allowed-suites permite que você defina uma lista separada por vírgulas de criptografias 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 que você defina uma lista separada por vírgulas de criptografias 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