Delen via

Overzicht van zelf-hostende gateway

  • Artikel

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.

Hybride en multicloud API-beheer

De zelf-hostende gatewayfunctie breidt API Management-ondersteuning voor hybride en multicloud-omgevingen uit 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 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, weergegeven als een API, dat wordt gebruikt om de service te configureren via de Azure-portal, PowerShell en andere ondersteunde mechanismen
  • Gateway (of gegevensvlak), die verantwoordelijk is voor het proxy'en van API-aanvragen, het toepassen van beleid en het verzamelen van telemetriegegevens
  • Ontwikkelaarsportal, die door ontwikkelaars wordt gebruikt voor het ontdekken, leren en onboarden voor gebruik 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 zelf-hostende gateways

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 compliance mogelijk maakt, met behoud van de voordelen van één beheerpunt, waarneembaarheid en ontdekking van alle API's binnen de organisatie, ongeacht waar de implementaties worden gehost.

API-verkeersstroom met zelf-hostende gateways

Verpakking

De zelf-hostende gateway is beschikbaar als een Linux-gebaseerde Docker-containerinstallatiekopie uit het Microsoft-artefactregister. Deze kan worden geïmplementeerd naar Docker, Kubernetes of een andere oplossing voor containerindeling die wordt uitgevoerd op een on-premises servercluster, in 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.

Containerinstallatiekopieën

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

Tagconventie Aanbeveling Opmerking Rolling 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 nieuwste preview-containerinstallatiekopieë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 ✔️ ❌

Hier vindt u een volledige lijst met beschikbare tags.

1Preview-versies worden niet officieel ondersteund en zijn alleen voor experimentele doeleinden. Zie het zelf-hostende gatewayondersteuningsbeleid.

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.

Notitie

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

Bij de installatie 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 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 bijgewerkt wanneer er een nieuwe versie van de containerinstallatiekopieën 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 is v2 vrijgegeven met 2.0.0 containerinstallatiekopieën, maar wanneer 2.1.0 deze wordt vrijgegeven, wordt de v2 tag gekoppeld aan de 2.1.0 installatiekopieën.

Belangrijk

Overweeg om een specifieke versietag in productie te gebruiken 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 zijn gekoppeld aan één API Management-service en wordt geconfigureerd via het beheervlak. Een zelf-hostende gateway maakt gebruik van connectiviteit met Azure om:

  • De status te rapporteren door elke minuut heartbeat-berichten te verzenden
  • Regelmatig (elke 10 seconden) te controleren op configuratie-updates en deze toe te passen wanneer ze beschikbaar zijn
  • Metrische gegevens te verzenden naar Azure Monitor, indien geconfigureerd om dit te doen
  • Gebeurtenissen te verzenden naar Application Insights, indien ingesteld 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:

Beschrijving Vereist voor v1 Vereist voor v2 Opmerkingen
Hostnaam van het configuratie-eindpunt <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net1 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 dat is gekoppeld aan exemplaar (<blob-storage-account-name>.blob.core.windows.net)
Hostnaam van Azure Table Storage-account ✔️ Optioneel2 Account dat is gekoppeld aan exemplaar (<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-toepassing Insights-integratie Optioneel5 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 Optioneel5 Meer informatie in Azure Event Hubs-documenten
Eindpunten voor integratie van externe cache Optioneel5 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 beleid.
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-verificatie 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 ongeldig alle toegangstokens die ermee zijn gemaakt

Verbindingsfouten

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

De zelf-hostende gateway is ontworpen om statisch te mislukken en kan tijdelijke 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 zelf-hostende gateways kunnen niet worden gestart

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, 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 plaatsvonden terwijl de gateway 'offline' was.

Beveiliging

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.

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

Volgende stappen