Azure API Management gebruiken met microservices die zijn geïmplementeerd in Azure Kubernetes Service

VAN TOEPASSING OP: Alle API Management-lagen

Microservices zijn perfect voor het bouwen van API's. Met Azure Kubernetes Service (AKS) kunt u snel een architectuur op basis van microservices implementeren en gebruiken in de cloud. U kunt vervolgens gebruikmaken van Azure API Management (API Management) om uw microservices te publiceren als API's voor intern en extern verbruik. In dit artikel worden de opties beschreven voor het implementeren van API Management met AKS. Hierbij wordt uitgegaan van basiskennis van Kubernetes, API Management en Azure-netwerken.

Achtergrond

Wanneer u microservices publiceert als API's voor verbruik, kan het lastig zijn om de communicatie tussen de microservices en de clients die deze gebruiken te beheren. Er is een groot aantal kruislingse problemen, zoals verificatie, autorisatie, beperking, caching, transformatie en bewaking. Deze problemen zijn geldig, ongeacht of de microservices worden blootgesteld aan interne of externe clients.

Het API Gateway-patroon heeft betrekking op deze problemen. Een API-gateway fungeert als een voordeur voor de microservices, koppelt clients los van uw microservices, voegt een extra beveiligingslaag toe en vermindert de complexiteit van uw microservices door de last van het afhandelen van kruislingse problemen te verwijderen.

Azure API Management is een kant-en-klare oplossing om uw API-gatewaybehoeften op te lossen. U kunt snel een consistente en moderne gateway voor uw microservices maken en deze publiceren als API's. Als full-lifecycle API Management-oplossing biedt het ook aanvullende mogelijkheden, waaronder een selfservice-ontwikkelaarsportal voor API-detectie, API-levenscyclusbeheer en API-analyses.

Wanneer AKS en API Management samen worden gebruikt, bieden ze een platform voor het implementeren, publiceren, beveiligen, bewaken en beheren van op microservices gebaseerde API's. In dit artikel doorlopen we een aantal opties voor het implementeren van AKS in combinatie met API Management.

Kubernetes Services en API's

In een Kubernetes-cluster worden containers geïmplementeerd in Pods, die kortstondig zijn en een levenscyclus hebben. Wanneer een werkrolknooppunt sterft, gaan de pods die op het knooppunt worden uitgevoerd verloren. Daarom kan het IP-adres van een pod op elk gewenst moment worden gewijzigd. We kunnen er niet op vertrouwen om met de pod te communiceren.

Om dit probleem op te lossen heeft Kubernetes het concept services geïntroduceerd. Een Kubernetes Service is een abstractielaag die een logische groep pods definieert en blootstelling van extern verkeer, taakverdeling en servicedetectie voor deze pods mogelijk maakt.

Wanneer we klaar zijn om onze microservices als API's te publiceren via API Management, moeten we nadenken over het toewijzen van onze Services in Kubernetes aan API's in API Management. Er zijn geen regels ingesteld. Het hangt af van hoe u uw bedrijfsmogelijkheden of -domeinen hebt ontworpen en gepartitioneerd in microservices aan het begin. Als de pods achter een service bijvoorbeeld verantwoordelijk zijn voor alle bewerkingen op een bepaalde resource (bijvoorbeeld klant), kan de service worden toegewezen aan één API. Als bewerkingen op een resource worden gepartitioneerd in meerdere microservices (bijvoorbeeld GetOrder, PlaceOrder), kunnen meerdere services logisch worden samengevoegd in één API in API Management (zie Fig. 1).

De toewijzingen kunnen zich ook ontwikkelen. Omdat API Management een gevel voor de microservices maakt, kunnen we onze microservices in de loop van de tijd herstructureren en de juiste grootte geven.

API Management implementeren vóór AKS

Er zijn enkele opties voor het implementeren van API Management vóór een AKS-cluster.

Hoewel een AKS-cluster altijd wordt geïmplementeerd in een virtueel netwerk (VNet), hoeft een API Management-exemplaar niet te worden geïmplementeerd in een VNet. Wanneer API Management zich niet in het VNet van het cluster bevindt, moet het AKS-cluster openbare eindpunten publiceren waarmee API Management verbinding kan maken. In dat geval moet de verbinding tussen API Management en AKS worden beveiligd. Met andere woorden, we moeten ervoor zorgen dat het cluster alleen toegankelijk is via API Management. Laten we de opties doorlopen.

Optie 1: Services openbaar beschikbaar maken

Services in een AKS-cluster kunnen openbaar worden weergegeven met behulp van servicetypen NodePort, LoadBalancer of ExternalName. In dit geval zijn services rechtstreeks toegankelijk vanaf openbaar internet. Nadat API Management vóór het cluster is geïmplementeerd, moeten we ervoor zorgen dat al het binnenkomende verkeer via API Management verloopt door verificatie toe te passen in de microservices. API Management kan bijvoorbeeld een toegangstoken bevatten in elke aanvraag die is ingediend bij het cluster. Elke microservice is verantwoordelijk voor het valideren van het token voordat de aanvraag wordt verwerkt.

Dit kan de eenvoudigste optie zijn om API Management vóór AKS te implementeren, met name als u al verificatielogica hebt geïmplementeerd in uw microservices.

Voordelen:

• Eenvoudige configuratie aan de kant van API Management omdat deze niet hoeft te worden geïnjecteerd in het cluster-VNet
• Er is geen wijziging aan de AKS-zijde als services al openbaar worden weergegeven en verificatielogica al bestaat in microservices

Nadelen:

• Mogelijk beveiligingsrisico vanwege openbare zichtbaarheid van eindpunten
• Geen enkel toegangspunt voor inkomend clusterverkeer
• Maakt microservices ingewikkeld met dubbele verificatielogica

Optie 2: Een ingangscontroller installeren

Hoewel optie 1 gemakkelijker kan zijn, heeft het belangrijke nadelen zoals hierboven vermeld. Als een API Management-exemplaar zich niet in het cluster-VNet bevindt, is wederzijdse TLS-verificatie (mTLS) een robuuste manier om ervoor te zorgen dat het verkeer veilig en vertrouwd is in beide richtingen tussen een API Management-exemplaar en een AKS-cluster.

Wederzijdse TLS-verificatie wordt systeemeigen ondersteund door API Management en kan worden ingeschakeld in Kubernetes door een ingangscontroller (afb. 3) te installeren. Als gevolg hiervan wordt verificatie uitgevoerd in de ingangscontroller, waardoor de microservices worden vereenvoudigd. Daarnaast kunt u de IP-adressen van API Management toevoegen aan de lijst met toegestane toegang door inkomend verkeer om ervoor te zorgen dat alleen API Management toegang heeft tot het cluster. Als API Management Premium-laag of Standard V2-laag wordt gebruikt, kan isolatie op netwerkniveau worden bereikt.

Voordelen:

• Eenvoudige configuratie aan de kant van API Management omdat deze niet hoeft te worden geïnjecteerd in het cluster-VNet en mTLS systeemeigen wordt ondersteund
• Centraliseert de beveiliging voor inkomend clusterverkeer op de laag Inkomend verkeer van inkomend verkeer
• Vermindert het beveiligingsrisico door openbaar zichtbare clustereindpunten te minimaliseren

Nadelen:

• Verhoogt de complexiteit van de clusterconfiguratie vanwege extra werk om de ingangscontroller te installeren, configureren en onderhouden en certificaten te beheren die worden gebruikt voor mTLS
• Beveiligingsrisico's vanwege openbare zichtbaarheid van eindpunten van toegangsbeheercontroller, tenzij API Management Standard v2 of Premium-laag wordt gebruikt.

Wanneer u API's publiceert via API Management, is het eenvoudig en gebruikelijk om toegang tot deze API's te beveiligen met behulp van abonnementssleutels. Ontwikkelaars die de gepubliceerde API's moeten gebruiken, moeten een geldige abonnementssleutel in HTTP-aanvragen opnemen wanneer ze deze API's aanroepen. Anders worden de aanroepen onmiddellijk geweigerd door de API Management-gateway. Ze worden niet doorgestuurd naar de back-endservices.

Als u een abonnementssleutel wilt ophalen voor toegang tot API's, is een abonnement vereist. Een abonnement is in feite een benoemde container voor een paar abonnementssleutels. Ontwikkelaars die de gepubliceerde API's moeten gebruiken, kunnen abonnementen krijgen. En ze hebben geen goedkeuring nodig van API-uitgevers. API-uitgevers kunnen ook rechtstreeks abonnementen maken voor API-consumenten.

Optie 3: APIM implementeren in het cluster-VNet

In sommige gevallen kunnen klanten met wettelijke beperkingen of strikte beveiligingsvereisten optie 1 en 2 niet-bruikbare oplossingen vinden vanwege openbaar blootgestelde eindpunten. In andere omgevingen bevinden het AKS-cluster en de toepassingen die gebruikmaken van de microservices zich mogelijk binnen hetzelfde VNet. Er is dus geen reden om het cluster openbaar beschikbaar te maken, omdat alle API-verkeer binnen het VNet blijft. Voor deze scenario's kunt u API Management implementeren in het cluster-VNet. API Management Developer- en Premium-lagen ondersteunen VNet-implementatie.

Er zijn twee modi voor het implementeren van API Management in een VNet : extern en intern.

Als API-gebruikers zich niet in het cluster-VNet bevinden, moet de externe modus (fig. 4) worden gebruikt. In deze modus wordt de API Management-gateway in het cluster-VNet geïnjecteerd, maar toegankelijk via openbaar internet via een externe load balancer. Het helpt om het cluster volledig te verbergen terwijl externe clients de microservices nog steeds kunnen gebruiken. Daarnaast kunt u azure-netwerkmogelijkheden zoals netwerkbeveiligingsgroepen (NSG) gebruiken om netwerkverkeer te beperken.

Als alle API-consumenten zich in het cluster-VNet bevinden, kan de interne modus (fig. 5) worden gebruikt. In deze modus wordt de API Management-gateway in het cluster-VNET geïnjecteerd en alleen toegankelijk vanuit dit VNet via een interne load balancer. Er is geen manier om de API Management-gateway of het AKS-cluster te bereiken vanaf openbaar internet.

In beide gevallen is het AKS-cluster niet openbaar zichtbaar. In vergelijking met optie 2 is de ingangscontroller mogelijk niet nodig. Afhankelijk van uw scenario en configuratie is verificatie mogelijk nog steeds vereist tussen API Management en uw microservices. Als er bijvoorbeeld een Service Mesh wordt gebruikt, is er altijd wederzijdse TLS-verificatie vereist.

Voordelen:

• De veiligste optie omdat het AKS-cluster geen openbaar eindpunt heeft
• Vereenvoudigt de clusterconfiguratie omdat het geen openbaar eindpunt heeft
• De mogelijkheid om zowel API Management als AKS in het VNet te verbergen met behulp van de interne modus
• Mogelijkheid om netwerkverkeer te beheren met behulp van Azure-netwerkmogelijkheden, zoals netwerkbeveiligingsgroepen (NSG)

Nadelen:

• Verhoogt de complexiteit van het implementeren en configureren van API Management om binnen het VNet te werken

Volgende stappen

• Meer informatie over netwerkconcepten voor toepassingen in AKS
• Meer informatie over het gebruik van API Management met virtuele netwerken