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

APLICA-SE A: Todas as camadas de gerenciamento de API

Os microsserviços são perfeitos para criar APIs. Com o Serviço Kubernetes do Azure (AKS), 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 conhecimento básico de Kubernetes, Gerenciamento de API e rede do Azure.

Fundo

Ao publicar microsserviços como APIs para consumo, pode ser um desafio gerenciar a comunicação entre os microsserviços e os clientes que os consomem. Há uma infinidade de preocupações transversais, como autenticação, autorização, limitação, cache, transformação e monitoramento. Essas preocupações são válidas independentemente de os microsserviços estarem expostos a clientes internos ou externos.

O padrão API Gateway aborda essas preocupações. Um gateway de API serve como uma porta de entrada para os microsserviços, separa os clientes de seus microsserviços, adiciona uma camada adicional de segurança e diminui a complexidade de seus microsserviços, removendo a carga de lidar com preocupações transversais.

O Gerenciamento de API do Azure é uma solução pronta para uso 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, ele também fornece recursos adicionais, incluindo um portal do desenvolvedor de autoatendimento para descoberta de API, gerenciamento do ciclo de vida da API e 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, passaremos por algumas opções de implantação do AKS em conjunto com o Gerenciamento de API.

Serviços e APIs do Kubernetes

Em um cluster 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 morre, os Pods em execução no nó são perdidos. Portanto, o endereço IP de um Pod pode mudar a qualquer momento. Não podemos confiar nele para nos comunicarmos com o pod.

Para resolver esse problema, o Kubernetes introduziu o conceito de Serviços. Um Serviço 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 estivermos prontos para publicar nossos microsserviços como APIs por meio do Gerenciamento de API, precisamos pensar em como mapear nossos Serviços no Kubernetes para APIs no Gerenciamento de API. Não há regras definidas. Depende de como você projetou e particionou seus recursos de negócios ou domínios em 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 um determinado recurso (por exemplo, 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, PlaceOrder), vários Serviços poderão ser logicamente agregados em uma única API no gerenciamento de API (consulte 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 corretamente nossos microsserviços ao longo do tempo.

Implante o Gerenciamento de API na frente do AKS

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

Embora um cluster AKS seja sempre implantado em uma rede virtual (VNet), uma instância de Gerenciamento de API não precisa ser implantada em uma VNet. Quando o Gerenciamento de API não reside na rede virtual do cluster, o cluster AKS precisa publicar pontos de extremidade públicos para que o Gerenciamento de API se conecte. 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 analisar as opções.

Opção 1: Expor os Serviços publicamente

Os serviços em um cluster AKS podem ser expostos publicamente usando os tipos de serviço NodePort, LoadBalancer ou ExternalName. Neste caso, os Serviços são acessíveis diretamente a partir da Internet pública. Depois de implantar o Gerenciamento de API na frente do cluster, precisamos garantir que todo o tráfego de entrada passe pelo Gerenciamento de API aplicando 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.

Esta pode ser a opção mais fácil para implantar o Gerenciamento de API na frente do AKS, especialmente se você já tiver a lógica de autenticação implementada em seus 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á estiverem expostos publicamente e a lógica de autenticação já existir em microsserviços

Contras:

• Risco potencial de segurança devido à visibilidade pública dos pontos finais
• Nenhum ponto de entrada único para o tráfego de cluster de entrada
• Complica microsserviços com lógica de autenticação duplicada

Opção 2: Instalar um controlador de entrada

Embora a opção 1 possa ser mais fácil, tem desvantagens notáveis, como mencionado acima. Se uma instância de Gerenciamento de API não residir na rede virtual do cluster, a autenticação TLS mútua (mTLS) será uma maneira robusta de garantir que o tráfego seja seguro e confiável em ambas as direções entre uma instância de Gerenciamento de API e um cluster AKS.

A autenticação TLS mútua é suportada nativamente pelo Gerenciamento de API e pode ser habilitada no Kubernetes instalando um Controlador de Ingresso (Fig. 3). Como resultado, a autenticação será realizada no Ingress Controller, o que simplifica os microsserviços. Além disso, você pode adicionar os endereços IP do Gerenciamento de API à lista de permissões por Ingress para garantir que apenas o Gerenciamento de API tenha acesso ao cluster. Se a camada Premium de Gerenciamento de API ou a camada V2 padrão forem usadas, o isolamento no nível de rede poderá ser alcançado.

Prós:

• Configuração fácil no lado do Gerenciamento de API, pois ele não precisa ser injetado no cluster VNet e o mTLS é suportado nativamente
• 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 publicamente visíveis

Contras:

• Aumenta a complexidade da configuração do cluster devido ao trabalho extra para instalar, configurar e manter o Ingress Controller e gerenciar certificados usados para mTLS
• Risco de segurança devido à visibilidade pública do(s) endpoint(s) do Ingress Controller, a menos que o nível API Management Standard v2 ou Premium esteja sendo usado.

Quando você publica APIs por meio do Gerenciamento de APIs, é fácil e comum 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 quando fizerem chamadas para essas APIs. Caso contrário, as chamadas serão rejeitadas imediatamente pelo gateway de Gerenciamento de API. Eles não são encaminhados para os serviços de back-end.

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

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

Em alguns casos, os clientes com restrições regulamentares ou requisitos de segurança rigorosos podem considerar as soluções das Opções 1 e 2 inviáveis devido a terminais expostos publicamente. Em outros, o cluster AKS e os aplicativos que consomem os microsserviços podem residir na mesma VNet, portanto, não há razão para expor o cluster publicamente, pois todo o tráfego da API permanecerá dentro da VNet. Para esses cenários, você pode implantar o Gerenciamento de API na rede virtual do cluster. O API Management Developer e as camadas Premium suportam a implantação de VNet.

Há dois modos de implantação do Gerenciamento de API em uma VNet – Externa e Interna.

Se os consumidores de API não residirem na rede virtual do cluster, o modo externo (Fig. 4) deverá ser usado. Nesse modo, o gateway de Gerenciamento de API é injetado na VNet do cluster, mas acessível a partir da Internet pública por meio de um balanceador de carga externo. Ele ajuda a ocultar completamente o cluster e, ao mesmo tempo, permite que clientes externos consumam os microsserviços. Além disso, você pode usar os recursos 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 rede virtual do cluster, o modo Interno (Fig. 5) poderá ser usado. Nesse modo, o gateway de Gerenciamento de API é injetado na VNET do cluster e acessível somente de dentro dessa VNet por meio de um balanceador de carga interno. Não há como acessar o gateway de Gerenciamento de API ou o cluster AKS a partir da Internet pública.

Em ambos os casos, o cluster AKS não é visível publicamente. Em comparação com a Opção 2, o Controlador de Ingresso 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 seus microsserviços. Por exemplo, se um Service Mesh for adotado, ele sempre exigirá autenticação TLS mútua.

Prós:

• A opção mais segura porque o cluster AKS não tem ponto de extremidade público
• Simplifica a configuração do cluster, uma vez que não tem 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 recursos de rede do Azure, como NSG (Network Security Groups)

Contras:

• Aumenta a complexidade da implantação e configuração do Gerenciamento de API para trabalhar dentro da VNet

Próximos passos

• Saiba mais sobre os conceitos de Rede para aplicações no AKS
• Saiba mais sobre Como usar o Gerenciamento de API com redes virtuais