Descrição geral do gateway autoalojado

  • Artigo

APLICA-SE A: Developer | Prémio

O gateway auto-hospedado é uma versão opcional em contêiner do gateway gerenciado padrão incluído em cada serviço 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, apresenta sua arquitetura de alto nível e destaca seus recursos.

Para obter uma visão geral dos recursos nas várias ofertas de gateway, consulte API gateway em Gerenciamento de API.

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

A funcionalidade do gateway autoalojado expande o suporte da Gestão de API para ambientes híbridos e multicloud e permite às organizações gerir de forma eficiente e segura as APIs alojadas no local e em clouds a partir de um único serviço Gestão 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 de gateway de Gerenciamento de API nos mesmos ambientes em que hospedam suas APIs. Todos os gateways auto-hospedados são gerenciados a partir do serviço de Gerenciamento de API com o qual são federados, fornecendo aos clientes a visibilidade e a experiência de gerenciamento unificada em todas as APIs internas e externas.

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

  • Plano de gestão, exposto como uma API, utilizado para configurar o serviço através do portal do Azure, do PowerShell e de outros mecanismos suportados.
  • Gateway (ou plano de dados), o qual é responsável por suportar com proxy os pedidos de API, aplicar políticas e recolher telemetria
  • Portal do programador utilizado pelos programadores para detetar, integrar e aprender a utilizar 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 deste modelo tem o custo de maior latência, problemas de conformidade e, em alguns casos, taxas extras de transferência de dados.

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

A implementação de gateways autoalojados nos mesmos ambientes em que as implementações da API de back-end estão alojadas permite que o tráfego da API flua diretamente para as APIs de back-end, o que reduz a latência, otimiza os custos da transferência de dados e permite a conformidade, ao mesmo tempo que mantém os benefícios de ter um único ponto de gestão, observabilidade e deteção de todas as APIs na organização, independentemente de onde as implementações estejam alojadas.

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

Packaging

O gateway autoalojado está disponível como imagem de contentor do Docker baseada no Linux a partir do Registo de Artefactos da Microsoft. Pode ser implementado no Docker, no Kubernetes ou em qualquer outra solução de orquestração de contentores em execução num cluster de servidores no local, numa infraestrutura da cloud ou para fins de avaliação e desenvolvimento, num 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 contentor

Fornecemos uma variedade de imagens de contêiner para gateways auto-hospedados para atender às suas necessidades:

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 nossa imagem de contêiner de visualização mais recente. v2-preview ✔️ ❌
latest Use essa tag se quiser avaliar o gateway auto-hospedado. latest ✔️ ❌
beta1 Use essa tag se quiser avaliar as versões de 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 de gateway auto-hospedado.

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

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

Nota

Nós fornecemos o comando e trechos YAML como referência, sinta-se livre para usar uma tag mais específica, se desejar.

Ao instalar com nosso gráfico Helm, a marcação de imagens é otimizada para você. A versão do aplicativo do gráfico Helm fixa o gateway para uma determinada versão e não depende latestdo .

Saiba mais sobre como instalar um gateway auto-hospedado do Gerenciamento de API no Kubernetes com o Helm.

Risco da utilização de etiquetas rolantes

Tags contínuas são tags que são potencialmente atualizadas quando uma nova versão da imagem de contêiner é lançada. Isso permite que os usuários do contêiner recebam atualizações para a imagem do contêiner sem precisar atualizar suas implantações.

Isso significa que você pode executar versões diferentes em paralelo sem perceber, por exemplo, quando executa ações de dimensionamento depois v2 que a tag foi atualizada.

Exemplo - v2 a tag foi liberada com 2.0.0 a imagem do contêiner, mas quando 2.1.0 for liberada, a v2 tag será vinculada à 2.1.0 imagem.

Importante

Considere o uso de uma tag de versão específica na produção para evitar a atualização não intencional 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 autoalojado tem de estar associado a um único serviço Gestão de API e configurado através do respetivo plano de gestão. Um gateway autoalojado utiliza a conectividade ao Azure para:

  • Comunicar o respetivo estado ao enviar mensagens de heartbeat a cada minuto
  • Verificar regularmente (a cada 10 segundos) se existem atualizações de configuração para as aplicar sempre que estiverem disponíveis
  • Enviar métricas para o Azure Monitor, se estiver configurado para o fazer
  • Enviar eventos para o Application Insights, se estiver definido para o fazer

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:

Description Necessário para v1 Necessário para v2 Notas
Nome do host do ponto de extremidade de configuração <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net1 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 ✔️ Opcional2 Os endereços IP devem corresponder ao local principal da instância de Gerenciamento de API.
Nome do host da conta de Armazenamento de Blob do Azure ✔️ Opcional2 Conta associada à instância (<blob-storage-account-name>.blob.core.windows.net)
Nome do host da conta do Armazenamento de Tabela do Azure ✔️ Opcional2 Conta associada à instância (<table-storage-account-name>.table.core.windows.net)
Pontos de extremidade para o Azure Resource Manager ✔️ Opcional3 Os endpoints necessários são management.azure.com.
Pontos de extremidade para integração com o Microsoft Entra ✔️ Opcional4 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 Opcional5 Opcional5 Os parâmetros de avaliação mínimos necessários são:
  • rt.services.visualstudio.com:443
  • dc.services.visualstudio.com:443
  • {region}.livediagnostics.monitor.azure.com:443
Saiba mais nos documentos do Azure Monitor
Pontos de extremidade para integração de 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

1 Para 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 ao usar a autenticação do Microsoft Entra para verificar as permissões RBAC.
4 Necessário apenas ao usar a autenticação do Microsoft Entra ou políticas relacionadas ao 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 são listados na página Status da 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 rede virtual interna

  • Conectividade privada - Se o gateway auto-hospedado for implantado em uma rede virtual, habilite a conectividade privada para o ponto de extremidade de configuração v2 a partir 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 Application Gateway.

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

Opção Considerações
Autenticação do Microsoft Entra Configurar um ou mais aplicativos do 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 procedimentos padrão do Microsoft Entra para atribuir ou revogar permissões de usuário ou grupo para o aplicativo e para girar segredos
Token de acesso ao 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 do gateway invalida todos os tokens de acesso criados com ela

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 continuará a funcionar usando uma cópia na memória da configuração
  • Gateways auto-hospedados interrompidos não poderão ser iniciados

Quando o backup de configuração é ativado e a conectividade com o Azure é 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 é restaurada, cada gateway auto-hospedado afetado pela interrupção se reconecta automaticamente com seu serviço de Gerenciamento de API associado e baixa todas as atualizações de configuração que ocorreram enquanto o gateway estava "offline".

Segurança

Limitações

A seguinte funcionalidade encontrada nos gateways gerenciados não está disponível nos 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 Negociar certificado de cliente ao configurar um nome de host personalizado de gateway auto-hospedado (nome de domínio).

Transport Layer Security (TLS)

Importante

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

Protocolos suportados

O gateway auto-hospedado fornece 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.

Pacotes de codificação disponíveis

Importante

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

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

A partir da v2.1.1 e superior, 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.

Próximos passos