Teilen über

Übersicht über das selbstgehostete Gateway

  • Artikel

GILT FÜR: Entwickler | Premium

Das selbstgehostete Gateway ist eine optionale, containerisierte Version des standardmäßigen verwalteten Gateways, das in jedem API Management-Dienst enthalten ist. Es ist nützlich für Szenarien wie das Platzieren von Gateways in den selben Umgebungen, in denen Sie Ihre APIs hosten. Verwenden Sie das selbst gehostete Gateway, um den API-Datenverkehrsfluss zu verbessern und Anforderungen an die API-Sicherheit und -Compliance zu erfüllen.

In diesem Artikel wird erläutert, wie die Funktion „selbstgehostetes Gateway“ von Azure API Management die API-Verwaltung in Hybridumgebungen und Umgebungen mit mehreren Clouds vereinfacht. Außerdem werden die allgemeine Architektur und die Funktionen vorgestellt.

Eine Übersicht der Features in den verschiedenen Gatewayangeboten finden Sie unter API-Gateway in API Management.

API-Verwaltung in Hybridumgebungen und Umgebungen mit mehreren Clouds

Das Feature „selbstgehostetes Gateway“ weitet die API Management-Unterstützung auf Hybridumgebungen und Umgebungen mit mehreren Clouds aus und ermöglicht es Organisationen, lokal und cloudübergreifend gehostete APIs über einen einzigen API Management-Dienst in Azure effizient und sicher zu verwalten.

Mit dem selbstgehosteten Gateway erhalten Kunden die Flexibilität, eine containerbasierte Version der API Management-Gatewaykomponente in den gleichen Umgebungen bereitzustellen, in denen auch die APIs gehostet werden. Alle selbstgehosteten Gateways werden über den API Management-Dienst verwaltet, mit dem sie sich im Verbund befinden. So profitieren Kunden von Transparenz und einheitlichen Verwaltungsfunktionen für alle internen und externen APIs.

Jeder API Management-Dienst besteht aus den folgenden Hauptkomponenten:

  • Eine Verwaltungsebene – als API verfügbar gemacht –, die zum Konfigurieren des Dienst über das Azure-Portal, PowerShell oder andere unterstützte Mechanismen verwendet wird
  • Eine Gatewayebene (bzw. Datenebene), auf der die Proxyweiterleitung von API-Anforderungen, die Anwendung von Richtlinien und die Sammlung von Telemetriedaten erfolgt
  • Ein Entwicklerportal, in dem Entwickler APIs ermitteln, kennen lernen und integrieren

Standardmäßig werden all diese Komponenten in Azure bereitgestellt, sodass sämtlicher API-Datenverkehr (auf dem folgenden Bild als durchgehende schwarze Pfeile dargestellt) durch Azure geleitet wird, unabhängig davon, wo die Back-End-Systeme gehostet werden, die die APIs implementieren. Mit dem einfachen Betrieb dieses Modells gehen allerdings höhere Latenzen, Complianceprobleme und in einigen Fällen zusätzliche Gebühren für die Datenübertragung einher.

API-Datenverkehrsflow ohne selbstgehostete Gateways

Indem selbstgehostete Gateways in denselben Umgebungen, in denen die Implementierungen der Back-End-APIs gehostet werden, bereitgestellt werden, kann der API-Datenverkehr direkt an die Back-End-APIs geleitet werden. Dies verringert die Latenz, optimiert die Datenübertragungskosten und sorgt für Compliance. Gleichzeitig bleiben die Vorteile erhalten: Die Verwaltung, der Einblick und die Ermittlung aller APIs in der Organisation erfolgt an einer zentralen Stelle – unabhängig davon, wo die Implementierungen gehostet werden.

API-Datenverkehrsflow mit selbstgehosteten Gateways

Verpackung

Das selbstgehostete Gateway ist in der Microsoft-Artefaktregistrierung als Linux-basiertes Docker-Containerimage verfügbar. Es kann in Docker, Kubernetes oder jeder anderen Lösung für die Containerorchestrierung bereitgestellt werden, die auf einem lokalen Servercluster, in einer Cloudinfrastruktur oder zu Evaluierungs- und Entwicklungszwecken auf einem PC ausgeführt wird. Sie können das selbst gehostete Gateway auch als Cluster-Erweiterung für einen Azure Arc-aktivierten Kubernetes-Cluster bereitstellen.

Containerimages

Wir stellen eine Vielzahl von Containerimages für selbstgehostete Gateways bereit, um Ihre Anforderungen zu erfüllen:

Tagkonvention Empfehlung Beispiel Fortlaufendes Tag Empfohlen für die Produktion
{major}.{minor}.{patch} Verwenden Sie dieses Tag, um immer die gleiche Version des Gateways auszuführen. 2.0.0 ❌ ✔️
v{major} Verwenden Sie dieses Tag, um immer eine Hauptversion des Gateways mit jedem neuen Feature und Patch auszuführen. v2 ✔️ ❌
v{major}-preview Verwenden Sie dieses Tag, wenn Sie immer unser neuestes Vorschaucontainerimage ausführen möchten. v2-preview ✔️ ❌
latest Verwenden Sie dieses Tag, wenn Sie das selbstgehostete Gateway auswerten möchten. latest ✔️ ❌
beta1 Verwenden Sie dieses Tag, wenn Sie die Vorschauversionen des selbstgehosteten Gateways testen möchten. beta ✔️ ❌

Eine vollständige Liste der verfügbaren Tags finden Sie hier.

1Vorschauversionen werden nicht offiziell unterstützt und sind nur für experimentelle Zwecke gedacht. Siehe Supportrichtlinien für selbstgehostete Gateways.

Verwendung von Tags in unseren offiziellen Bereitstellungsoptionen

Unsere Bereitstellungsoptionen im Azure-Portal verwenden das Tag v2. Mit diesem Tag können Kunden die neueste Version des Containerimages des selbstgehosteten Gateways v2 mit allen Featureupdates und Patches verwenden.

Hinweis

Wir stellen den Befehl und die YAML-Codeausschnitte als Referenz bereit. Sie können bei Bedarf ein spezifischeres Tag verwenden.

Bei der Installation mit unserem Helm-Diagramm ist die Imagemarkierung für Sie optimiert. Die Anwendungsversion des Helm-Charts heftet das Gateway an eine bestimmte Version an und ist nicht auf latest angewiesen.

Weitere Informationen finden Sie unter Installieren selbstgehosteter API Management-Gateways in Kubernetes mit Helm.

Risiko der Verwendung von fortlaufenden Tags

Fortlaufende Tags sind Tags, die möglicherweise aktualisiert werden, wenn eine neue Version des Containerimages veröffentlicht wird. Dadurch können Containerbenutzer Updates für das Containerimage erhalten, ohne ihre Bereitstellungen aktualisieren zu müssen.

Das bedeutet, dass Sie möglicherweise verschiedene Versionen parallel ausführen können, ohne es zu bemerken, etwa wenn Sie nach der Aktualisierung des Tags v2 Skalierungsaktionen ausführen.

Beispiel: Das Tag v2 wurde mit dem Containerimage 2.0.0 veröffentlicht. Bei der Veröffentlichung von 2.1.0 wird das Tag v2 jedoch mit dem Image 2.1.0 verknüpft.

Wichtig

Erwägen Sie die Verwendung eines speziellen Versionstags in der Produktion, um eine unbeabsichtigte Aktualisierung auf eine neuere Version zu vermeiden.

Konnektivität mit Azure

Selbstgehostete Gateways erfordern ausgehende TCP/IP-Konnektivität mit Azure an Port 443. Jedes selbstgehostete Gateway muss einer einzelnen API Management-Dienstinstanz zugeordnet werden und wird über deren Verwaltungsebene konfiguriert. Ein selbstgehostetes Gateway nutzt die Konnektivität mit Azure für Folgendes:

  • Melden des Status durch minütliches Senden von Heartbeatmeldungen
  • Regelmäßiges Überprüfen auf Konfigurationsupdates (alle zehn Sekunden) und Anwenden der Updates, sobald sie verfügbar sind
  • Senden von Metriken an Azure Monitor, sofern konfiguriert
  • Senden von Ereignissen an Application Insights, sofern eingerichtet

FQDN-Abhängigkeiten

Für den ordnungsgemäßen Betrieb benötigt jedes selbstgehostete Gateway ausgehende Konnektivität an Port 443 mit den folgenden Endpunkten, die mit der zugehörigen cloudbasierten API Management-Instanz verknüpft sind:

BESCHREIBUNG Erforderlich für v1 Erforderlich für v2 Hinweise
Hostname des Konfigurationsendpunkts <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net1 Benutzerdefinierte Hostnamen werden ebenfalls unterstützt und können anstelle des Standardhostnamens verwendet werden.
Öffentliche IP-Adresse der API Management-Instanz ✔️ ✔️ Die IP-Adresse des primären Standorts ist ausreichend.
Öffentliche IP-Adressen des Azure Storage-Diensttags ✔️ Optional2 IP-Adressen müssen dem primären Standort einer API Management-Instanz entsprechen.
Hostname des Azure Blob Storage-Kontos ✔️ Optional2 Der Instanz zugeordnetes Konto (<blob-storage-account-name>.blob.core.windows.net)
Hostname des Azure Table Storage-Kontos ✔️ Optional2 Der Instanz zugeordnetes Konto (<table-storage-account-name>.table.core.windows.net)
Endpunkte für Azure Resource Manager ✔️ Optional3 Erforderliche Endpunkte sind management.azure.com.
Endpunkte für die Microsoft Entra-Integration ✔️ Optional4 Erforderliche Endpunkte sind <region>.login.microsoft.com und login.microsoftonline.com.
Endpunkte für die Azure Application Insights-Integration Optional5 Optional5 Mindestens erforderliche Endpunkte sind:
  • rt.services.visualstudio.com:443
  • dc.services.visualstudio.com:443
  • {region}.livediagnostics.monitor.azure.com:443
Weitere Informationen finden Sie in der Azure Monitor-Dokumentation.
Endpunkte für die Integration von Event Hubs Optional5 Optional5 Weitere Informationen erhalten Sie in der Azure Event Hubs-Dokumentation.
Endpunkte für die Integration von externem Speicher Optional5 Optional5 Diese Anforderung hängt von dem externen Cache ab, der verwendet wird.

1Eine API-Verwaltungsinstanz in einem internen virtuellen Netzwerk finden Sie unter Konnektivität in einem internen virtuellen Netzwerk.
2Nur in v2 erforderlich, wenn der API-Inspektor oder Kontingente in Richtlinien verwendet werden.
3Nur erforderlich, wenn die Microsoft Entra-Authentifizierung zum Überprüfen der RBAC-Berechtigungen verwendet wird.
4Nur erforderlich, wenn die Microsoft Entra-Authentifizierung oder Microsoft Entra-bezogene Richtlinien verwendet werden.
5Nur erforderlich, wenn das Feature verwendet wird und öffentliche IP-Adress-, Port- und Hostnameninformationen erfordert.

Wichtig

  • DNS-Hostnamen müssen in IP-Adressen auflösbar sein, und die entsprechenden IP-Adressen müssen erreichbar sein.
  • Die zugeordneten Speicherkontonamen werden auf der Seite Netzwerkkonnektivitätsstatus des Diensts im Azure-Portal aufgeführt.
  • Öffentliche IP-Adressen, die den zugeordneten Speicherkonten zugrunde liegen, sind dynamisch und können sich ohne vorherige Ankündigung ändern.

Konnektivität im internen virtuellen Netzwerk

  • Private Konnektivität: Wenn das selbst gehostete Gateway in einem virtuellen Netzwerk bereitgestellt wird, aktivieren Sie die private Konnektivität mit dem v2-Konfigurationsendpunkt vom Standort des selbst gehosteten Gateways, z. B. mithilfe eines privaten DNS in einem Peered-Netzwerk.

  • Internetverbindung: Wenn das selbst gehostete Gateway eine Verbindung mit dem v2-Konfigurationsendpunkt über das Internet herstellen muss, konfigurieren Sie einen benutzerdefinierten Hostnamen für den Konfigurationsendpunkt, und machen Sie den Endpunkt mithilfe des Anwendungsgateways verfügbar.

Authentifizierungsoptionen

Um die Verbindung zwischen dem selbstgehosteten Gateway und dem Konfigurationsendpunkt der cloudbasierten API Management-Instanz zu authentifizieren, haben Sie die folgenden Optionen in den Konfigurationseinstellungen des Gatewaycontainers.

Option Überlegungen
Microsoft Entra-Authentifizierung Konfigurieren einer oder mehrerer Microsoft Entra-Apps für den Zugriff auf das Gateway

Separates Verwalten des Zugriffs pro App

Konfigurieren längerer Ablaufzeiten für Geheimnisse in Übereinstimmung mit den Richtlinien Ihrer Organisation

Verwenden von Microsoft Entra-Standardprozeduren zum Zuweisen oder Widerrufen von Benutzer- oder Gruppenberechtigungen für eine App und zum Rotieren von Geheimnissen
Gatewayzugriffstoken (auch Authentifizierungsschlüssel) Das Token läuft maximal alle 30 Tage ab und muss in den Containern erneuert werden.

Unterstützt durch einen Gatewayschlüssel, der unabhängig gedreht werden kann (z. B. um den Zugriff zu widerrufen)

Beim erneuten Generieren des Gatewayschlüssels werden alle damit erstellten Zugriffstoken ungültig.

Konnektivitätsfehler

Wenn die Verbindung zu Azure unterbrochen wird, kann das selbstgehostete Gateway keine Konfigurationsupdates empfangen, Statusmeldungen senden oder Telemetriedaten hochladen.

Das selbstgehostete Gateway ist für „fail-static“ konzipiert und übersteht temporäre Unterbrechungen der Konnektivität mit Azure. Es kann mit oder ohne lokale Konfigurationssicherung bereitgestellt werden. Bei der Konfigurationssicherung speichern selbstgehostete Gateways in regelmäßigen Abständen eine Sicherungskopie der jüngsten heruntergeladenen Konfiguration auf einem persistenten Volume, das an den Container oder Pod angeschlossen ist.

Wenn die Konfigurationssicherung deaktiviert ist und die Konnektivität mit Azure unterbrochen wird, geschieht Folgendes:

  • Die Ausführung selbstgehosteter Gateways funktioniert auch weiterhin unter Verwendung einer arbeitsspeicherinternen Kopie der Konfiguration.
  • Beendete selbstgehostete Gateways können nicht gestartet werden.

Wenn die Konfigurationssicherung aktiviert ist und die Konnektivität mit Azure unterbrochen wird, geschieht Folgendes:

  • Die Ausführung selbstgehosteter Gateways funktioniert auch weiterhin unter Verwendung einer arbeitsspeicherinternen Kopie der Konfiguration.
  • Angehaltene selbstgehostete Gateways können unter Verwendung einer Sicherungskopie der Konfiguration starten.

Wenn die Konnektivität wiederhergestellt ist, stellt jedes vom Ausfall betroffene selbstgehostete Gateway automatisch wieder eine Verbindung mit dem zugehörigen API Management-Dienst her und lädt alle Konfigurationsupdates herunter, die zur Verfügung gestellt wurden, während das Gateway offline war.

Sicherheit

Einschränkungen

Die folgende, in verwalteten Gateways zu findende Funktionalität ist im selbstgehosteten Gateway nicht verfügbar:

  • TLS-Sitzungswiederaufnahme.
  • Erneute Aushandlung des Clientzertifikats. Um Clientzertifikatauthentifizierung zu verwenden, müssen API-Consumer ihre Zertifikate als Teil des ersten TLS-Handshakes präsentieren. Um dies sicherzustellen, aktivieren Sie die Einstellung „Clientzertifikat aushandeln“, wenn Sie den benutzerdefinierten Hostnamen (Domänennamen) eines selbstgehosteten Gateways konfigurieren.

Transport Layer Security (TLS)

Wichtig

Diese Übersicht gilt nur für die selbstgehosteten Gateways V1 und V2.

Unterstützte Protokolle

Das selbstgehostete Gateway unterstützt standardmäßig TLS v1.2.

Kunden, die benutzerdefinierte Domänen verwenden, können TLS v1.0 und/oder TLS v1.1 auf der Steuerungsebene aktivieren.

Verfügbare Verschlüsselungssammlungen

Wichtig

Diese Übersicht gilt nur für das selbstgehostete Gateways v2.

Das selbstgehostete Gateway verwendet die folgenden Verschlüsselungssuiten für Client- und Serververbindungen:

  • 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

Verwalten von Verschlüsselungssammlungen

Ab v2.1.1 können die verwendeten Verschlüsselungen über die Konfiguration verwalten:

  • net.server.tls.ciphers.allowed-suites ermöglicht das Definieren einer durch Kommas getrennten Liste mit Verschlüsselungen, die für die TLS-Verbindung zwischen dem API-Client und dem selbstgehosteten Gateway verwendet werden sollen.
  • net.client.tls.ciphers.allowed-suites ermöglicht das Definieren einer durch Kommas getrennten Liste mit Verschlüsselungen, die für die TLS-Verbindung zwischen dem selbstgehosteten Gateway und dem Back-End verwendet werden sollen.

Nächste Schritte