Overzicht van zelfgehoste gateway

2025-10-30

VAN TOEPASSING OP: Ontwikkelaar | Premie

Zelfgehoste gateway is een optionele versie in containers van de standaard beheerde gateway die is opgenomen in elk API Management-exemplaar. 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. Ook wordt de architectuur op hoog niveau van de functie gepresenteerd en worden de mogelijkheden ervan beschreven.

Zie API-gateway in API Management voor een overzicht van de verschillen tussen beheerde en zelf-hostende gateways.

Het API-beheer voor hybride en multicloud

De zelf-hostende gatewayfunctie breidt API Management-ondersteuning uit voor hybride en multicloudomgevingen en stelt u in staat om API's die on-premises worden gehost en vanuit één API Management-exemplaar in Azure efficiënt en veilig te beheren.

Met zelf-hostende gateway hebt u de flexibiliteit om een containerversie van het API Management-gatewayonderdeel te implementeren in dezelfde omgevingen waar u uw API's host. Alle zelf-hostende gateways worden beheerd vanuit het API Management-exemplaar waarmee ze zijn gefedereerd, zodat u de zichtbaarheid en uniforme beheerervaring krijgt voor alle interne en externe API's.

Elk API Management-exemplaar bestaat uit de volgende belangrijke onderdelen:

Een beheervlak, beschikbaar gemaakt als EEN API, die wordt gebruikt om de service te configureren via Azure Portal, PowerShell en andere ondersteunde technologieën
Een gateway (of gegevensvlak), die verantwoordelijk is voor het proxyen van API-aanvragen, het toepassen van beleid en het verzamelen van telemetriegegevens
Een 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 in 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.

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 naleving wordt ingeschakeld, terwijl het voordeel blijft van één beheerpunt, waarneembaarheid en detectie voor alle API's in de organisatie, ongeacht waar hun implementaties worden gehost.

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, 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

Er zijn verschillende containerinstallatiekopieën beschikbaar voor zelf-hostende gateways:

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 de nieuwste preview-containerimage wilt gebruiken.	`v2-preview`	✔️	❌
`latest`	Gebruik deze tag als u de zelf-hostende gateway wilt evalueren.	`latest`	✔️	❌
`beta` ¹	Gebruik deze tag als u preview-versies van de zelf-hostende gateway wilt evalueren.	`beta`	✔️	❌

Hier vindt u een volledige lijst met beschikbare tags.

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

Gebruik van tags in officiële implementatieopties

Implementatieopties in Azure Portal gebruiken de v2 tag waarmee u de meest recente versie van de zelf-hostende gateway v2-containerinstallatiekopie kunt gebruiken met alle functie-updates en patches.

Opmerking

De opdracht en YAML-fragmenten worden geleverd als referentie. U kunt desgewenst een specifiekere tag gebruiken.

Wanneer u een gateway met een Helm-grafiek installeert, is het taggen van afbeeldingen geoptimaliseerd. De toepassingsversie van de Helm-grafiek maakt de gateway vast aan een bepaalde versie en is niet afhankelijk van latest.

Zie Een zelf-hostende gateway voor API Management installeren in Kubernetes met Helm voor meer informatie.

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. Met dit type tags kunnen containergebruikers updates ontvangen voor de containerinstallatiekopie zonder dat ze hun implementaties hoeven bij te werken.

Wanneer u dit type tag gebruikt, kunt u mogelijk verschillende versies parallel uitvoeren zonder dit te zien, bijvoorbeeld wanneer u schaalacties uitvoert nadat de v2 tag is bijgewerkt.

Voorbeeld: De v2 tag wordt vrijgegeven samen met de 2.0.0 containerimage. Wanneer 2.1.0 wordt vrijgegeven, wordt de v2 tag gekoppeld aan de 2.1.0 afbeelding.

Belangrijk

Overweeg om een specifieke versietag in productie te gebruiken om onbedoelde upgrades 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 zelfgehoste gateway moet zich verbinden met één API Management-exemplaar en wordt geconfigureerd via het configuratiepaneel. Een zelf-hostende gateway maakt gebruik van connectiviteit met Azure voor:

Rapporteert de status door elke minuut heartbeat-berichten te verzenden.
Controleer regelmatig (elke 10 seconden) op configuratie-updates wanneer deze beschikbaar zijn.
Het verzenden van metrische gegevens naar Azure Monitor, indien geconfigureerd om dit te doen.
Gebeurtenissen verzenden naar Application Insights, indien geconfigureerd om dit te doen.

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	`<api-management-service-name>.configuration.azure-api.net` ¹	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 de Azure Storage-servicetag	Optioneel²	IP-adressen moeten overeenkomen met de primaire locatie van het API Management-exemplaar.
Hostnaam van het Azure Blob Storage-account	Optioneel²	Het account dat is gekoppeld aan de instantie (`<blob-storage-account-name>.blob.core.windows.net`).
Hostnaam van het Azure Table Storage-account	Optioneel²	Het account dat is gekoppeld aan het exemplaar (`<table-storage-account-name>.table.core.windows.net`).
Eindpunten voor Azure Resource Manager	Optioneel³	Het vereiste eindpunt is `management.azure.com`.
Eindpunten voor Microsoft Entra-integratie	Optioneel⁴	Vereiste eindpunten zijn `<region>.login.microsoft.com` en `login.microsoftonline.com`.
Eindpunten voor Azure Application Insights-integratie	Optioneel⁵	Minimaal vereiste eindpunten zijn `rt.services.visualstudio.com:443`, `dc.services.visualstudio.com:443`en `{region}.livediagnostics.monitor.azure.com:443`. Zie de Documentatie van Azure Monitor voor meer informatie.
Eindpunten voor Event Hubs-integratie	Optioneel⁵	Zie de documentatie van Azure Event Hubs voor meer informatie.
Eindpunten voor integratie van externe cache	Optioneel⁵	Deze vereiste is afhankelijk van de externe cache die wordt gebruikt.

¹Zie Connectiviteit in een intern virtueel netwerk voor informatie over een API Management-exemplaar in een intern virtueel netwerk.
²Alleen vereist in v2 wanneer API-inspector of -quota worden gebruikt in beleidsregels.
³Alleen vereist bij het gebruik van Microsoft Entra-verificatie om RBAC-machtigingen te verifiëren.
⁴Alleen vereist wanneer u Microsoft Entra-verificatie of -beleidsregels gebruikt die betrekking hebben op Microsoft Entra.
⁵Alleen 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 weergegeven 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 een 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 met behulp van Azure Application Gateway.

Verificatieopties

De configuratie-instellingen van de gatewaycontainer bieden de volgende opties voor het verifiëren van de verbinding tussen de zelf-hostende gateway en het configuratie-eindpunt van het api Management-exemplaar in de cloud.

Optie	Overwegingen
Microsoft Entra-authenticatie	Configureer een of meer Microsoft Entra-apps voor toegang tot de gateway. Beheer de toegang afzonderlijk per app. Configureer langere verlooptijden voor geheimen in overeenstemming met het beleid van uw organisatie. Gebruik standaardprocedures van Microsoft Entra om gebruikers- of groepsmachtigingen toe te wijzen of in te trekken voor apps en om geheimen te roteren.
Toegangstoken voor gateway. (Ook wel een verificatiesleutel genoemd.)	Token verloopt minstens elke 30 dagen en moet in de containers vernieuwd worden. Ondersteund door een gatewaysleutel die onafhankelijk kan worden gedraaid (bijvoorbeeld om de toegang in te trekken). Door de gatewaysleutel opnieuw te genereren, worden 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 in-memory kopie van de configuratie.
Gestopte zelfgehoste gateways zullen niet kunnen starten.

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

Zelfgehoste gateways blijven functioneren door gebruik te maken van een in-memory kopie van de configuratie.
Gestopte zelfgehoste gateways kunnen starten door gebruik te maken van een back-up-kopie van de configuratie.

Wanneer de connectiviteit wordt hersteld, maakt elke zelfgehoste gateway die door de storing is beïnvloed automatisch opnieuw verbinding met de bijbehorende API-beheerinstantie en downloadt het alle configuratie-updates die zich voordeden terwijl de gateway offline was.

Veiligheid

Beperkingen

De volgende functionaliteit die beschikbaar is in beheerde gateways , is niet beschikbaar in 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

Zelf-hostende gateways ondersteunen standaard TLS v1.2.

Als u aangepaste domeinen gebruikt, kunt u TLS v1.0 en/of v1.1 inschakelen in het besturingsvlak.

Beschikbare coderingssuites

Zelf-hostende gateways maken 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

Met 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 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 voor de TLS-verbinding tussen de zelf-hostende gateway en de back-end.

Feedback

Is deze pagina nuttig?