Teilen über

Übersicht über das selbstgehostete Gateway

GILT FÜR: Developer | Premium

Selbst gehostetes Gateway ist eine optionale containerisierte Version des standardmäßigen verwalteten Gateways, das in jeder API-Verwaltungsinstanz enthalten ist. Es ist nützlich für Szenarien wie das Platzieren von Gateways in den gleichen 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 das selbst gehostete Gatewayfeature von Azure API Management die Hybrid- und Multicloud-API-Verwaltung ermöglicht. Außerdem wird die allgemeine Architektur des Features präsentiert und seine Funktionen beschrieben.

Eine Übersicht über die Unterschiede zwischen verwalteten und selbst gehosteten Gateways finden Sie unter API-Gateway in der API-Verwaltung.

API-Verwaltung in Hybridumgebungen und Umgebungen mit mehreren Clouds

Das selbst gehostete Gatewayfeature erweitert die API-Verwaltungsunterstützung für Hybrid- und Multicloud-Umgebungen und ermöglicht es Ihnen, APIs, die lokal und über cloudübergreifend gehostet werden, effizient und sicher über eine einzelne API-Verwaltungsinstanz in Azure zu verwalten.

Mit selbst gehostetem Gateway haben Sie die Flexibilität, eine containerisierte Version der API-Verwaltungsgatewaykomponente in den gleichen Umgebungen bereitzustellen, in denen Sie Ihre APIs hosten. Alle selbst gehosteten Gateways werden von der API-Verwaltungsinstanz verwaltet, mit der sie verbunden sind, sodass Sie die Sichtbarkeit und einheitliche Verwaltungserfahrung über alle internen und externen APIs hinweg erhalten.

Jede API-Verwaltungsinstanz besteht aus den folgenden Schlüsselkomponenten:

  • Eine Verwaltungsebene, die als API verfügbar gemacht wird, um den Dienst über das Azure-Portal, PowerShell und andere unterstützte Technologien zu konfigurieren
  • Ein Gateway (oder eine Datenebene), das für Proxy-API-Anforderungen, das Anwenden von Richtlinien und das Sammeln von Telemetriedaten zuständig ist
  • Ein Entwicklerportal, das von Entwicklern zum Ermitteln, Erlernen und Onboarding für die Verwendung der APIs verwendet wird

Standardmäßig werden alle diese Komponenten in Azure bereitgestellt, was dazu führt, dass der gesamte API-Datenverkehr (dargestellt als einfarbige schwarze Pfeile in der folgenden Abbildung) durch Azure fließt, unabhängig davon, wo Back-Ends 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-Datenverkehrsfluss ohne selbst gehostete Gateways

Durch die Bereitstellung von selbst gehosteten Gateways in den gleichen Umgebungen, in denen die Back-End-API-Implementierungen gehostet werden, können API-Datenverkehr direkt an die Back-End-APIs fließen, wodurch Latenz reduziert, Datenübertragungskosten optimiert und die Compliance ermöglicht und gleichzeitig die Vorteile einer einzigen Verwaltungs-, Observierbarkeits- und Ermittlungsmöglichkeit für alle APIs in der Organisation beibehalten werden, unabhängig davon, wo ihre Implementierungen gehostet werden.

API-Datenverkehrsfluss mit selbst gehosteten Gateways

Verpackung

Das selbstgehostete Gateway ist in der Microsoft-Artefaktregistrierung als Linux-basiertes Docker-Containerimage verfügbar. Sie kann für Docker, Kubernetes oder eine beliebige andere Container-Orchestrierungslösung bereitgestellt werden, die auf einem Servercluster lokal, in einer Cloudinfrastruktur oder zu Auswertungs- und Entwicklungszwecken auf einem Persönlichen Computer ausgeführt wird. Sie können das selbst gehostete Gateway auch als Cluster-Erweiterung für einen Azure Arc-aktivierten Kubernetes-Cluster bereitstellen.

Containerimages

Es stehen eine Vielzahl von Containerimages für selbst gehostete Gateways zur Verfügung:

Tagkonvention Empfehlung Beispiel Fortlaufendes Tag Empfohlen für die Produktion
{major}.{minor}.{patch} Verwenden Sie dieses Tag, um immer dieselbe 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 das neueste Vorschaucontainerimage ausführen möchten. v2-preview ✔️ ❌
latest Verwenden Sie dieses Tag, wenn Sie das selbstgehostete Gateway auswerten möchten. latest ✔️ ❌
beta 1 Verwenden Sie dieses Tag, wenn Sie die Vorschauversionen des selbstgehosteten Gateways testen möchten. beta ✔️ ❌

Hier finden Sie eine vollständige Liste der verfügbaren Tags.

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

Verwendung von Tags in offiziellen Bereitstellungsoptionen

Bereitstellungsoptionen im Azure-Portal verwenden das v2 Tag, mit dem Sie die neueste Version des selbst gehosteten Gateway-v2-Containerimages mit allen Featureupdates und Patches verwenden können.

Hinweis

Der Befehl und die YAML-Codeausschnitte werden als Referenz bereitgestellt. Sie können ein spezifischeres Tag verwenden, wenn Sie möchten.

Wenn Sie ein Gateway mit einem Helm-Chart installieren, wird das Image-Tagging 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 eines selbst gehosteten API-Verwaltungsgateways auf 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. Die Verwendung dieser Art von Tags ermöglicht containerbenutzern das Empfangen von Updates für das Containerimage, ohne ihre Bereitstellungen aktualisieren zu müssen.

Wenn Sie diesen Tagtyp verwenden, können Sie möglicherweise verschiedene Versionen parallel ausführen, ohne sie zu notieren, z. B. wenn Sie Skalierungsaktionen ausführen, nachdem das v2 Tag aktualisiert wurde.

Beispiel: Das v2-Element wird mit dem 2.0.0-Container-Image freigegeben. Wenn 2.1.0 freigegeben wird, wird das v2-Tag mit dem 2.1.0-Bild verbunden.

Wichtig

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

Konnektivität mit Azure

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

  • Melden Sie ihren Status, indem Sie Taktnachrichten jede Minute senden.
  • Es wird regelmäßig (alle 10 Sekunden) nach Konfigurationsupdates gesucht und diese angewendet, wann immer sie verfügbar sind.
  • Senden von Metriken an Azure Monitor, falls dies konfiguriert ist.
  • Senden von Ereignissen an Application Insights, falls dies konfiguriert ist.

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:

Endpunkt Erforderlich? Notizen
Hostname des Konfigurationsendpunkts <api-management-service-name>.configuration.azure-api.net 1 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 reicht aus.
Öffentliche IP-Adressen des Azure Storage-Diensttags Optional2 IP-Adressen müssen dem primären Speicherort der API-Verwaltungsinstanz entsprechen.
Hostname des Azure Blob Storage-Kontos Optional2 Das Konto, das der Instanz (<blob-storage-account-name>.blob.core.windows.net) zugeordnet ist.
Hostname des Azure Table Storage-Kontos Optional2 Das Konto, das der Instanz (<table-storage-account-name>.table.core.windows.net) zugeordnet ist.
Endpunkte für Azure Resource Manager Optional3 Der erforderliche Endpunkt ist 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 Minimale erforderliche Endpunkte sind rt.services.visualstudio.com:443, dc.services.visualstudio.com:443und {region}.livediagnostics.monitor.azure.com:443. Weitere Informationen finden Sie in der Dokumentation zu Azure Monitor.
Endpunkte für die Integration von Event Hubs Optional5 Weitere Informationen finden Sie in der Dokumentation zu Azure Event Hubs.
Endpunkte für die Integration von externem Speicher Optional5 Diese Anforderung hängt vom verwendeten externen Cache ab.

1Informationen zu einer 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 Sie die Microsoft Entra-Authentifizierung oder -Richtlinien im Zusammenhang mit Microsoft Entra verwenden.
5Nur erforderlich, wenn das Feature verwendet wird und öffentliche IP-Adresse, Port und Hostnameninformationen erforderlich sind.

Wichtig

  • DNS-Hostnamen müssen für IP-Adressen aufgelöst werden können, und die entsprechenden IP-Adressen müssen erreichbar sein.
  • Die zugehörigen Speicherkontonamen werden auf der Seite "Netzwerkkonnektivität " des Diensts im Azure-Portal aufgelistet.
  • Öffentliche IP-Adressen, die den zugeordneten Speicherkonten zugrunde liegen, sind dynamisch und können sich ohne vorherige Ankündigung ändern.

Konnektivität in einem 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 Azure-Anwendungsgateways verfügbar.

Authentifizierungsoptionen

Die Konfigurationseinstellungen des Gatewaycontainers bieten die folgenden Optionen zum Authentifizieren der Verbindung zwischen dem selbst gehosteten Gateway und dem konfigurationsendpunkt der cloudbasierten API-Verwaltungsinstanz.

Option Überlegungen
Microsoft Entra-Authentifizierung Konfigurieren Sie eine oder mehrere Microsoft Entra-Apps für den Zugriff auf das Gateway.

Verwalten Sie den Zugriff separat pro App.

Konfigurieren Sie längere Ablaufzeiten für geheime Schlüssel gemäß den Richtlinien Ihrer Organisation.

Verwenden Sie standardmäßige Microsoft Entra-Verfahren, um Benutzer- oder Gruppenberechtigungen für Apps zuzuweisen oder zu widerrufen und um geheime Schlüssel zu verwalten.
Gateway-Zugriffstoken. (Auch als Authentifizierungsschlüssel bezeichnet.) Das Token läuft mindestens alle 30 Tage ab und muss in den Containern erneuert werden.

Gesichert durch einen Gatewayschlüssel, der unabhängig gedreht werden kann (z. B. zum Widerrufen des Zugriffs).

Durch die Erneuerung des Gatewayschlüssels werden alle damit erstellten Zugriffstoken ungültig.

Tipp

Informationen zu Ereignisrasterereignissen, die von einem selbst gehosteten Gateway generiert werden, wenn ein Gatewayzugriffstoken bald abläuft oder abgelaufen ist, finden Sie unter Azure API Management als Ereignisrasterquelle . Verwenden Sie diese Ereignisse, um sicherzustellen, dass bereitgestellte Gateways immer mit der zugehörigen API-Verwaltungsinstanz authentifiziert werden können.

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:

  • Das Ausführen selbst gehosteter Gateways funktioniert weiterhin mithilfe einer Speicherkopie der Konfiguration.
  • Gestoppte selbst gehostete Gateways können nicht mehr gestartet werden.

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

  • Das Ausführen selbst gehosteter Gateways funktioniert weiterhin mithilfe einer Speicherkopie der Konfiguration.
  • Gestoppte selbstgehostete Gateways können mithilfe einer Konfigurationssicherungskopie neu gestartet werden.

Wenn die Verbindung wiederhergestellt wird, stellt jedes selbst gehostete Gateway, das von dem Ausfall betroffen ist, automatisch eine Verbindung mit der zugehörigen API-Verwaltungsinstanz her und lädt alle Konfigurationsupdates herunter, die während des Gateways offline waren.

Sicherheit

Einschränkungen

Die folgende Funktionalität, die in verwalteten Gateways verfügbar ist, ist in selbst gehosteten Gateways 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) (Transportschichtsicherheit)

Unterstützte Protokolle

Selbst gehostete Gateways unterstützen standardmäßig TLS v1.2.

Wenn Sie benutzerdefinierte Domänen verwenden, können Sie TLS v1.0 und/oder v1.1 in der Steuerebene aktivieren.

Verfügbare Verschlüsselungssammlungen

Selbst gehostete Gateways verwenden die folgenden Verschlüsselungssammlungen 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

Mit v2.1.1 und höher können Sie die Verschlüsselungen verwalten, die über die Konfiguration verwendet werden:

  • net.server.tls.ciphers.allowed-suites ermöglicht es Ihnen, eine durch Trennzeichen getrennte Liste von Verschlüsselungen zu definieren, die für die TLS-Verbindung zwischen dem API-Client und dem selbst gehosteten Gateway verwendet werden sollen.
  • net.client.tls.ciphers.allowed-suites ermöglicht es Ihnen, eine durch Trennzeichen getrennte Liste von Verschlüsselungen zu definieren, die für die TLS-Verbindung zwischen dem selbst gehosteten Gateway und dem Back-End verwendet werden sollen.

Verwandte Inhalte

  • Last updated on