Udostępnij za pośrednictwem

Omówienie bramy hostowanej lokalnie

DOTYCZY: Developer | Premium

Brama samodzielnie hostowana jest opcjonalną, konteneryzowaną wersją domyślnej bramy zarządzanej, która jest uwzględniona w każdej usłudze zarządzania interfejsem API. 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 hybrydowym i multicloud interfejsem API

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 przekazywanie żądań API przez serwer proxy, stosowanie polityk i zbieranie danych telemetrycznych.
  • Portal deweloperów używany przez deweloperów do odkrywania, nauki i wdrażania się w używanie interfejsów API.

Domyślnie wszystkie te składniki są wdrażane na platformie Azure, powodując, że cały ruch API (pokazany jako solidne czarne strzałki na poniższej ilustracji) przepływa przez platformę Azure, niezależnie od tego, gdzie są hostowane zaplecza obsługujące 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 bram hostowanych samodzielnie

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 samodzielnie hostowanymi bramami

Opakowanie

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 ruchomy Zalecane do produkcji
{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ć główną wersję bramy z każdą nową funkcjonalnością 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 ✔️ ❌
beta 1 Użyj tego tagu, jeśli chcesz ocenić wersje zapoznawcze bramy samodzielnie hostowanej. 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 polityki wsparcia dla samodzielnie hostowanej bramy.

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

Nasze opcje wdrażania w portalu Azure używają tagu v2, który umożliwia klientom korzystanie z najnowszej wersji obrazu kontenera bramy własnej w wersji 2 z 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 Helm chartu tagowanie obrazów jest zoptymalizowane dla Twojej wygody. Wersja aplikacji pakietu Helm przypisuje bramę do określonej wersji i nie polega na 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 przemieszczających się tagów

Tagi aktualizowane na bieżąco 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 — tag v2 został wydany z obrazem kontenera 2.0.0, ale gdy 2.1.0 zostanie wydany, tag v2 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ę
  • Regularne sprawdzanie (co 10 sekund) i stosowanie aktualizacji konfiguracji, gdy tylko 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:

Punkt końcowy Wymagane? Uwagi
Nazwa hosta punktu końcowego konfiguracji <apim-service-name>.configuration.azure-api.net 1 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 Microsoft Entra Opcjonalnie4 Wymagane punkty końcowe to <region>.login.microsoft.com i login.microsoftonline.com.
Punkty końcowe dla integracji z Azure Application Insights 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 Dowiedz się więcej w dokumentacji usługi Azure Event Hubs
Punkty końcowe na potrzeby integracji zewnętrznej pamięci podręcznej 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 w zasadach używany jest inspektor API lub przydziały.
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 Stanu łączności sieciowej usługi w portalu Azure.
  • 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 samodzielnie hostowana jest wdrożona w sieci wirtualnej, włącz prywatną łączność z punktem końcowym konfiguracji w wersji v2 z lokalizacji bramy samodzielnie hostowanej, na przykład przy użyciu prywatnego systemu DNS w sieci oktopowej.

  • Łą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 samodzielnie hostowaną bramą a punktem końcowym konfiguracji wystąpienia usługi API Management opartego na chmurze, w ustawieniach konfiguracji kontenera bramki masz 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 dla każdej aplikacji osobno

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

Wskazówka

Zobacz Usługa Azure API Management jako źródło usługi Event Grid, aby uzyskać informacje o zdarzeniach usługi Event Grid generowanych przez bramę samodzielnie hostowaną, gdy token dostępu bramy zbliża się do wygaśnięcia lub wygasł. Użyj tych zdarzeń, aby upewnić się, że wdrożone bramy zawsze mogą się uwierzytelniać za pomocą skojarzonej instancji usługi zarządzania interfejsami API.

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 lokalna jest zaprojektowana tak, aby działać w trybie 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. Tworzenie kopii zapasowej konfiguracji pozwala, aby bramy samodzielnie hostowane regularnie zapisywały kopię najnowszej pobranej konfiguracji na trwałym woluminie dołączonym do ich kontenera lub podu.

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

  • Kontynuowanie działania własnych bram będzie odbywać się przy użyciu kopi konfiguracji w pamięci.
  • Zatrzymane bramy samodzielnie hostowane nie będą mogły się uruchomić ponownie.

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

  • Kontynuowanie działania własnych bram będzie odbywać się przy użyciu kopi konfiguracji w pamięci.
  • Zatrzymane bramy hostowane lokalnie będą mogły rozpocząć korzystanie z konfiguracji z kopii zapasowej.

Po przywróceniu łączności, każda samodzielnie hostowana brama, której dotyczyła awaria, automatycznie połączy się ponownie ze swoją powiązaną usługą API Management i pobierze wszystkie aktualizacje konfiguracji, które pojawiły się, 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 TLS.
  • Renegocjacja certyfikatu klienta. Aby korzystać z uwierzytelniania certyfikatem klienta, konsumenci 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 domeny dla lokalnie hostowanej bramy.

Bezpieczeństwo warstwy transportowej (TLS)

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

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.

Powiązana zawartość