Översikt över gateway med egen värd

  • Artikel

GÄLLER FÖR: Utvecklare | Premium

Den lokalt installerade gatewayen är en valfri, containerbaserad version av den hanterade standardgatewayen som ingår i varje API Management-tjänst. Det är användbart för scenarier som att placera gatewayer i samma miljöer där du är värd för dina API:er. Använd den lokalt installerade gatewayen för att förbättra API-trafikflödet och hantera KRAV för API-säkerhet och efterlevnad.

Den här artikeln beskriver hur funktionen för lokalt installerad gateway i Azure API Management möjliggör hantering av hybrid- och multimolns-API: er, presenterar dess arkitektur på hög nivå och visar dess funktioner.

En översikt över funktionerna i de olika gatewayerbjudandena finns i API Gateway i API Management.

Hantering av hybrid- och multimoln-API:et

Den lokalt installerade gatewayfunktionen utökar API Managements stöd för hybridmiljöer och miljöer med flera moln och gör det möjligt för organisationer att effektivt och säkert hantera API:er som finns lokalt och i moln från en enda API Management-tjänst i Azure.

Med den lokala gatewayen har kunderna flexibiliteten att distribuera en containerbaserad version av API Management-gatewaykomponenten till samma miljöer där de är värdar för sina API:er. Alla gatewayer med egen värd hanteras från API Management-tjänsten som de är federerade med, vilket ger kunderna insyn och enhetlig hantering för alla interna och externa API:er.

Varje API Management-tjänst består av följande viktiga komponenter:

  • Hanteringsplan, som exponeras som ett API, som används för att konfigurera tjänsten via Azure Portal, PowerShell och andra mekanismer som stöds.
  • Gateway (eller dataplan), som ansvarar för proxy-API-begäranden, och tillämpar principer och samlar in telemetri
  • Utvecklarportalen som används av utvecklare för att identifiera, lära sig och registrera sig för att använda API:erna

Som standard distribueras alla dessa komponenter i Azure, vilket gör att all API-trafik (visas som svarta pilar på följande bild) flödar genom Azure oavsett var serverdelar som implementerar API:erna finns. Den här modellens drifts enkelhet sker på bekostnad av ökad svarstid, efterlevnadsproblem och i vissa fall extra avgifter för dataöverföring.

API-trafikflöde utan gatewayer med egen värd

Genom att distribuera gatewayer med egen värd i samma miljöer där implementeringarna av serverdels-API:et finns kan API-trafik flöda direkt till serverdels-API:erna, vilket minskar svarstiden, optimerar dataöverföringskostnaderna och möjliggör efterlevnad samtidigt som fördelarna med att ha en enda hanteringsplats, observerbarhet och identifiering av alla API:er i organisationen, oavsett var implementeringarna finns.

API-trafikflöde med lokala gatewayer

Paketering

Den lokalt installerade gatewayen är tillgänglig som en Linux-baserad Docker-containeravbildning från Microsofts artefaktregister. Den kan distribueras till Docker, Kubernetes eller någon annan containerorkestreringslösning som körs på ett serverkluster lokalt, i molninfrastrukturen eller i utvärderings- och utvecklingssyfte på en privat dator. Du kan också distribuera den lokalt installerade gatewayen som ett klustertillägg till ett Azure Arc-aktiverat Kubernetes-kluster.

Containeravbildningar

Vi tillhandahåller en mängd olika containeravbildningar för gatewayer med egen värd för att uppfylla dina behov:

Taggkonvention Rekommendation Exempel Rullande tagg Rekommenderas för produktion
{major}.{minor}.{patch} Använd den här taggen för att alltid köra samma version av gatewayen 2.0.0 ❌ ✔️
v{major} Använd den här taggen för att alltid köra en huvudversion av gatewayen med varje ny funktion och korrigering. v2 ✔️ ❌
v{major}-preview Använd den här taggen om du alltid vill köra vår senaste förhandsgranskningscontaineravbildning. v2-preview ✔️ ❌
latest Använd den här taggen om du vill utvärdera den lokalt installerade gatewayen. latest ✔️ ❌
beta1 Använd den här taggen om du vill utvärdera förhandsversioner av den lokala gatewayen. beta ✔️ ❌

Du hittar en fullständig lista över tillgängliga taggar här.

1Förhandsversioner stöds inte officiellt och är endast för experimentella ändamål. Se supportprinciperna för lokalt installerad gateway.

Användning av taggar i våra officiella distributionsalternativ

Våra distributionsalternativ i Azure-portalen använder taggen v2 som gör att kunderna kan använda den senaste versionen av den lokala gatewayen v2-containeravbildningen med alla funktionsuppdateringar och korrigeringar.

Kommentar

Vi tillhandahåller kommandot och YAML-kodfragmenten som referens. Använd gärna en mer specifik tagg om du vill.

När du installerar med vårt Helm-diagram optimeras bildtaggning åt dig. Helm-diagrammets programversion fäster gatewayen till en viss version och förlitar sig inte på latest.

Läs mer om hur du installerar en lokalt installerad API Management-gateway på Kubernetes med Helm.

Risk för att använda rullande taggar

Rullande taggar är taggar som kan uppdateras när en ny version av containeravbildningen släpps. Detta gör att containeranvändare kan ta emot uppdateringar av containeravbildningen utan att behöva uppdatera sina distributioner.

Det innebär att du kan köra olika versioner parallellt utan att märka det, till exempel när du utför skalningsåtgärder när v2 taggen har uppdaterats.

Exempel – v2 taggen släpptes med 2.0.0 containeravbildningen, men när 2.1.0 kommer att släppas länkas taggen v2 till avbildningen 2.1.0 .

Viktigt!

Överväg att använda en specifik versionstagg i produktion för att undvika oavsiktlig uppgradering till en nyare version.

Anslutningar till Azure SQL

Gatewayer med egen värd kräver utgående TCP/IP-anslutning till Azure på port 443. Varje lokalt installerad gateway måste vara associerad med en enda API Management-tjänst och konfigureras via dess hanteringsplan. En gateway med egen värd använder anslutning till Azure för att:

  • Rapportera dess status genom att skicka pulsslagsmeddelanden varje minut
  • Regelbundet söka efter (var 10:e sekund) och tillämpa konfigurationsuppdateringar när de är tillgängliga
  • Skicka mått till Azure Monitor, om det är konfigurerat för att göra det
  • Skicka händelser till Application Insights, om det är inställt på att göra det

Viktigt!

Stöd för azure API Management med egen värdbaserad gateway version 0 och version 1-containeravbildningar upphör den 1 oktober 2023, tillsammans med motsvarande Konfigurations-API v1. Använd vår migreringsguide för att använda lokalt installerad gateway v2.0.0 eller senare med Configuration API v2. Läs mer i vår utfasningsdokumentation

FQDN-beroenden

För att fungera korrekt behöver varje lokalt installerad gateway utgående anslutning på port 443 till följande slutpunkter som är associerade med dess molnbaserade API Management-instans:

beskrivning Krävs för v1 Krävs för v2 Kommentar
Värdnamn för konfigurationsslutpunkten <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net1 Anpassade värdnamn stöds också och kan användas i stället för standardvärdnamnet.
Offentlig IP-adress för API Management-instansen ✔️ ✔️ IP-adressen för den primära platsen räcker.
Offentliga IP-adresser för Azure Storage-tjänsttagg ✔️ Valfritt2 IP-adresser måste motsvara den primära platsen för API Management-instansen.
Värdnamn för Azure Blob Storage-konto ✔️ Valfritt2 Konto som är associerat med instansen (<blob-storage-account-name>.blob.core.windows.net)
Värdnamn för Azure Table Storage-konto ✔️ Valfritt2 Konto som är associerat med instansen (<table-storage-account-name>.table.core.windows.net)
Slutpunkter för Azure Resource Manager ✔️ Valfritt3 Nödvändiga slutpunkter är management.azure.com.
Slutpunkter för Microsoft Entra-integrering ✔️ Valfritt4 Nödvändiga slutpunkter är <region>.login.microsoft.com och login.microsoftonline.com.
Slutpunkter för Azure Application Insights-integrering Valfritt5 Valfritt5 Minimala nödvändiga slutpunkter är:
  • rt.services.visualstudio.com:443
  • dc.services.visualstudio.com:443
  • {region}.livediagnostics.monitor.azure.com:443
Läs mer i Azure Monitor-dokument
Slutpunkter för Event Hubs-integrering Valfritt5 Valfritt5 Läs mer i Azure Event Hubs-dokument
Slutpunkter för extern cacheintegrering Valfritt5 Valfritt5 Det här kravet beror på den externa cache som används

1För en API Management-instans i ett internt virtuellt nätverk aktiverar du privat anslutning till v2-konfigurationsslutpunkten från platsen för den lokala gatewayen, till exempel med hjälp av en privat DNS i ett peer-kopplat nätverk.
2Krävs endast i v2 när API-kontroll eller kvoter används i principer.
3Krävs endast när du använder Microsoft Entra-autentisering för att verifiera RBAC-behörigheter.
4Krävs endast när du använder Microsoft Entra-autentisering eller Microsoft Entra-relaterade principer.
5Krävs endast när funktionen används och kräver offentlig IP-adress, port och värdnamnsinformation.

Viktigt!

  • DNS-värdnamn måste kunna matchas mot IP-adresser och motsvarande IP-adresser måste kunna nås.
  • De associerade lagringskontonamnen visas på tjänstens statussida för nätverksanslutning i Azure-portalen.
  • Offentliga IP-adresser som ligger till grund för de associerade lagringskontona är dynamiska och kan ändras utan föregående meddelande.

Autentiseringsalternativ

Om du vill autentisera anslutningen mellan den lokalt installerade gatewayen och den molnbaserade API Management-instansens konfigurationsslutpunkt har du följande alternativ i gatewaycontainerns konfigurationsinställningar.

Alternativ Att tänka på
Microsoft Entra-autentisering Konfigurera en eller flera Microsoft Entra-appar för åtkomst till gateway

Hantera åtkomst separat per app

Konfigurera längre förfallotider för hemligheter i enlighet med organisationens principer

Använd Microsoft Entra-standardprocedurer för att tilldela eller återkalla användar- eller gruppbehörigheter till appen och för att rotera hemligheter
Gateway-åtkomsttoken (kallas även autentiseringsnyckel) Token upphör att gälla var 30:e dag som högst och måste förnyas i containrarna

Backas upp av en gatewaynyckel som kan roteras oberoende (till exempel för att återkalla åtkomst)

Återskapa gatewaynyckeln ogiltigförklarar alla åtkomsttoken som skapats med den

Anslut fel

När anslutningen till Azure går förlorad kan den lokalt installerade gatewayen inte ta emot konfigurationsuppdateringar, rapportera dess status eller ladda upp telemetri.

Den lokalt installerade gatewayen är utformad för att "misslyckas statisk" och kan överleva tillfällig förlust av anslutning till Azure. Den kan distribueras med eller utan lokal konfigurationssäkerhetskopia. Med konfigurationssäkerhetskopiering sparar lokala gatewayer regelbundet en säkerhetskopia av den senaste nedladdade konfigurationen på en beständig volym som är kopplad till containern eller podden.

När konfigurationssäkerhetskopian är avstängd och anslutningen till Azure avbryts:

  • Om du kör gatewayer med egen värd fortsätter den att fungera med hjälp av en minnesintern kopia av konfigurationen
  • Stoppade gatewayer med egen värd kan inte starta

När konfigurationssäkerhetskopian är aktiverad och anslutningen till Azure avbryts:

  • Om du kör gatewayer med egen värd fortsätter den att fungera med hjälp av en minnesintern kopia av konfigurationen
  • Stoppade gatewayer med egen värd kan börja använda en säkerhetskopia av konfigurationen

När anslutningen återställs återansluter varje lokalt installerad gateway som påverkas av driftstoppet automatiskt med sin associerade API Management-tjänst och laddar ned alla konfigurationsuppdateringar som inträffade när gatewayen var "offline".

Säkerhet

Begränsningar

Följande funktioner som finns i de hanterade gatewayerna är inte tillgängliga i de lokala gatewayerna:

  • Återupptagande av TLS-session.
  • Omförhandling av klientcertifikat. Om du vill använda klientcertifikatautentisering måste API-konsumenter presentera sina certifikat som en del av den första TLS-handskakningen. För att säkerställa det här beteendet aktiverar du inställningen Förhandla klientcertifikat när du konfigurerar en egen värdbaserad gateway med anpassat värdnamn (domännamn).

Transport Layer Security (TLS)

Viktigt!

Den här översikten gäller endast för den lokalt installerade gatewayen v1 och v2.

Protokoll som stöds

Den lokalt installerade gatewayen har som standard stöd för TLS v1.2.

Kunder som använder anpassade domäner kan aktivera TLS v1.0 och/eller v1.1 i kontrollplanet.

Tillgängliga chiffersviter

Viktigt!

Den här översikten gäller endast för den lokala gatewayen v2.

Den lokalt installerade gatewayen använder följande chiffersviter för både klient- och serveranslutningar:

  • 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

Hantera chiffersviter

Från och med v2.1.1 och senare kan du hantera chiffer som används via konfigurationen:

  • net.server.tls.ciphers.allowed-suites gör att du kan definiera en kommaavgränsad lista över chiffer som ska användas för TLS-anslutningen mellan API-klienten och den lokalt installerade gatewayen.
  • net.client.tls.ciphers.allowed-suites gör att du kan definiera en kommaavgränsad lista över chiffer som ska användas för TLS-anslutningen mellan den lokala gatewayen och serverdelen.

Nästa steg