自我裝載閘道概觀

適用於:開發人員 |進階版

自我裝載閘道是每個 API 管理服務中包含的預設受控閘道選用的容器化版本。 舉例而言,要將閘道放在裝載 API 的相同環境時,其效用就可發揮。 使用自我裝載閘道可改善 API 流量,以及因應 API 安全性和合規性需求。

本文說明 Azure APIM 的自我裝載閘道功能如何啟用混合式和多雲端 APIM、呈現其高階架構,並重點展現其功能。

若要認識各種閘道供應項目的功能,請參閱 API 管理中的 API 閘道

混合式與多雲端管理 API

自我裝載閘道功能可擴充混合式和多雲端環境的API 管理支援,讓組織能夠從 Azure 中的單一API 管理服務有效率且安全地管理裝載於內部部署和跨雲端的 API。

有了自我裝載閘道,客戶就可以彈性地將容器化版本的 API 管理閘道元件部署到裝載客戶 API 的相同環境。 所有自我裝載閘道都是從與其同盟的 API 管理服務來進行管理,因此可為客戶在所有內部和外部 API 提供可見度和統一管理的體驗。

每個 API 管理服務都是由下列的重要元件所組成:

  • 管理平面,其公開為 API,可用來透過 Azure 入口網站、PowerShell 和其他支援的機制來設定服務。
  • 閘道 (或資料平面),其負責 Proxy API 要求、套用原則及收集遙測
  • 開發人員用來探索、學習及上線以使用 API 的開發人員入口網站

根據預設,所有這些元件都會部署在 Azure 中,這導致不論實作 API 的後端裝載於何處,所有 API 流量 (如下圖所示的實心黑色箭號) 都會流經 Azure。 此模型簡化了操作,代價是延遲增加、合規性問題,而且在某些情況下會收取額外的資料傳輸費用。

沒有自我裝載閘道的 API 流量流程

針對裝載後端 API 的實作環境,將自我裝載閘道部署至與之相同的環境可讓 API 流量直接流向後端 API,這可降低延遲、最佳化資料傳輸成本,並啟用合規性,同時保有單一管理點、可觀察性,以及能夠探索組織內所有 API 而不論其實作裝載於何處等優點。

使用自我裝載閘道的 API 流量流程

包裝

可從 Microsoft Artifact Registry 將自我裝載閘道做為以 Linux 為基礎的 Docker 容器映像來使用。 可以將其部署至 Docker、Kubernetes 或任何其他在內部部署伺服器叢集上執行的容器協調流程解決方案、雲端基礎結構,或將其部署用於個人電腦上的評估和開發用途。 您也可以將自我裝載閘道部署至已啟用 Azure Arc 的 Kubernetes 叢集,做為叢集延伸模組。

容器映像

我們會提供各種容器映像,讓自我裝載閘道符合您的需求:

標籤慣例 建議 範例 輪替標籤 建議用於生產環境
{major}.{minor}.{patch} 使用此標籤來一律執行相同版本的閘道 2.0.0 ✔️
v{major} 使用此標籤,一律以每個新功能和修補檔來執行閘道的主要版本。 v2 ✔️
v{major}-preview 如果您想要一律執行我們最新的預覽容器映像,請使用此標籤。 v2-preview ✔️
latest 如果您想要評估自我裝載閘道,請使用此標籤。 latest ✔️
beta1 如果您想要評估自我裝載閘道預覽版,則請使用此標記。 beta ✔️

您可以在此找到完整的可用標籤清單。

1預覽版未正式支援,僅供實驗之用。 請參閱自我裝載閘道支援原則

在我們的官方部署選項中使用標籤

Azure 入口網站中的部署選項會使用 v2 標籤,其可讓客戶搭配所有功能更新和修補檔使用最新版本的自我裝載閘道 v2 容器映像。

注意

我們會提供命令和 YAML 程式碼片段做為參考,如果您想要的話,也可以放心使用更明確的標記。

使用 Helm 圖表進行安裝時,會為您最佳化映像標記。 Helm 圖表的應用程式版本會將網路閘道釘選到指定的版本,而且不依賴 latest

深入了解如何使用 Helm 在 Kubernetes 上安裝 APIM 自我裝載閘道

使用輪替標籤的風險

輪替標籤是發行新版本容器映像時可能會更新的標籤。 這可讓容器使用者接收容器映像的更新,而不需要更新其部署。

這表示您可以平行執行不同的版本,而不會注意到這點,例如當您在 v2 標籤更新後執行調整動作時。

範例 - v2 標籤已隨著 2.0.0 容器映像發行,但當 2.1.0 發行時,v2 標籤將會連結至 2.1.0 映像。

重要

請考量在實際執行環境中使用特定的版本標籤,以避免意外升級至較新版本。

Azure 的連線能力

自我裝載閘道需要在連接埠 443 上對 Azure 輸出 TCP/IP 連線。 每個自我裝載閘道都必須與單一API 管理服務相關聯,並能透過其管理平面進行設定。 自我裝載閘道會使用與 Azure 的連線,以便:

  • 每分鐘傳送活動訊號訊息,以便報告其狀態
  • 定期檢查 (每 10 秒) 設定更新,並在每次有可用更新時進行套用
  • 將計量傳送至 Azure 監視器 (若有設定)
  • 將事件傳送至 Application Insights (若有設定)

重要

對 Azure APIM 自我裝載閘道第 0 版和第 1 版容器映像的支援,以及其對應的設定 API v1,將於 2023 年 10 月 1 日結束。 使用我們的移轉指南,搭配設定 API v2 使用自我裝載閘道 v2.0.0 或更高版本。 在我們的淘汰文件中深入瞭解

FQDN 相依性

若要正常運作,每個自我裝載閘道都需要在連接埠 443 上輸出連線至與其雲端式 API 管理執行個體相關聯的下列端點:

描述 v1 的必要項目 v2 的必要項目 備註
設定端點的主機名稱 <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net1 也支援並且可以使用自訂主機名稱,而不是預設主機名稱。
API 管理執行個體的公用 IP 位址 ✔️ ✔️ 主要位置的 IP 位址就已足夠。
Azure 儲存體服務標籤的公用 IP 位址 ✔️ 選擇性2 IP 位址必須對應至 API 管理執行個體的主要位置。
Azure Blob 儲存體帳戶的主機名稱 ✔️ 選擇性2 與執行個體相關聯的帳戶 (<blob-storage-account-name>.blob.core.windows.net)
Azure 資料表儲存體帳戶的主機名稱 ✔️ 選擇性2 與執行個體相關聯的帳戶 (<table-storage-account-name>.table.core.windows.net)
Azure Resource Manager 的端點 ✔️ 選用3 必要端點為 management.azure.com
Microsoft Entra 整合的端點 ✔️ 選用4 必要端點為 <region>.login.microsoft.comlogin.microsoftonline.com
適用於 Azure Application Insights 整合的端點 選用5 選用5 必要端點的最低數目為:
  • rt.services.visualstudio.com:443
  • dc.services.visualstudio.com:443
  • {region}.livediagnostics.monitor.azure.com:443
Azure 監視器文件中深入了解
適用於事件中樞整合的端點 選用5 選用5 Azure 事件中樞文件中深入了解
適用於外部快取整合的端點 選用5 選用5 此需求取決於正在使用的外部快取

1針對內部虛擬網路中的 APIM 執行個體,啟用從自我裝載閘道的位置到 v2 設定端點的私人連線,例如,在對等互連網路中使用私人 DNS。
2只有在原則中使用 API 偵測器或配額時,v2 中才需要。
3只有在使用 Microsoft Entra 驗證來驗證 RBAC 權限時才需要。
4只有在使用 Microsoft Entra 驗證或 Microsoft Entra 相關原則時才需要。
5只有在使用功能且需要公用 IP 位址、連接埠和主機名稱資訊時才需要。

重要

  • DNS 主機名稱必須可解析為 IP 位址,而且必須可觸達對應的 IP 位址。
  • 相關聯的儲存體帳戶名稱會列在Azure 入口網站中服務的 [網路連線狀態] 頁面中。
  • 相關聯儲存體帳戶下的公用 IP 位址是動態的,且可能在不另行通知的情況下變更。

驗證選項

若要驗證自我裝載閘道與雲端式 APIM 執行個體設定端點之間的連線,您在閘道容器的組態設定中具有下列選項。

選項 考量
Microsoft Entra 驗證 設定一或多個 Microsoft Entra 應用程式以存取閘道

個別管理每個應用程式的存取權

根據組織的原則,針對祕密設定較長的到期時間

使用標準 Microsoft Entra 程序來指派或撤銷應用程式的使用者或群組權限,以及輪替祕密

閘道存取權杖 (也稱為驗證金鑰) 權杖最多每 30 天到期一次,而且必須在容器中續約

由可獨立輪替的閘道金鑰所支援 (例如,撤銷存取權)

重新產生閘道金鑰會讓所有使用它所建立的存取權杖失效

連線失敗

當 Azure 的連線中斷時,自我裝載閘道無法接收設定更新、報告其狀態或上傳遙測。

自我裝載閘道是針對「靜態失敗」而設計的,而且可以暫時承受與 Azure 之間的連線中斷。 您可以使用或不使用本機設定備份來部署自我裝載閘道。 透過設定備份,自我裝載閘道會定期針對最新下載的設定,將設定的備份複本儲存在其容器或 Pod 附加的永續性磁碟區上。

當備份關閉且 Azure 的連線中斷時:

  • 執行自我裝載閘道將使用設定的記憶體內部複本繼續運作
  • 已停止的自我裝載閘道將無法啟動

當備份開啟且 Azure 的連線中斷時:

  • 執行自我裝載閘道將使用設定的記憶體內部複本繼續運作
  • 已停止的自我裝載閘道將能夠開始使用設定的備份複本

還原連線時,受中斷影響的每個自我裝載閘道都會自動與其相關聯的API 管理服務重新連線,並下載閘道「離線」時發生的所有設定更新。

安全性

限制

在受控閘道中找到的下列功能在自我裝載閘道中無法使用

  • TLS 工作階段繼續。
  • 用戶端憑證重新交涉。 若要使用用戶端憑證驗證,API 取用者必須將其憑證展現為初始 TLS 交握的一部分。 若要確保此行為,請在設定自我裝載閘道的自訂主機名稱 (網域名稱) 時啟用「交涉用戶端憑證」設定。

傳輸層安全性 (TLS)

重要

此概觀僅適用於自我裝載閘道 v1 和 v2。

支援的通訊協定

根據預設,自我裝載閘道會為 TLS v1.2 提供支援。

使用自訂網域的客戶可以在控制平面中啟用 TLS v1.0 和/或 v1.1。

可用的加密套件

重要

此概觀僅適用於自我裝載閘道 v2。

自我裝載閘道會針對用戶端和伺服器連線使用下列加密套件:

  • 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

管理加密套件

從 v2.1.1 和更新版本開始,您可以管理透過設定使用的加密:

  • net.server.tls.ciphers.allowed-suites 可讓您定義以逗號分隔的加密清單,以便使用 API 用戶端與自我裝載閘道之間的 TLS 連線。
  • net.client.tls.ciphers.allowed-suites 可讓您定義以逗號分隔的加密清單,以便使用自我裝載閘道與後端之間的 TLS 連線。

下一步