Usar o Gerenciamento de API do Azure com microsserviços implantados no Serviço de Kubernetes do Azure

APLICA-SE A: todas as camadas do Gerenciamento de API

Os microsserviços são perfeitos para a criação de APIs. Com o AKS (Serviço de Kubernetes do Azure), você pode implantar e operar rapidamente uma arquitetura baseada em microsserviços na nuvem. Em seguida, você pode aproveitar o Gerenciamento de API do Azure (Gerenciamento de API) para publicar seus microsserviços como APIs para consumo interno e externo. Este artigo descreve as opções de implantação do Gerenciamento de API com o AKS. Ele pressupõe um conhecimento básico do Kubernetes, do Gerenciamento de API e da Rede do Azure.

Tela de fundo

Durante a publicação de microsserviços como APIs para consumo, pode ser difícil gerenciar a comunicação entre os microsserviços e os clientes que os consomem. Há uma infinidade de preocupações paralelas, como autenticação, autorização, limitação, cache, transformação e monitoramento. Essas preocupações são válidas, independentemente de os microsserviços serem expostos a clientes internos ou externos.

O padrão de gateway de API resolve essas preocupações. Um gateway de API serve como uma porta de front-end para os microsserviços, separa os clientes dos seus microsserviços, adiciona uma camada extra de segurança e diminui a complexidade dos microsserviços removendo a carga de lidar com preocupações paralelas.

O Gerenciamento de API do Azure é uma solução completa para resolver suas necessidades de gateway de API. Você pode criar rapidamente um gateway consistente e moderno para seus microsserviços e publicá-los como APIs. Como uma solução de gerenciamento de API de ciclo de vida completo, ela também fornece funcionalidades adicionais, incluindo um portal do desenvolvedor de autoatendimento para a descoberta, o gerenciamento de ciclo de vida e a análise de API.

Quando usados juntos, o AKS e o Gerenciamento de API fornecem uma plataforma para implantar, publicar, proteger, monitorar e gerenciar suas APIs baseadas em microsserviços. Neste artigo, veremos algumas opções de implantação do AKS em conjunto com o Gerenciamento de API.

Serviços e APIs do Kubernetes

Em um cluster do Kubernetes, os contêineres são implantados em pods, que são efêmeros e têm um ciclo de vida. Quando um nó de trabalho se torna inativo, os pods em execução no nó são perdidos. Portanto, o endereço IP de um pod pode ser alterado a qualquer momento. Não podemos depender dele para se comunicar com o pod.

Para resolver esse problema, o Kubernetes introduziu o conceito de Serviços. Um Serviço de Kubernetes é uma camada de abstração que define um grupo lógico de pods e permite a exposição de tráfego externo, balanceamento de carga e descoberta de serviço para esses pods.

Quando estamos prontos para publicar nossos microsserviços como APIs por meio do Gerenciamento de API, precisamos pensar em como mapear nossos serviços do Kubernetes para as APIs do Gerenciamento de API. Não há regras definidas. Isso dependerá de como você criou e particionou as funcionalidades de negócios ou os domínios nos microsserviços no início. Por exemplo, se os pods por trás de um serviço forem responsáveis por todas as operações em determinado recurso (por exemplo, o cliente), o serviço poderá ser mapeado para uma API. Se as operações em um recurso forem particionadas em vários microsserviços (por exemplo, GetOrder e PlaceOrder), vários serviços poderão ser logicamente agregados em uma só API no Gerenciamento de API (veja a Fig. 1).

Os mapeamentos também podem evoluir. Como o Gerenciamento de API cria uma fachada na frente dos microsserviços, ele nos permite refatorar e dimensionar os nossos microsserviços ao longo do tempo.

Implantar o Gerenciamento de API na frente do AKS

Há algumas opções de implantação do Gerenciamento de API na frente de um cluster do AKS.

Embora um cluster do AKS sempre seja implantado em uma VNet (rede virtual), uma instância do Gerenciamento de API não precisa ser implantada em uma VNet. Quando o Gerenciamento de API não reside na VNet do cluster, o cluster do AKS precisa publicar pontos de extremidade públicos para o Gerenciamento de API para conexão. Nesse caso, há a necessidade de proteger a conexão entre o Gerenciamento de API e o AKS. Em outras palavras, precisamos garantir que o cluster só possa ser acessado exclusivamente por meio do Gerenciamento de API. Vamos explorar as opções.

Opção 1: expor os serviços publicamente

Os serviços de um cluster do AKS podem ser expostos publicamente usando tipos de serviço NodePort, LoadBalancer ou ExternalName. Nesse caso, os serviços podem ser acessados diretamente pela Internet pública. Depois de implantarmos o Gerenciamento de API na frente do cluster, precisaremos garantir que todo o tráfego de entrada passe pelo Gerenciamento de API pela aplicação da autenticação nos microsserviços. Por exemplo, o Gerenciamento de API pode incluir um token de acesso em cada solicitação feita ao cluster. Cada microsserviço é responsável por validar o token antes de processar a solicitação.

Essa pode ser a opção mais fácil para implantar o Gerenciamento de API na frente do AKS, especialmente se você já tem a lógica de autenticação implementada nos microsserviços.

Prós:

• Configuração fácil no lado do Gerenciamento de API porque ele não precisa ser injetado na VNet do cluster
• Nenhuma alteração no lado do AKS se os serviços já estão expostos publicamente e se a lógica de autenticação já existe nos microsserviços

Contras:

• Possível risco de segurança devido à visibilidade pública dos pontos de extremidade
• Nenhum ponto de entrada única para o tráfego do cluster de entrada
• Complica os microsserviços com uma lógica de autenticação duplicada

Opção 2: instalar um controlador de entrada

Embora a Opção 1 possa ser mais fácil, ela tem desvantagens notáveis, conforme mencionado acima. Se uma instância do Gerenciamento de API não residir na VNet do cluster, a mTLS (autenticação TLS mútua) será uma forma robusta de garantir que o tráfego seja seguro e confiável nas duas direções entre uma instância do Gerenciamento de API e um cluster do AKS.

A autenticação TLS mútua tem suporte nativo no Gerenciamento de API e pode ser habilitada no Kubernetes pela instalação de um controlador de entrada (Fig. 3). Como resultado, a autenticação será executada no controlador de entrada, o que simplifica os microsserviços. Além disso, você pode adicionar os endereços IP do Gerenciamento de API à lista de permitidos por entrada para garantir que somente o Gerenciamento de API tenha acesso ao cluster. Se a Camada Premium ou a Camada Standard V2 do Gerenciamento de API for usada, o isolamento em nível de rede poderá ser alcançado.

Prós:

• Configuração fácil no lado do Gerenciamento de API porque ele não precisa ser injetado na VNet do cluster, e a mTLS tem suporte nativo
• Centraliza a proteção para o tráfego de cluster de entrada na camada do controlador de entrada
• Reduz o risco de segurança minimizando os pontos de extremidade de cluster visíveis publicamente

Contras:

• Aumenta a complexidade da configuração de cluster devido ao trabalho extra para instalar, configurar e manter o controlador de entrada e gerenciar os certificados usados para mTLS
• Risco de segurança devido à visibilidade pública do(s) ponto de extremidade(s) do Controlador de Entrada, a menos que a camada Standard v2 ou Premium do Gerenciamento de API esteja sendo usada.

Quando você publica APIs por meio do Gerenciamento de API, é fácil e normal proteger o acesso a essas APIs usando chaves de assinatura. Os desenvolvedores que precisam consumir as APIs publicadas devem incluir uma chave de assinatura válida em solicitações HTTP ao fazer chamadas para essas APIs. Caso contrário, as chamadas serão imediatamente rejeitadas pelo gateway de Gerenciamento de API. Elas não são encaminhadas para os serviços de back-end.

É necessária uma assinatura para obter uma chave de assinatura para acessar APIs. A assinatura é essencialmente um contêiner nomeado para um par de chaves de assinatura. Os desenvolvedores que precisam consumir as APIs publicadas podem obter as assinaturas. E eles não precisam da aprovação dos editores das APIs. Os editores de API também podem criar assinaturas diretamente para os consumidores da API.

Opção 3: implantar o APIM dentro da VNet do cluster

Em alguns casos, os clientes com restrições regulatórias ou requisitos de segurança estritos podem considerar as Opções 1 e 2 como soluções não viáveis devido aos pontos de extremidade publicamente expostos. Em outros, o cluster do AKS e os aplicativos que consomem os microsserviços podem residir na mesma VNet. Portanto, não há motivo para expor o cluster publicamente, pois todo o tráfego da API permanecerá na VNet. Para esses cenários, você pode implantar o Gerenciamento de API na VNet do cluster. As camadas Desenvolvedor e Premium do Gerenciamento de API dão suporte à implantação de VNet.

Há dois modos de implantar o Gerenciamento de API em uma VNet: externo e interno.

Se os consumidores da API não residirem na VNet do cluster, o modo externo (Fig. 4) deverá ser usado. Nesse modo, o gateway do Gerenciamento de API é injetado na VNet do cluster, mas fica acessível pela Internet pública por meio de um balanceador de carga externo. Isso ajuda a ocultar o cluster completamente e permitir que clientes externos consumam os microsserviços. Além disso, você pode usar as funcionalidades de rede do Azure, como NSG (grupos de segurança de rede) para restringir o tráfego de rede.

Se todos os consumidores de API residirem na VNet do cluster, o modo interno (Fig. 5) poderá ser usado. Nesse modo, o gateway do Gerenciamento de API é injetado na VNET do cluster e fica acessível somente dentro dessa VNet por meio de um balanceador de carga interno. Não é possível acessar o gateway do Gerenciamento de API ou o cluster do AKS pela Internet pública.

Em ambos os casos, o cluster do AKS não fica visível publicamente. Em comparação com a Opção 2, o controlador de entrada pode não ser necessário. Dependendo do cenário e da configuração, a autenticação ainda pode ser necessária entre o Gerenciamento de API e os microsserviços. Por exemplo, se a malha de serviço for adotada, ela sempre exigirá a autenticação TLS mútua.

Prós:

• A opção mais segura, porque o cluster do AKS não tem nenhum ponto de extremidade público
• Simplifica a configuração do cluster porque ele não tem nenhum ponto de extremidade público
• Capacidade de ocultar o Gerenciamento de API e o AKS dentro da VNet usando o modo interno
• Capacidade de controlar o tráfego de rede usando funcionalidades de rede do Azure, como NSG (grupos de segurança de rede)

Contras:

• Aumenta a complexidade de implantar e configurar o Gerenciamento de API para trabalhar dentro da VNet

Próximas etapas

• Saiba mais sobre os conceitos de rede para aplicativos no AKS
• Saiba mais sobre Como usar o Gerenciamento de API com redes virtuais