Gambaran umum gateway yang dihosting sendiri

  • Artikel

BERLAKU UNTUK: Pengembang | Premium

Gateway yang dihosting sendiri adalah gateway terkelola default versi opsional yang terkontainerisasi yang disertakan dalam setiap layanan API Management. Ini berguna untuk skenario seperti menempatkan gateway di lingkungan yang sama tempat Anda menghosting API. Gunakan gateway yang dihosting sendiri untuk meningkatkan arus lalu lintas API dan mengatasi persyaratan kepatuhan dan keamanan API.

Artikel ini menjelaskan bagaimana fitur gateway yang dihost sendiri dari Azure API Management memungkinkan manajemen API hibrid dan multicloud, menyajikan arsitektur tingkat tinggi, dan menyoroti kemampuannya.

Untuk gambaran umum fitur di berbagai penawaran gateway, lihat Gateway API di API Management.

Manajemen API hibrid dan multi-cloud

Fitur gateway yang di-host sendiri memperluas dukungan API Management untuk lingkungan hibrid dan multi-cloud serta memungkinkan organisasi untuk secara efisien dan aman mengelola API yang di-host secara lokal dan lintas cloud dari satu layanan API Management di Azure.

Dengan gateway yang dihosting sendiri, pelanggan memiliki fleksibilitas untuk menerapkan versi komponen gateway API Management ke dalam lingkungan yang sama tempat mereka menghosting API-nya. Semua gateway yang dihosting sendiri dikelola dari layanan API Management tempat mereka digabungkan, sehingga memberikan visibilitas dan pengalaman pengelolaan terpadu pada semua API internal dan eksternal kepada pelanggan.

Setiap layanan API Management terdiri dari komponen utama berikut:

  • Bidang manajemen, diekspos sebagai API, digunakan untuk mengonfigurasi layanan melalui portal Azure, PowerShell, dan mekanisme lain yang didukung.
  • Gateway (atau data plane), yang bertanggung jawab untuk membuat proksi permintaan API, menerapkan kebijakan, dan mengumpulkan telemetri
  • Portal pengembang yang digunakan oleh pengembang untuk menemukan, belajar, dan onboard untuk menggunakan API

Secara default, semua komponen ini disebarkan di Azure, menyebabkan semua lalu lintas API (ditampilkan sebagai panah hitam utuh pada gambar berikut) mengalir melalui Azure terlepas di mana backend yang menerapkan API dihosting. Kesederhanaan operasional model ini menyebabkan peningkatan latensi, masalah kepatuhan, dan dalam beberapa kasus, biaya transfer data tambahan.

Arus lalu lintas API tanpa gateway yang dihosting sendiri

Dengan menyebarkan gateway yang dihost sendiri ke dalam lingkungan yang sama tempat implementasi API backend dihosting, lalu lintas API dapat mengalir langsung ke API backend, yang mengurangi latensi, mengoptimalkan biaya transfer data, dan mengaktifkan kepatuhan sambil tetap mempertahankan keuntungan memiliki titik tunggal manajemen, observabilitas, dan penemuan semua API dalam organisasi terlepas dari di mana penerapannya dihosting.

Arus lalu lintas API dengan gateway yang dihosting sendiri

Pengemasan

Gateway yang dihost sendiri tersedia sebagai gambar kontainer Docker berbasis-Linux dari Microsoft Artifact Registry. Hal ini dapat diterapkan ke Docker, Kubernetes, atau solusi orkestrasi kontainer lainnya yang berjalan di cluster server di lokasi, infrastruktur cloud, atau untuk tujuan evaluasi dan pengembangan, di komputer pribadi. Anda juga dapat menyebarkan gateway yang dihost sendiri ke kluster Kube berkemampuan Azure Arc.

Gambar kontainer

Kami menyediakan berbagai citra kontainer untuk gateway yang dihost sendiri guna memenuhi kebutuhan Anda:

Konvensi tag Rekomendasi Contoh Tag bergulir Direkomendasikan untuk produksi
{major}.{minor}.{patch} Gunakan tag berikut ini untuk selalu menjalankan versi gateway yang sama 2.0.0 ❌ ✔️
v{major} Gunakan tag ini untuk selalu menjalankan versi besar gateway dengan setiap fitur dan patch baru. v2 ✔️ ❌
v{major}-preview Gunakan tag ini jika Anda selalu ingin menjalankan citra kontainer pratinjau terbaru kami. v2-preview ✔️ ❌
latest Gunakan tag ini jika Anda ingin mengevaluasi gateway yang dihost sendiri. latest ✔️ ❌
beta1 Gunakan tag ini jika Anda ingin mengevaluasi versi pratinjau gateway yang dihost sendiri. beta ✔️ ❌

Anda dapat menemukan daftar penuh tag yang tersedia di sini.

1Versi pratinjau tidak didukung secara resmi dan hanya untuk tujuan eksperimental. Lihat kebijakan dukungan gateway yang dihost sendiri.

Penggunaan tag dalam opsi penyebaran resmi kami

Opsi penyebaran kami pada portal Microsoft Azure menggunakan tag v2, yang memungkinkan pelanggan menggunakan versi terbaru dari gambar kontainer v2 gateway yang dihost sendiri dengan semua pembaruan fitur dan patch.

Catatan

Kami menyediakan perintah dan cuplikan YAML sebagai referensi, jangan ragu untuk menggunakan tag yang lebih spesifik jika Anda ingin.

Saat menginstal dengan bagan Helm kami, pemberian tag citra dioptimalkan untuk Anda. Versi aplikasi bagan Helm menyematkan gateway pada versi yang diberikan serta tidak bergantung pada latest.

Pelajari selengkapnya cara menginstal gateway API Management yang dihost sendiri di Kubernetes dengan Helm.

Risiko menggunakan tag bergulir

Tag bergulir adalah tag yang dapat diperbarui saat versi baru citra kontainer dirilis. Ini memungkinkan pengguna kontainer untuk menerima pembaruan pada citra kontainer tanpa harus memperbarui penyebaran mereka.

Artinya, Anda dapat menjalankan versi yang berbeda secara paralel tanpa melihatnya, misalnya ketika Anda melakukan tindakan penskalaan setelah tag v2 diperbarui.

Contoh - tag v2 dirilis dengan citra kontainer 2.0.0, tetapi saat 2.1.0 akan dirilis, tag v2 akan ditautkan ke citra 2.1.0.

Penting

Pertimbangkan untuk menggunakan tag versi tertentu dalam produksi untuk menghindari peningkatan yang tidak disengaja ke versi yang lebih baru.

Konektivitas ke Azure

Gateway yang dihosting sendiri memerlukan konektivitas TCP/IP keluar ke Azure pada port 443. Setiap gateway yang dihosting sendiri harus dikaitkan dengan satu layanan API Management dan dikonfigurasi melalui bidang pengelolaannya. Gateway yang dihost sendiri menggunakan konektivitas ke Azure untuk:

  • Melaporkan statusnya dengan mengirimkan pesan heartbeat setiap menit
  • Secara teratur memeriksa (setiap 10 detik) serta menerapkan pembaruan konfigurasi setiap kali tersedia
  • Mengirim metrik ke Azure Monitor, jika dikonfigurasi untuk melakukannya
  • Mengirim kejadian ke Application Insights, jika disetel untuk melakukannya

Penting

Dukungan untuk gateway yang dihost sendiri Azure API Management versi 0 dan gambar kontainer versi 1 berakhir pada 1 Oktober 2023, bersama dengan Api Konfigurasi v1 yang sesuai. Gunakan panduan migrasi kami untuk menggunakan gateway yang dihost sendiri v2.0.0 atau yang lebih tinggi dengan Configuration API v2. Pelajari lebih lanjut dalam dokumentasi penghentian kami

dependensi FQDN

Untuk mengoperasikannya dengan benar, setiap gateway yang dihost sendiri memerlukan konektivitas keluar pada port 443 ke titik akhir berikut yang terkait dengan instans API Management berbasis-cloudnya:

Deskripsi Diperlukan untuk v1 Diperlukan untuk v2 Catatan
Nama host titik akhir konfigurasi <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net1 Nama host kustom juga didukung dan dapat digunakan alih-alih nama host default.
Alamat IP publik instans API Management ✔️ ✔️ Alamat IP lokasi utama sudah cukup.
Alamat IP publik tag layanan Azure Storage ✔️ Opsional2 Alamat IP harus sesuai dengan lokasi utama instans API Management.
Nama host akun Azure Blob Storage ✔️ Opsional2 Akun yang terkait dengan instans (<blob-storage-account-name>.blob.core.windows.net)
Nama host akun Azure Table Storage ✔️ Opsional2 Akun yang terkait dengan instans (<table-storage-account-name>.table.core.windows.net)
Titik akhir untuk Azure Resource Manager ✔️ Opsional3 Titik akhir yang diperlukan adalah management.azure.com.
Titik akhir untuk integrasi Microsoft Entra ✔️ Opsional4 Titik akhir yang diperlukan adalah <region>.login.microsoft.com dan login.microsoftonline.com.
Titik akhir untuk integrasi Azure Application Insights Opsional5 Opsional5 Titik akhir minimal yang diperlukan adalah:
  • rt.services.visualstudio.com:443
  • dc.services.visualstudio.com:443
  • {region}.livediagnostics.monitor.azure.com:443
Pelajari selengkapnya di dokumen Azure Monitor
Titik akhir untuk integrasi Azure Event Hubs Opsional5 Opsional5 Pelajari selengkapnya di dokumen Azure Event Hubs
Titik akhir untuk integrasi cache eksternal Opsional5 Opsional5 Persyaratan ini tergantung pada cache eksternal yang sedang digunakan

1Untuk instans API Management di jaringan virtual internal, aktifkan konektivitas privat ke titik akhir konfigurasi v2 dari lokasi gateway yang dihost sendiri, misalnya, menggunakan DNS privat di jaringan yang di-peering.
2Hanya diperlukan di v2 saat pemeriksa API atau kuota digunakan dalam kebijakan.
3Hanya diperlukan saat menggunakan autentikasi Microsoft Entra untuk memverifikasi izin RBAC.
4Hanya diperlukan saat menggunakan autentikasi Microsoft Entra atau kebijakan terkait Microsoft Entra.
5Hanya diperlukan saat fitur digunakan dan memerlukan alamat IP publik, port, dan informasi nama host.

Penting

  • Nama host DNS harus dapat diperbaiki ke alamat IP dan alamat IP yang sesuai harus dapat dijangkau.
  • Nama akun penyimpanan terkait terdaftar di halaman Status konektivitas jaringan layanan di portal Azure.
  • Alamat IP publik yang mendasari akun penyimpanan terkait bersifat dinamis dan dapat berubah tanpa pemberitahuan.

Opsi autentikasi

Untuk mengautentikasi koneksi antara gateway yang dihost sendiri dan titik akhir konfigurasi instans API Management berbasis cloud, Anda memiliki opsi berikut di pengaturan konfigurasi kontainer gateway.

Opsi Pertimbangan
Autentikasi Microsoft Entra Mengonfigurasi satu atau beberapa aplikasi Microsoft Entra untuk akses ke gateway

Mengelola akses secara terpisah per aplikasi

Mengonfigurasi waktu kedaluwarsa yang lebih lama untuk rahasia sesuai dengan kebijakan organisasi Anda

Gunakan prosedur Microsoft Entra standar untuk menetapkan atau mencabut izin pengguna atau grup ke aplikasi dan untuk memutar rahasia
Token akses gateway (juga disebut kunci autentikasi) Token kedaluwarsa setiap 30 hari maksimal dan harus diperpanjang dalam kontainer

Didukung oleh kunci gateway yang dapat diputar secara independen (misalnya, untuk mencabut akses)

Meregenerasi kunci gateway membatalkan semua token akses yang dibuat dengannya

Kegagalan konektivitas

Saat konektivitas ke Azure hilang, gateway yang dihost sendiri tidak dapat menerima pembaruan konfigurasi, melaporkan statusnya, atau mengunggah telemetri.

Gateway yang dihosting sendiri dirancang untuk "gagal statis" dan dapat bertahan dari hilangnya konektivitas sementara ke Azure. Hal ini dapat diterapkan dengan atau tanpa cadangan konfigurasi lokal. Dengan cadangan konfigurasi, gateway yang dihost sendiri secara teratur menyimpan cadangan konfigurasi yang diunduh terakhir pada volume tetap yang terlampir ke kontainer atau podnya.

Saat cadangan konfigurasi dimatikan dan konektivitas ke Azure terputus:

  • Menjalankan gateway yang dihosting sendiri akan terus berfungsi menggunakan salinan konfigurasi dalam memori
  • Gateway yang dihosting sendiri dan dihentikan tidak akan dapat dimulai

Saat cadangan konfigurasi diaktifkan dan konektivitas ke Azure terputus:

  • Menjalankan gateway yang dihosting sendiri akan terus berfungsi menggunakan salinan konfigurasi dalam memori
  • Gateway yang dihosting sendiri yang dihentikan akan dapat mulai menggunakan salinan cadangan konfigurasi

Saat konektivitas dipulihkan, setiap gateway yang dihosting sendiri yang terpengaruh oleh pemadaman akan secara otomatis terhubung kembali dengan layanan API Management terkait dan mengunduh semua pembaruan konfigurasi yang terjadi saat gateway "offline".

Keamanan

Batasan

Fungsionalitas berikut yang ditemukan di gateway terkelola tidak tersedia di gateway yang dihosting sendiri:

  • Dimulainya kembali sesi TLS.
  • Negosiasi ulang sertifikat klien. Untuk menggunakan autentikasi sertifikat klien, konsumen API harus menunjukkan sertifikat mereka sebagai bagian dari handshake TLS awal. Untuk memastikan perilaku ini, aktifkan pengaturan Negosiasi Sertifikat Klien saat mengonfigurasi nama host kustom gateway yang dihosting sendiri (nama domain).

Keamanan Lapisan Transportasi (TLS)

Penting

Gambaran umum ini hanya berlaku untuk gateway yang dihost sendiri v1 & v2.

Protokol yang Didukung

Gateway yang dihost sendiri menyediakan dukungan bagi TLS v1.2 secara default.

Pelanggan yang menggunakan domain kustom dapat mengaktifkan TLS v1.0 dan/atau v1.1 pada sarana kontrol.

Cipher suite tersedia

Penting

Gambaran umum ini hanya berlaku bagi gateway v2 yang dihost sendiri.

Gateway yang dihost sendiri menggunakan cipher suite berikut ini bagi koneksi klien dan server:

  • 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

Mengelola sebuah cipher suite

Pada v2.1.1 ke atas, Anda bisa mengelola cipher yang digunakan dalam konfigurasi:

  • net.server.tls.ciphers.allowed-suites memungkinkan Anda untuk menentukan daftar cipher yang dipisahkan koma, untuk digunakan koneksi TLS antara klien API dan gateway yang dihost sendiri.
  • net.client.tls.ciphers.allowed-suites memungkinkan Anda untuk menentukan daftar cipher yang dipisahkan koma, untuk digunakan koneksi TLS antara gateway yang dihost sendiri dan backend.

Langkah berikutnya