Overzicht van zelf-hostende gateway

De zelf-hostende gateway is een optionele, in een container geplaatste versie 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 waarin u uw API's host. Gebruik de zelf-hostende gateway om de API-verkeersstroom te verbeteren en de vereisten voor API-beveiliging en -naleving aan te pakken.

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 belicht.

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

Beschikbaarheid

Belangrijk

Deze functie is beschikbaar in de premium- en ontwikkelaarslagen van API Management.

Api-beheer voor hybride en meerdere clouds

De zelf-hostende gatewayfunctie breidt API Management ondersteuning uit voor hybride omgevingen en omgevingen met meerdere clouds en stelt organisaties in staat om api's die on-premises en in clouds worden gehost, efficiënt 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 waarin 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 krijgen voor alle interne en externe API's.

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

• Beheervlak, beschikbaar gemaakt als een API, die wordt gebruikt om de service te configureren via de 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 effen 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 gaat ten koste van verhoogde latentie, nalevingsproblemen en in sommige gevallen extra kosten voor gegevensoverdracht.

Door zelf-hostende gateways te implementeren in dezelfde omgevingen waarin de implementaties van de back-end-API's worden gehost, kan API-verkeer rechtstreeks naar de back-end-API's stromen, wat de latentie vermindert, de kosten voor gegevensoverdracht optimaliseert en naleving mogelijk maakt met behoud van de voordelen van één beheerpunt, waarneembaarheid en detectie van alle API's binnen de organisatie, ongeacht waar de implementaties worden gehost.

Verpakking

De zelf-hostende gateway is beschikbaar als een Docker-containerinstallatiekopie op basis van Linux vanuit de Microsoft-artefactregister. Het kan worden geïmplementeerd in Docker, Kubernetes of een andere oplossing voor containerindeling die wordt uitgevoerd op een servercluster on-premises, een cloudinfrastructuur of voor evaluatie- en ontwikkelingsdoeleinden op een pc. U kunt de zelf-hostende gateway ook als clusterextensie implementeren in een Kubernetes-cluster met Azure Arc.

Containerinstallatiekopieën

We bieden verschillende containerinstallatiekopieën voor zelf-hostende gateways om aan uw behoeften te voldoen:

Labelconventie	Aanbeveling	Voorbeeld	Doorlopende tag	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 meest recente voorbeeldcontainerinstallatiekopieën wilt uitvoeren.	v2-preview	✔️	❌
latest	Gebruik deze tag als u de zelf-hostende gateway wilt evalueren.	latest	✔️	❌
beta1	Gebruik deze tag als u preview-versies van de zelf-hostende gateway wilt evalueren.	beta	✔️	❌

U vindt hier een volledige lijst met beschikbare tags.

¹ Preview-versies worden niet officieel ondersteund en zijn alleen voor experimentele doeleinden.

Gebruik van tags in onze officiële implementatieopties

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

Notitie

We bieden de opdracht en YAML-fragmenten als referentie. Gebruik desgewenst een specifiekere tag.

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

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

Risico van het gebruik van rolling tags

Rolling tags zijn tags die mogelijk worden bijgewerkt wanneer een nieuwe versie van de containerinstallatiekopieën worden vrijgegeven. Hierdoor kunnen containergebruikers updates voor de containerinstallatiekopieën ontvangen zonder dat ze hun implementaties hoeven bij te werken.

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

Voorbeeld: v2 de tag is vrijgegeven met 2.0.0 de containerinstallatiekopieën, maar wanneer 2.1.0 deze wordt vrijgegeven, wordt de v2 tag gekoppeld aan de 2.1.0 installatiekopieën.

Belangrijk

Overweeg het gebruik van een specifieke versietag in productie om onbedoelde upgrade naar een nieuwere versie te voorkomen.

Connectiviteit met Azure

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

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

Belangrijk

Ondersteuning voor containerinstallatiekopieën voor Azure API Management zelf-hostende gateway versie 0 en versie 1 eindigt op 1 oktober 2023, samen met de bijbehorende configuratie-API v1. Gebruik onze migratiehandleiding voor het gebruik van zelf-hostende gateway v2.0.0 of hoger met configuratie-API v2. Meer informatie in onze documentatie over afschaffing

FQDN-afhankelijkheden

Voor een goede werking moet elke zelf-hostende gateway uitgaande connectiviteit hebben op poort 443 naar de volgende eindpunten die zijn gekoppeld aan het cloudgebaseerde API Management-exemplaar:

Description	Vereist voor v1	Vereist voor v2	Notities
Hostnaam van het configuratie-eindpunt	<apim-service-name>.management.azure-api.net	<apim-service-name>.configuration.azure-api.net	Voor connectiviteit met v2-eindpunt is DNS-omzetting van de standaardhostnaam vereist. Op dit moment maakt API Management het configureren van een aangepaste domeinnaam voor het v2-eindpunt1 niet mogelijk.
Openbaar IP-adres van het API Management-exemplaar	✔️	✔️	IP-adressen van de primaire locatie zijn voldoende.
Openbare IP-adressen van Azure Storage-servicetag	✔️	Optioneel2	IP-adressen moeten overeenkomen met de primaire locatie van API Management exemplaar.
Hostnaam van Azure Blob Storage-account	✔️	Optioneel2	Account dat is gekoppeld aan het exemplaar (<blob-storage-account-name>.blob.core.windows.net)
Hostnaam van Azure Table Storage-account	✔️	Optioneel2	Account dat is gekoppeld aan het exemplaar (<table-storage-account-name>.table.core.windows.net)
Eindpunten voor Azure-toepassing Insights-integratie	Optioneel3	Optioneel3	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	Optioneel3	Optioneel3	Meer informatie in Azure Event Hubs documenten
Eindpunten voor integratie van externe cache	Optioneel3	Optioneel3	Deze vereiste is afhankelijk van de externe cache die wordt gebruikt

¹ Voor een API Management exemplaar in een intern virtueel netwerk schakelt u privéconnectiviteit in met het v2-configuratie-eindpunt vanaf de locatie van de zelf-hostende gateway, bijvoorbeeld met behulp van een privé-DNS in een peernetwerk.
² Alleen vereist in v2 wanneer API-inspector of -quota worden gebruikt in beleid.
³ 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 de gekoppelde opslagaccounts worden weergegeven op de pagina Status van netwerkconnectiviteit van de service in de Azure Portal.
• Openbare IP-adressen die onder de gekoppelde opslagaccounts liggen, zijn dynamisch en kunnen zonder kennisgeving worden gewijzigd.

Verbindingsfouten

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

De zelf-hostende gateway is ontworpen om statisch te mislukken 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 van de laatst gedownloade configuratie op een permanent volume op dat is gekoppeld aan hun container of pod.

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

• Het uitvoeren van zelf-hostende gateways blijft werken met behulp van een in-memory kopie van de configuratie
• Gestopte zelf-hostende gateways kunnen niet worden gestart

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

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

Wanneer de connectiviteit is hersteld, wordt elke zelf-hostende gateway die wordt beïnvloed door de storing, automatisch opnieuw verbinding gemaakt met de bijbehorende API Management service en worden alle configuratie-updates gedownload die zijn opgetreden terwijl de gateway 'offline' was.

Beveiliging

Beperkingen

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

• TLS-sessie hervatten.
• Opnieuw onderhandelen over clientcertificaten. Als u clientcertificaatverificatie 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 zelf-hostende gateway aangepaste hostnaam (domeinnaam).

Transport Layer Security (TLS)

Belangrijk

Dit overzicht is alleen van toepassing op de zelf-hostende gateway v1 & v2.

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

Belangrijk

Dit overzicht is alleen van toepassing op de zelf-hostende gateway v2.

De zelf-hostende gateway gebruikt de volgende coderingssuites voor zowel client- als 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.

Volgende stappen

• Meer informatie over de verschillende gateways vindt u in ons overzicht van API-gateways
• Meer informatie over API Management in een hybride en multicloudwereld
• Meer informatie over richtlijnen voor het uitvoeren van de zelf-hostende gateway op Kubernetes in productie
• Zelf-hostende gateway implementeren in Docker
• Zelf-hostende gateway implementeren in Kubernetes
• Zelf-hostende gateway implementeren in Kubernetes-cluster met Azure Arc
• Configuratie-instellingen voor zelf-hostende gateway
• Meer informatie over waarneembaarheidsmogelijkheden in API Management
• Meer informatie over Dapr-integratie met de zelf-hostende gateway