Compartilhar via

Visão geral do gateway auto-hospedado

  • Artigo

APLICA-SE A: Desenvolvedor | Premium

O gateway auto-hospedado é uma versão opcional, em contêineres, do gateway gerenciado padrão incluído em todos os serviços do Gerenciamento de API. Ele é ú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 permite o gerenciamento de API híbrida e de várias nuvens, apresenta sua arquitetura de alto nível e realça seus recursos.

Para obter uma visão geral dos recursos das várias ofertas de gateway, confira 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 de várias nuvens e permite que as organizações gerenciem com eficiência e segurança as APIs hospedadas no local e entre nuvens de um único serviço de Gerenciamento de API no Azure.

Com o gateway auto-hospedado, os clientes têm a flexibilidade de implantar uma versão em contêiner do componente do gateway de gerenciamento de API nos mesmos ambientes em que hospedam suas APIs. Todos os gateways auto-hospedados são gerenciados por meio do serviço API Management com o qual são federados, fornecendo aos clientes a experiência de gerenciamento unificada e de visibilidade em todas as APIs internas e externas.

Cada serviço de gerenciamento de API é composto pelos seguintes componentes principais:

  • Plano de gerenciamento, exposto como uma API, usado para configurar o serviço por meio do portal do Azure, do PowerShell e de outros mecanismos com suporte.
  • O gateway (ou o plano de dados), que é responsável por solicitações de proxy de API, aplicação de políticas e coleta de telemetria
  • Portal do desenvolvedor usado por desenvolvedores para descobrir, aprender e integrar para usar as APIs

Por padrão, todos esses componentes são implantados no Azure, causando todo o tráfego da API (mostrado como setas pretas sólidas na imagem a seguir) para fluir pelo Azure, independentemente de onde os back-ends implementando as APIs estejam 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.

Fluxo de tráfego de API sem gateways auto-hospedados

A implantação de gateways auto-hospedados nos mesmos ambientes em que as implementações de 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, a observabilidade e a descoberta de todas as APIs na organização, independentemente de onde suas implementações estejam hospedadas.

Fluxo de tráfego de API com gateways auto-hospedados

Empacotamento

O gateway auto-hospedado está disponível como uma imagem de contêiner do Docker baseada em Linux do Microsoft Artifact Registry. Ele pode ser implantado no Docker, Kubernetes ou qualquer outra solução de orquestração de contêiner em execução em um cluster de servidor local, 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

Fornecemos uma variedade de imagens de contêiner para gateways de hospedagem interna para atender às suas necessidades:

Convenção de marca Recomendação Exemplo Marca de rolagem Recomendado para produção
{major}.{minor}.{patch} Use essa marca 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 essa marca se você quiser sempre executar nossa imagem de contêiner de visualização mais recente. v2-preview ✔️ ❌
latest Use essa marca se você quiser avaliar o gateway auto-hospedado. latest ✔️ ❌
beta1 Use essa marca se você quiser avaliar as versões prévias do gateway auto-hospedado. beta ✔️ ❌

Você pode encontrar uma lista completa das marcações aqui.

1 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 marcas em nossas opções de implantação oficial

Nossas opções de implantação no portal do Azure usam a v2 marca que permite que os clientes usem a versão mais recente da imagem de contêiner do gateway v2 de hospedagem interna com todas as atualizações de recursos e patches.

Observação

Fornecemos os trechos de comando e YAML como referência, sinta-se à vontade para usar uma marca mais específica, se desejar.

Ao instalar o com o pacote do Helm, a marcação de imagem é otimizada para você. A versão do aplicativo do Pacote do Helm fixa o gateway a uma determinada versão e não depende de latest.

Saiba mais sobre como instalar um gateway de Gerenciamento de API auto-hospedado em Kubernetes com o 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. Isso permite que os usuários de contêiner recebam atualizações para a imagem de contêiner sem precisar atualizar suas implantações.

Isso significa que você pode potencialmente executar diferentes versões em paralelo sem perceber, por exemplo, ao executar ações de dimensionamento após v2 a atualização da marca.

Exemplo-a v2 marcação foi liberada com 2.0.0 a imagem de contêiner, mas quando 2.1.0 será liberado, a v2 marca será vinculada à 2.1.0 imagem.

Importante

Considere usar uma marca de versão específica na produção para evitar a atualização não intencional 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 um único serviço 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 seu status enviando mensagens de pulsação a cada minuto
  • Verificar regularmente (a cada 10 segundos) e aplicar atualizações de configuração sempre que elas estiverem disponíveis
  • Enviar métricas e logs de solicitação para o Azure Monitor, se configurado para fazer isso
  • Enviando eventos para Application Insights, se definido 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:

Descrição Necessário para v1 Necessário para v2 Observações
Nome do host do ponto de extremidade da configuração <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net1 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 é o suficiente.
Endereços IP públicos da marca de serviço de Armazenamento do Azure ✔️ Opcional2 Os endereços IP devem corresponder à localização primária da instância de Gerenciamento de API.
Nome do host da conta do Armazenamento de Blobs do Azure ✔️ Opcional2 Conta associada à instância (<blob-storage-account-name>.blob.core.windows.net)
Nome do host da conta do Armazenamento de Tabelas do Azure ✔️ Opcional2 Conta associada à instância (<table-storage-account-name>.table.core.windows.net)
Pontos de extremidade para Azure Resource Manager ✔️ Opcional3 Os pontos de extremidade necessários são management.azure.com.
Endpoints para integração do Microsoft Entra ✔️ Opcional4 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 Opcional5 Opcional5 Os pontos de extremidade mínimos necessários são:
  • rt.services.visualstudio.com:443
  • dc.services.visualstudio.com:443
  • {region}.livediagnostics.monitor.azure.com:443
Saiba mais em documentos do Azure Monitor
Pontos de extremidade para integração dos Hubs de Eventos Opcional5 Opcional5 Saiba mais nos documentos dos Hubs de Eventos do Azure
Pontos de extremidade para integração de cache externo Opcional5 Opcional5 Esse requisito depende do cache externo que está sendo usado

1Para uma instância de Gerenciamento de API em uma rede virtual interna, confira Conectividade em uma rede virtual interna.
1 Necessário somente na v2 em que o inspetor de API ou cotas são usados em políticas.
3 Necessário somente ao usar a autenticação do Microsoft Entra para verificar permissões do RBAC.
4Necessário somente ao usar a autenticação do Microsoft Entra ou as políticas relacionadas ao Microsoft Entra.
5 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 estar acessíveis.
  • Os nomes de conta de armazenamento associados sã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 na rede virtual interna

  • Conectividade privada – se o gateway auto-hospedado for implantado em uma rede virtual, habilite a conectividade privada com o ponto de extremidade de configuração v2 do local 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.

Opções de autenticação

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, você tem as seguintes opções nas configurações do contêiner de gateway.

Opção Considerações
autenticação do Microsoft Entra Configurar um ou mais aplicativos Microsoft Entra para acesso ao gateway

Gerenciar o acesso separadamente por aplicativo

Configurar tempos de expiração mais longos para segredos de acordo com as políticas da sua organização

Usar procedimentos padrão do Microsoft Entra para atribuir ou revogar permissões de usuário ou grupo ao aplicativo e girar segredos
Token de acesso do gateway (também chamado de chave de autenticação) O token expira a cada 30 dias, no máximo, e deve ser renovado nos contêineres

Apoiado por uma chave de gateway que pode ser girada independentemente (por exemplo, para revogar o acesso)

Regenerar a chave de gateway invalida todos os tokens de acesso criados com ela

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:

  • A execução de gateways auto-hospedados continuará a funcionar usando uma cópia na memória da configuração
  • Os gateways auto-hospedados interrompidos não poderão ser iniciados

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

  • A execução de gateways auto-hospedados continuará a funcionar usando uma cópia na memória da configuração
  • Os gateways auto-hospedados interrompidos poderão começar a usar uma cópia de backup da configuração

Quando a conectividade for restaurada, cada gateway auto-hospedado afetado pela interrupção será reconectado automaticamente ao seu serviço de gerenciamento de API associado e baixará todas as atualizações de configuração que ocorreram enquanto o gateway estava "offline".

Segurança

Limitações

A funcionalidade a seguir encontrada nos gateways gerenciados não está disponível nos 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

Importante

Essa visão geral só é aplicável ao gateway auto-hospedado v1 e v2.

Protocolos com suporte

O gateway auto-hospedado dá suporte para TLS v1.2 por padrão.

Os clientes que usam domínios personalizados podem habilitar o TLS v1.0 e/ou v1.1 no plano de controle.

Conjuntos de criptografia disponíveis

Importante

Essa visão geral só é aplicável ao gateway auto-hospedado v2.

O gateway auto-hospedado usa os seguintes pacotes 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

Da v2.1.1 em diante, 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írgula de criptografias a ser usada 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írgula de criptografias a ser usada para a conexão TLS entre o gateway auto-hospedado e o back-end.

Próximas etapas