Udostępnij za pośrednictwem

Omówienie własnej bramy

  • Artykuł

DOTYCZY: Developer | Premia

Brama self-hosted jest opcjonalną, konteneryzowaną wersją domyślnej bramy zarządzanej uwzględnionej w każdej usłudze API Management. Jest to przydatne w scenariuszach, takich jak umieszczanie bram w tych samych środowiskach, w których hostujesz interfejsy API. Użyj własnej bramy, aby poprawić przepływ ruchu interfejsu API i spełnić wymagania dotyczące zabezpieczeń i zgodności interfejsu API.

W tym artykule wyjaśniono, jak funkcja własnej bramy usługi Azure API Management umożliwia hybrydowe i wielochmurowe zarządzanie interfejsami API, prezentuje architekturę wysokiego poziomu i wyróżnia jej możliwości.

Aby zapoznać się z omówieniem funkcji różnych ofert bram, zobacz Brama interfejsu API w usłudze API Management.

Zarządzanie hybrydowymi interfejsami API i w wielu chmurach

Funkcja bramy hostowanej samodzielnie rozszerza obsługę usługi API Management w środowiskach hybrydowych i dla wielu chmur oraz umożliwia organizacjom wydajne i bezpieczne zarządzanie interfejsami API hostowanymi lokalnie i w różnych chmurach z poziomu jednej usługi API Management na platformie Azure.

Dzięki własnej bramie klienci mają elastyczność wdrażania konteneryzowanej wersji składnika bramy usługi API Management w tych samych środowiskach, w których hostują swoje interfejsy API. Wszystkie bramy hostowane samodzielnie są zarządzane z poziomu usługi API Management, z którą są sfederowane, zapewniając klientom widoczność i ujednolicone środowisko zarządzania we wszystkich wewnętrznych i zewnętrznych interfejsach API.

Każda usługa API Management składa się z następujących kluczowych składników:

  • Płaszczyzna zarządzania, uwidoczniona jako interfejs API, używana do konfigurowania usługi za pośrednictwem witryny Azure Portal, programu PowerShell i innych obsługiwanych mechanizmów.
  • Brama (lub płaszczyzna danych), która jest odpowiedzialna za użycie serwera proxy w żądaniach interfejsu API, za stosowanie zasad i zbieranie danych telemetrycznych
  • Portal deweloperów używany przez deweloperów do odnajdywania, uczenia się i dołączania w celu używania interfejsów API

Domyślnie wszystkie te składniki są wdrażane na platformie Azure, powodując cały ruch interfejsu API (pokazany jako solidne czarne strzałki na poniższej ilustracji) do przepływu przez platformę Azure niezależnie od tego, gdzie są hostowane zaplecza implementowane interfejsy API. Prostota operacyjna tego modelu wiąże się z kosztem zwiększonego opóźnienia, problemów ze zgodnością i w niektórych przypadkach dodatkowych opłat za transfer danych.

Przepływ ruchu interfejsu API bez własnych bram

Wdrażanie bram hostowanych samodzielnie w tych samych środowiskach, w których są hostowane wdrożenia interfejsu API zaplecza, umożliwia przepływ ruchu interfejsu API bezpośrednio do interfejsów API zaplecza, co zmniejsza opóźnienie, optymalizuje koszty transferu danych i zapewnia zgodność, zachowując jednocześnie korzyści wynikające z posiadania jednego punktu zarządzania, wgląd i odnajdywanie wszystkich interfejsów API w organizacji niezależnie od tego, gdzie są hostowane ich wdrożenia.

Przepływ ruchu interfejsu API z własnymi bramami

Packaging

Brama hostowana samodzielnie jest dostępna jako obraz kontenera platformy Docker oparty na systemie Linux pochodzący z usługi Rejestr Artefaktów Microsoft. Można element wdrożyć w usłudze Docker, na platformie Kubernetes lub w dowolnym innym rozwiązaniu orkiestracji kontenerów działającym w klastrze serwera w środowisku lokalnym, infrastrukturze chmury lub w celach dotyczących ocen i rozwoju na komputerze osobistym. Bramę hostowaną samodzielnie można również wdrożyć jako rozszerzenie klastra w klastrze platformy Kubernetes z obsługą usługi Azure Arc.

Obrazy kontenerów

Udostępniamy różne obrazy kontenerów dla bram hostowanych samodzielnie, aby spełnić Twoje potrzeby:

Konwencja tagów Zalecenie Przykład Tag kroczący Zalecane w środowisku produkcyjnym
{major}.{minor}.{patch} Użyj tego tagu, aby zawsze uruchamiać tę samą wersję bramy 2.0.0 ❌ ✔️
v{major} Użyj tego tagu, aby zawsze uruchamiać wersję główną bramy z każdą nową funkcją i poprawką. v2 ✔️ ❌
v{major}-preview Użyj tego tagu, jeśli zawsze chcesz uruchomić nasz najnowszy obraz kontenera w wersji zapoznawczej. v2-preview ✔️ ❌
latest Użyj tego tagu, jeśli chcesz ocenić bramę hostowaną samodzielnie. latest ✔️ ❌
beta1 Użyj tego tagu, jeśli chcesz ocenić wersje zapoznawcza bramy hostowanej samodzielnie. beta ✔️ ❌

Pełną listę dostępnych tagów można znaleźć tutaj.

1Wersje zapoznawcza nie są oficjalnie obsługiwane i są przeznaczone tylko do celów eksperymentalnych. Zobacz zasady obsługi własnej bramy.

Używanie tagów w naszych oficjalnych opcjach wdrażania

Nasze opcje wdrażania w witrynie Azure Portal używają tagu v2 , który umożliwia klientom korzystanie z najnowszej wersji obrazu kontenera bramy własnej bramy w wersji 2 ze wszystkimi aktualizacjami funkcji i poprawkami.

Uwaga

Udostępniamy polecenia i fragmenty kodu YAML jako odwołanie. Jeśli chcesz, możesz użyć bardziej szczegółowego tagu.

Podczas instalowania za pomocą naszego wykresu Helm tagowanie obrazów jest zoptymalizowane pod kątem Ciebie. Wersja aplikacji pakietu Helm przypina bramę do danej wersji i nie korzysta z elementu latest.

Dowiedz się więcej na temat sposobu instalowania własnej bramy usługi API Management na platformie Kubernetes przy użyciu programu Helm.

Ryzyko użycia tagów rolowych

Tagi stopniowe to tagi, które są potencjalnie aktualizowane po wydaniu nowej wersji obrazu kontenera. Dzięki temu użytkownicy kontenerów mogą odbierać aktualizacje obrazu kontenera bez konieczności aktualizowania ich wdrożeń.

Oznacza to, że można potencjalnie uruchamiać różne wersje równolegle bez zauważenia go, na przykład podczas wykonywania akcji skalowania po v2 zaktualizowaniu tagu.

Przykład — v2 tag został wydany z obrazem 2.0.0 kontenera, ale gdy 2.1.0 zostanie wydany, v2 tag zostanie połączony z obrazem 2.1.0 .

Ważne

Rozważ użycie określonego tagu wersji w środowisku produkcyjnym, aby uniknąć niezamierzonego uaktualnienia do nowszej wersji.

Łączność z platformą Azure

Bramy hostowane samodzielnie wymagają wychodzącej łączności protokołów TCP/IP z platformą Azure na porcie 443. Każda brama hostowana samodzielnie musi być skojarzona z jedną usługą API Management i skonfigurowana za pośrednictwem jej płaszczyzny zarządzania. Brama hostowana samodzielnie używa łączności z platformą Azure w celu:

  • Raportowania swojego stanu przez wysyłanie komunikatów pulsu co minutę
  • Regularnego sprawdzania (co 10 sekund) i stosowania aktualizacji konfiguracji za każdym razem, gdy są dostępne
  • Wysyłania metryk do usługi Azure Monitor, jeśli została ta opcja skonfigurowana
  • Wysyłania zdarzeń do usługi Application Insights, jeśli została ta opcja ustawiona

Zależności nazwy FQDN

Aby działać prawidłowo, każda brama hostowana samodzielnie wymaga łączności wychodzącej na porcie 443 do następujących punktów końcowych skojarzonych z wystąpieniem usługi API Management opartym na chmurze:

opis Wymagane dla wersji 1 Wymagane dla wersji 2 Uwagi
Nazwa hosta punktu końcowego konfiguracji <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net1 Niestandardowe nazwy hostów są również obsługiwane i mogą być używane zamiast domyślnej nazwy hosta.
Publiczny adres IP wystąpienia usługi API Management ✔️ ✔️ Adres IP lokalizacji podstawowej jest wystarczający.
Publiczne adresy IP tagu usługi Azure Storage ✔️ Opcjonalne2 Adresy IP muszą odpowiadać podstawowej lokalizacji wystąpienia usługi API Management.
Nazwa hosta konta usługi Azure Blob Storage ✔️ Opcjonalne2 Konto skojarzone z wystąpieniem (<blob-storage-account-name>.blob.core.windows.net)
Nazwa hosta konta usługi Azure Table Storage ✔️ Opcjonalne2 Konto skojarzone z wystąpieniem (<table-storage-account-name>.table.core.windows.net)
Punkty końcowe dla usługi Azure Resource Manager ✔️ Opcjonalne3 Wymagane punkty końcowe to management.azure.com.
Punkty końcowe dla integracji z firmą Microsoft Entra ✔️ Opcjonalnie4 Wymagane punkty końcowe to <region>.login.microsoft.com i login.microsoftonline.com.
Punkty końcowe na potrzeby integracji z usługą aplikacja systemu Azure Insights Opcjonalnie5 Opcjonalnie5 Minimalne wymagane punkty końcowe to:
  • rt.services.visualstudio.com:443
  • dc.services.visualstudio.com:443
  • {region}.livediagnostics.monitor.azure.com:443
Dowiedz się więcej w dokumentacji usługi Azure Monitor
Punkty końcowe na potrzeby integracji z usługą Event Hubs Opcjonalnie5 Opcjonalnie5 Dowiedz się więcej w dokumentacji usługi Azure Event Hubs
Punkty końcowe na potrzeby integracji zewnętrznej pamięci podręcznej Opcjonalnie5 Opcjonalnie5 To wymaganie zależy od używanej zewnętrznej pamięci podręcznej

1W przypadku wystąpienia usługi API Management w wewnętrznej sieci wirtualnej zobacz Łączność w wewnętrznej sieci wirtualnej.
2 Wymagane tylko w wersji 2, gdy inspektor interfejsu API lub przydziały są używane w zasadach.
3Wymagane tylko w przypadku korzystania z uwierzytelniania entra firmy Microsoft w celu zweryfikowania uprawnień RBAC.
4Wymagane tylko w przypadku korzystania z uwierzytelniania Microsoft Entra lub zasad związanych z firmą Microsoft Entra.
5Wymagane tylko wtedy, gdy funkcja jest używana i wymaga informacji o publicznym adresie IP, porcie i nazwie hosta.

Ważne

  • Nazwy hostów DNS muszą być rozpoznawane jako adresy IP, a odpowiednie adresy IP muszą być osiągalne.
  • Skojarzone nazwy kont magazynu są wyświetlane na stronie Stan łączności sieciowej usługi w witrynie Azure Portal.
  • Publiczne adresy IP bazowe skojarzonych kont magazynu są dynamiczne i mogą ulec zmianie bez powiadomienia.

Łączność w wewnętrznej sieci wirtualnej

  • Łączność prywatna — jeśli brama self-hosted jest wdrożona w sieci wirtualnej, włącz prywatną łączność z punktem końcowym konfiguracji w wersji 2 z lokalizacji własnej bramy, na przykład przy użyciu prywatnego systemu DNS w sieci równorzędnej.

  • Łączność z Internetem — jeśli brama hostowana samodzielnie musi połączyć się z punktem końcowym konfiguracji w wersji 2 za pośrednictwem Internetu, skonfiguruj niestandardową nazwę hosta dla punktu końcowego konfiguracji i uwidocznij punkt końcowy przy użyciu usługi Application Gateway.

Opcje uwierzytelniania

Aby uwierzytelnić połączenie między własną bramą a punktem końcowym konfiguracji wystąpienia usługi API Management opartego na chmurze, w ustawieniach konfiguracji kontenera bramy są dostępne następujące opcje.

Opcja Kwestie wymagające rozważenia
Uwierzytelnianie Microsoft Entra Konfigurowanie co najmniej jednej aplikacji firmy Microsoft Entra na potrzeby dostępu do bramy

Zarządzanie dostępem oddzielnie na aplikację

Konfigurowanie dłuższych czasów wygaśnięcia dla wpisów tajnych zgodnie z zasadami organizacji

Używanie standardowych procedur firmy Microsoft Entra do przypisywania lub odwołowywania uprawnień użytkowników lub grup do aplikacji oraz rotacji wpisów tajnych
Token dostępu bramy (nazywany również kluczem uwierzytelniania) Token wygasa co 30 dni i musi zostać odnowiony w kontenerach

Wspierane przez klucz bramy, który można obracać niezależnie (na przykład w celu odwołania dostępu)

Ponowne generowanie klucza bramy powoduje unieważnienie wszystkich utworzonych za jego pomocą tokenów dostępu

Błędy łączności

W przypadku utraty łączności z platformą Azure brama self-hosted nie może odbierać aktualizacji konfiguracji, zgłaszać jego stanu lub przekazywać dane telemetryczne.

Brama hostowana samodzielnie jest przeznaczona do "awarii statycznej" i może przetrwać tymczasową utratę łączności z platformą Azure. Można go wdrożyć z lokalną kopią zapasową konfiguracji lub bez niej. Dzięki kopii zapasowej konfiguracji bramy hostowane samodzielnie regularnie zapisują kopię zapasową najnowszej pobranej konfiguracji na trwałym woluminie dołączonym do kontenera lub zasobnika.

Po wyłączeniu kopii zapasowej konfiguracji i przerwaniu łączności z platformą Azure:

  • Uruchamianie własnych bram będzie nadal działać przy użyciu kopii w pamięci konfiguracji
  • Zatrzymane bramy self-hosted nie będą mogły uruchomić

Po włączeniu kopii zapasowej konfiguracji i przerwaniu łączności z platformą Azure:

  • Uruchamianie własnych bram będzie nadal działać przy użyciu kopii w pamięci konfiguracji
  • Zatrzymane bramy self-hosted będą mogły rozpocząć korzystanie z kopii zapasowej konfiguracji

Po przywróceniu łączności każda własna brama, której dotyczy awaria, automatycznie połączy się ponownie ze skojarzą usługą API Management i pobierze wszystkie aktualizacje konfiguracji, które wystąpiły, gdy brama była "w trybie offline".

Zabezpieczenia

Ograniczenia

Następujące funkcje znalezione w bramach zarządzanych nie są dostępne w bramach hostowanych samodzielnie:

  • Wznowienie sesji PROTOKOŁU TLS.
  • Renegocjacja certyfikatu klienta. Aby korzystać z uwierzytelniania certyfikatu klienta, użytkownicy interfejsu API muszą przedstawić swoje certyfikaty w ramach początkowego uzgadniania protokołu TLS. Aby zapewnić to zachowanie, włącz ustawienie Negocjuj certyfikat klienta podczas konfigurowania niestandardowej nazwy hosta bramy (nazwy domeny).

Transport Layer Security (TLS)

Ważne

To omówienie dotyczy tylko własnej bramy w wersji 1 i 2.

Obsługiwane protokoły

Brama hostowana samodzielnie zapewnia domyślnie obsługę protokołu TLS w wersji 1.2.

Klienci korzystający z domen niestandardowych mogą włączyć protokół TLS w wersji 1.0 i/lub 1.1 na płaszczyźnie sterowania.

Dostępne zestawy szyfrowania

Ważne

To omówienie dotyczy tylko własnej bramy w wersji 2.

Brama hostowana samodzielnie używa następujących zestawów szyfrowania dla połączeń klienta i serwera:

  • 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

Zarządzanie zestawami szyfrowania

Od wersji 2.1.1 lub nowszej można zarządzać szyframi używanymi w ramach konfiguracji:

  • net.server.tls.ciphers.allowed-suites Umożliwia zdefiniowanie rozdzielanej przecinkami listy szyfrów używanych na potrzeby połączenia TLS między klientem interfejsu API a bramą hostowaną samodzielnie.
  • net.client.tls.ciphers.allowed-suites Umożliwia zdefiniowanie rozdzielanej przecinkami listy szyfrów używanych na potrzeby połączenia TLS między własną bramą a zapleczem.

Następne kroki