Delen via

Overzicht van zelfgehoste gateway

VAN TOEPASSING OP: Ontwikkelaar | Premie

De zelf-hostende gateway is een optionele, containerversie van de standaard beheerde gateway die is opgenomen in elke API Management-service. Het is handig voor scenario's zoals het plaatsen van gateways in dezelfde omgevingen waar u uw API's host. Gebruik de zelf-hostende gateway om de API-verkeersstroom te verbeteren en te voldoen aan de vereisten voor API-beveiliging en -naleving.

In dit artikel wordt uitgelegd hoe de zelf-hostende gatewayfunctie van Azure API Management hybride en multicloud-API-beheer mogelijk maakt, de architectuur op hoog niveau presenteert en de mogelijkheden ervan markeert.

Zie API-gateway in API Management voor een overzicht van de functies in de verschillende gatewayaanbiedingen.

Het API-beheer voor hybride en multicloud

De zelf-hostende gatewayfunctie breidt API Management-ondersteuning uit voor hybride en multicloud-omgevingen en stelt organisaties in staat om API's die on-premises worden gehost en veilig te beheren vanuit één API Management-service in Azure.

Met de zelf-hostende gateway hebben klanten de flexibiliteit om een containerversie van het API Management-gatewayonderdeel te implementeren in dezelfde omgevingen waar ze hun API's hosten. Alle zelf-hostende gateways worden beheerd vanuit de API Management-service waarmee ze zijn gefedereerd, waardoor klanten de zichtbaarheid en uniforme beheerervaring hebben voor alle interne en externe API's.

Elke API Management-service bestaat uit de volgende belangrijke onderdelen:

  • Beheervlak, beschikbaar gemaakt als API, die wordt gebruikt om de service te configureren via Azure Portal, PowerShell en andere ondersteunde mechanismen.
  • Gateway (of gegevensvlak), die verantwoordelijk is voor het proxyen van API-aanvragen, het toepassen van beleid en het verzamelen van telemetriegegevens
  • Ontwikkelaarsportal die door ontwikkelaars wordt gebruikt voor het detecteren, leren en onboarden van de API's

Standaard worden al deze onderdelen geïmplementeerd in Azure, waardoor al het API-verkeer (weergegeven als ononderbroken zwarte pijlen op de volgende afbeelding) door Azure stroomt, ongeacht waar back-ends die de API's implementeren, worden gehost. De operationele eenvoud van dit model komt ten koste van verhoogde latentie, nalevingsproblemen en in sommige gevallen extra kosten voor gegevensoverdracht.

API-verkeersstroom zonder zelfgehoste gateways

Door zelf-hostende gateways te implementeren in dezelfde omgevingen waar de back-end-API-implementaties worden gehost, kan API-verkeer rechtstreeks naar de back-end-API's stromen, waardoor latentie wordt verminderd, de kosten voor gegevensoverdracht worden geoptimaliseerd en de naleving wordt ingeschakeld en tegelijkertijd de voordelen behouden van één beheerpunt, waarneembaarheid en detectie van alle API's binnen de organisatie, ongeacht waar hun implementaties worden gehost.

API-verkeersstroom met zelf-hostende gateways

Verpakking

De zelfgehoste gateway is beschikbaar als een Linux-gebaseerde Docker-containerimage vanuit het Microsoft Artifact Registry. Het kan worden geïmplementeerd in Docker, Kubernetes of een andere containerindelingsoplossing die wordt uitgevoerd op een servercluster on-premises, in de cloudinfrastructuur of voor evaluatie- en ontwikkelingsdoeleinden, op een pc. U kunt de zelf-hostende gateway ook implementeren als clusterextensie naar een Kubernetes-cluster met Azure Arc.

Containerafbeeldingen

We bieden diverse containerafbeeldingen voor zelfgehoste gateways om aan uw behoeften te voldoen.

Tagconventie Aanbeveling Voorbeeld Rollend label Aanbevolen voor productie
{major}.{minor}.{patch} Gebruik deze tag om altijd dezelfde versie van de gateway uit te voeren 2.0.0 ❌ ✔️
v{major} Gebruik deze tag om altijd een primaire versie van de gateway uit te voeren met elke nieuwe functie en patch. v2 ✔️ ❌
v{major}-preview Gebruik deze tag als u altijd onze nieuwste preview-containerafbeelding wilt gebruiken. v2-preview ✔️ ❌
latest Gebruik deze tag als u de zelf-hostende gateway wilt evalueren. latest ✔️ ❌
beta 1 Gebruik deze tag als u preview-versies van de zelf-hostende gateway wilt evalueren. beta ✔️ ❌

Hier vindt u een volledige lijst met beschikbare tags.

1Preview-versies worden niet officieel ondersteund en zijn alleen voor experimentele doeleinden. Zie het zelfgehoste gateway ondersteuningsbeleid.

Gebruik van tags in onze officiële implementatieopties

Onze implementatieopties in Azure Portal gebruiken de v2 tag waarmee klanten de meest recente versie van de zelf-hostende gateway v2-containerinstallatiekopie kunnen gebruiken met alle functie-updates en patches.

Opmerking

We bieden de opdracht en YAML-fragmenten als referentie. U kunt desgewenst een specifiekere tag gebruiken.

Bij de installatie met onze Helm-chart is het taggen van afbeeldingen geoptimaliseerd voor jou. De toepassingsversie van de Helm-grafiek maakt de gateway vast aan een bepaalde versie en is niet afhankelijk van latest.

Meer informatie over het installeren van een zelf-hostende API Management-gateway in Kubernetes met Helm.

Risico van het gebruik van rolling tags

Rolling tags zijn tags die mogelijk worden geüpdatet wanneer er een nieuwe versie van de containerafbeelding wordt uitgebracht. Hierdoor kunnen containergebruikers updates ontvangen voor de containerinstallatiekopieën zonder dat ze hun implementaties hoeven bij te werken.

Dit betekent dat u mogelijk verschillende versies parallel kunt uitvoeren zonder deze te zien, bijvoorbeeld wanneer u schaalacties uitvoert zodra v2 de tag is bijgewerkt.

Voorbeeld: tag werd v2 vrijgegeven met 2.0.0 containerafbeelding, maar wanneer 2.1.0 wordt vrijgegeven, zal de v2 tag gekoppeld zijn aan de 2.1.0 afbeelding.

Belangrijk

Overweeg om een specifieke versietag in productie te gebruiken om onbedoelde upgrade naar een nieuwere versie te voorkomen.

Connectiviteit met Azure

Voor zelf-hostende gateways is uitgaande TCP/IP-connectiviteit met Azure vereist op poort 443. Elke zelf-hostende gateway moet worden gekoppeld aan één API Management-service en wordt geconfigureerd via het beheervlak. Een zelf-hostende gateway maakt gebruik van connectiviteit met Azure voor:

  • De status rapporteren door elke minuut heartbeat-berichten te verzenden
  • Controleer regelmatig op (elke 10 seconden) en pas configuratie-updates toe wanneer deze beschikbaar zijn
  • Metrische gegevens verzenden naar Azure Monitor, indien geconfigureerd om dit te doen
  • Gebeurtenissen verzenden naar Application Insights, indien ingesteld op

FQDN-afhankelijkheden

Om goed te kunnen werken, heeft elke zelf-hostende gateway uitgaande connectiviteit op poort 443 nodig voor de volgende eindpunten die zijn gekoppeld aan het cloudexemplaar van API Management:

Eindpunt Vereist? Opmerkingen
Hostnaam van het configuratie-eindpunt <apim-service-name>.configuration.azure-api.net 1 Aangepaste hostnamen worden ook ondersteund en kunnen worden gebruikt in plaats van de standaardhostnaam.
Openbaar IP-adres van het API Management-exemplaar ✔️ HET IP-adres van de primaire locatie is voldoende.
Openbare IP-adressen van Azure Storage-servicetag Optioneel2 IP-adressen moeten overeenkomen met de primaire locatie van het API Management-exemplaar.
Hostnaam van Azure Blob Storage-account Optioneel2 Account geassocieerd met instantie (<blob-storage-account-name>.blob.core.windows.net)
Hostnaam van Azure Table Storage-account Optioneel2 Account geassocieerd met instantie (<table-storage-account-name>.table.core.windows.net)
Eindpunten voor Azure Resource Manager Optioneel3 Vereiste eindpunten zijn management.azure.com.
Eindpunten voor Microsoft Entra-integratie Optioneel4 Vereiste eindpunten zijn <region>.login.microsoft.com en login.microsoftonline.com.
Eindpunten voor Azure Application Insights-integratie Optioneel5 Minimaal vereiste eindpunten zijn:
  • rt.services.visualstudio.com:443
  • dc.services.visualstudio.com:443
  • {region}.livediagnostics.monitor.azure.com:443
Meer informatie in Azure Monitor-documenten
Eindpunten voor Event Hubs-integratie Optioneel5 Meer informatie in Azure Event Hubs-documenten
Eindpunten voor integratie van externe cache Optioneel5 Deze vereiste is afhankelijk van de externe cache die wordt gebruikt

1Zie Connectiviteit in een intern virtueel netwerk voor een API Management-exemplaar in een intern virtueel netwerk.
2Alleen vereist in v2 wanneer API-inspector of -quota worden gebruikt in beleidsregels.
3Alleen vereist bij het gebruik van Microsoft Entra-verificatie om RBAC-machtigingen te verifiëren.
4Alleen vereist bij het gebruik van Microsoft Entra-verificatie of aan Microsoft Entra gerelateerd beleid.
5Alleen vereist wanneer de functie wordt gebruikt en openbare IP-adres-, poort- en hostnaamgegevens vereist.

Belangrijk

  • DNS-hostnamen moeten kunnen worden omgezet in IP-adressen en de bijbehorende IP-adressen moeten bereikbaar zijn.
  • De namen van het gekoppelde opslagaccount worden vermeld op de pagina Netwerkverbindingsstatus van de service in Azure Portal.
  • Openbare IP-adressen die onder de gekoppelde opslagaccounts liggen, zijn dynamisch en kunnen zonder voorafgaande kennisgeving worden gewijzigd.

Connectiviteit in intern virtueel netwerk

  • Privéconnectiviteit : als de zelf-hostende gateway wordt geïmplementeerd in een virtueel netwerk, schakelt u privéconnectiviteit met het v2-configuratie-eindpunt in vanaf de locatie van de zelf-hostende gateway, bijvoorbeeld met behulp van een privé-DNS in een gekoppeld netwerk.

  • Internetverbinding : als de zelf-hostende gateway via internet verbinding moet maken met het v2-configuratie-eindpunt, configureert u een aangepaste hostnaam voor het configuratie-eindpunt en maakt u het eindpunt beschikbaar via Application Gateway.

Verificatieopties

Als u de verbinding tussen de zelf-hostende gateway en het configuratie-eindpunt van het cloud-API Management-exemplaar wilt verifiëren, hebt u de volgende opties in de configuratie-instellingen van de gatewaycontainer.

Optie Overwegingen
Microsoft Entra-authenticatie Een of meer Microsoft Entra-apps configureren voor toegang tot de gateway

Toegang afzonderlijk beheren per app

Langere verlooptijden configureren voor geheimen in overeenstemming met het beleid van uw organisatie

Standaardprocedures van Microsoft Entra gebruiken om gebruikers- of groepsmachtigingen toe te wijzen of in te trekken voor apps en om geheimen te roteren
Gatewaytoegangstoken (ook wel verificatiesleutel genoemd) Token verloopt elke 30 dagen maximaal en moet worden vernieuwd in de containers

Ondersteund door een gatewaysleutel die onafhankelijk kan worden gedraaid (bijvoorbeeld om de toegang in te trekken)

Het opnieuw genereren van de gatewaysleutel maakt alle toegangstokens die ermee zijn gemaakt ongeldig.

Aanbeveling

Zie Azure API Management als een Event Grid-bron voor informatie over Event Grid-gebeurtenissen die worden gegenereerd door een zelf-hostende gateway wanneer een gatewaytoegangstoken bijna is verlopen of is verlopen. Gebruik deze gebeurtenissen om ervoor te zorgen dat geïmplementeerde gateways altijd kunnen worden geverifieerd met hun bijbehorende API Management-exemplaar.

Connectiviteitsfouten

Wanneer de verbinding met Azure is verbroken, kan de zelf-hostende gateway geen configuratie-updates ontvangen, de status rapporteren of telemetrie uploaden.

De zelfgehoste gateway is ontworpen om in een statische toestand te falen en kan tijdelijk verlies van connectiviteit met Azure overleven. Het kan worden geïmplementeerd met of zonder lokale configuratieback-up. Met configuratieback-up slaan zelf-hostende gateways regelmatig een back-upkopie op van de meest recente gedownloade configuratie op een permanent volume dat is gekoppeld aan de container of pod.

Wanneer de configuratieback-up is uitgeschakeld en de verbinding met Azure wordt onderbroken:

  • Het uitvoeren van zelf-hostende gateways blijft functioneren met behulp van een kopie in het geheugen van de configuratie
  • Gestopte zelfgehoste gateways zullen niet kunnen starten

Wanneer de configuratieback-up is ingeschakeld en de verbinding met Azure wordt onderbroken:

  • Het uitvoeren van zelf-hostende gateways blijft functioneren met behulp van een kopie in het geheugen van de configuratie
  • Gestopte zelf-hostende gateways kunnen een back-upkopie van de configuratie gebruiken

Wanneer de verbinding wordt hersteld, zal elke zelfgehoste gateway die door de storing is beïnvloed automatisch opnieuw verbinding maken met de bijbehorende API Management-service en worden alle configuratie-updates gedownload die plaatsvonden terwijl de gateway offline was.

Veiligheid

Beperkingen

De volgende functionaliteit in de beheerde gateways is niet beschikbaar in de zelf-hostende gateways:

  • Hervatting van TLS-sessie.
  • Heronderhandeling van clientcertificaat. Als u verificatie van clientcertificaten wilt gebruiken, moeten API-gebruikers hun certificaten presenteren als onderdeel van de eerste TLS-handshake. Om dit gedrag te garanderen, schakelt u de instelling Negotiate Client Certificate in bij het configureren van een aangepaste hostnaam (domeinnaam) van een zelf-hostende gateway.

Transportlaagbeveiliging (TLS)

Ondersteunde protocollen

De zelf-hostende gateway biedt standaard ondersteuning voor TLS v1.2.

Klanten die aangepaste domeinen gebruiken, kunnen TLS v1.0 en/of v1.1 inschakelen in het besturingsvlak.

Beschikbare coderingssuites

De zelf-hostende gateway maakt gebruik van de volgende coderingssuites voor client- en serververbindingen:

  • 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

Coderingssuites beheren

Vanaf v2.1.1 en hoger kunt u de coderingen beheren die worden gebruikt via de configuratie:

  • net.server.tls.ciphers.allowed-suites hiermee kunt u een door komma's gescheiden lijst met coderingen definiëren die moeten worden gebruikt voor de TLS-verbinding tussen de API-client en de zelf-hostende gateway.
  • net.client.tls.ciphers.allowed-suites hiermee kunt u een door komma's gescheiden lijst met coderingen definiëren die moeten worden gebruikt voor de TLS-verbinding tussen de zelf-hostende gateway en de back-end.

Verwante inhoud