Bagikan melalui

Gambaran umum gateway yang dihosting sendiri

BERLAKU UNTUK: Pengembang | Premium

Gateway yang dihost sendiri adalah versi opsional yang dikontainerisasi dari gateway terkelola default yang disertakan dalam setiap instans API Management. Ini berguna untuk skenario seperti menempatkan gateway di lingkungan yang sama tempat Anda menghosting API Anda. 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. Ini juga menyajikan arsitektur tingkat tinggi fitur dan menggambarkan kemampuannya.

Untuk gambaran umum perbedaan antara gateway terkelola dan yang dihost sendiri, lihat GATEWAY API di API Management.

Manajemen API hibrid dan multi-cloud

Fitur gateway yang dihost sendiri memperluas dukungan API Management untuk lingkungan hibrid dan multicloud dan memungkinkan Anda mengelola API yang dihosting secara efisien dan aman di lokal dan di seluruh cloud dari satu instans API Management di Azure.

Dengan gateway yang dihost sendiri, Anda memiliki fleksibilitas untuk menyebarkan versi kontainer komponen gateway API Management ke lingkungan yang sama tempat Anda menghosting API Anda. Semua gateway yang dihost sendiri dikelola dari instans API Management yang digabungkan dengannya, sehingga memberi Anda visibilitas dan pengalaman manajemen terpadu di semua API internal dan eksternal.

Setiap instans API Management terdiri dari komponen utama berikut:

  • Bidang manajemen, yang diekspos sebagai API, digunakan untuk mengonfigurasi layanan melalui portal Microsoft Azure, PowerShell, dan teknologi lain yang didukung
  • Gateway (atau bidang data), yang bertanggung jawab untuk memproksi permintaan API, menerapkan kebijakan, dan mengumpulkan telemetri
  • Portal pengembang yang digunakan oleh pengembang untuk menemukan, mempelajari, dan onboard untuk menggunakan API

Secara default, semua komponen ini disebarkan di Azure, menyebabkan semua lalu lintas API (ditampilkan sebagai panah hitam padat dalam gambar berikut) mengalir melalui Azure terlepas dari di mana backend yang mengimplementasikan 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 dihost sendiri

Menyebarkan gateway yang dihost sendiri ke lingkungan yang sama di mana implementasi API backend dihosting memungkinkan lalu lintas API mengalir langsung ke API backend, yang mengurangi latensi, mengoptimalkan biaya transfer data, dan memungkinkan kepatuhan sambil mempertahankan manfaat memiliki satu titik manajemen, pengamatan, dan penemuan untuk semua API di organisasi, terlepas dari di mana implementasinya dihosting.

Arus lalu lintas API dengan gateway yang dihost sendiri

Pengemasan

Gateway yang dihosting sendiri tersedia sebagai gambar kontainer Docker berbasis Linux dari Registry Artefak Microsoft. Ini dapat disebarkan ke Docker, Kubernetes, atau solusi orkestrasi kontainer lainnya yang berjalan pada kluster server lokal, infrastruktur cloud, atau, untuk tujuan evaluasi dan pengembangan, di komputer pribadi. Anda juga dapat menyebarkan gateway yang dihost sendiri sebagai ekstensi kluster ke kluster Kubernetes berkemampuan Azure Arc.

Gambar kontainer

Berbagai gambar kontainer untuk gateway yang dihost sendiri tersedia:

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

Anda dapat menemukan daftar lengkap tag yang tersedia di sini.

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

Penggunaan tag dalam opsi penyebaran resmi

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

Catatan

Cuplikan perintah dan YAML disediakan sebagai referensi. Anda dapat menggunakan tag yang lebih spesifik jika mau.

Saat Anda menginstal gateway dengan bagan Helm, penandaan gambar menjadi lebih efisien. Versi aplikasi dari Helm chart mengunci gateway pada versi tertentu dan tidak bergantung pada latest.

Untuk informasi selengkapnya, lihat Menginstal gateway mandiri API Management di Kubernetes dengan Helm.

Risiko penggunaan tag bergulir

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

Saat Anda menggunakan jenis tag ini, Anda berpotensi menjalankan versi yang berbeda secara paralel tanpa melihat itu, misalnya saat Anda melakukan tindakan penskalaan setelah v2 tag diperbarui.

Contoh: Tag v2 dirilis bersama image kontainer 2.0.0. Ketika 2.1.0 dirilis, v2 tag akan ditautkan ke 2.1.0 gambar.

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 dihost sendiri harus dikaitkan dengan satu instans API Management dan dikonfigurasi melalui bidang manajemennya. Gateway yang dihost sendiri menggunakan konektivitas ke Azure untuk:

  • Melaporkan statusnya dengan mengirim pesan denyut nadi setiap menit.
  • Secara teratur (setiap 10 detik) memeriksa dan menerapkan pembaruan konfigurasi setiap kali tersedia.
  • Mengirim metrik ke Azure Monitor, jika dikonfigurasi untuk melakukannya.
  • Mengirim peristiwa ke Application Insights, jika dikonfigurasi untuk melakukannya.

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:

Titik akhir Diperlukan? Catatan
Nama host titik akhir konfigurasi <api-management-service-name>.configuration.azure-api.net 1 Nama host kustom juga didukung dan dapat digunakan alih-alih nama host default.
Alamat IP publik instansiasi API Management ✔️ Alamat IP lokasi utama sudah cukup.
Alamat IP publik dari 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 Titik akhir minimal yang diperlukan adalah rt.services.visualstudio.com:443, dc.services.visualstudio.com:443, dan {region}.livediagnostics.monitor.azure.com:443. Untuk informasi selengkapnya, lihat dokumentasi Azure Monitor.
Titik akhir untuk integrasi Event Hubs Opsional5 Untuk informasi selengkapnya, lihat dokumentasi Azure Event Hubs.
Titik akhir untuk integrasi cache eksternal Opsional5 Persyaratan ini tergantung pada cache eksternal yang sedang digunakan.

1Untuk informasi tentang instans API Management di jaringan virtual internal, lihat Konektivitas di jaringan virtual internal.
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 Anda menggunakan autentikasi atau kebijakan Microsoft Entra yang terkait dengan Microsoft Entra.
5Hanya diperlukan saat fitur digunakan dan memerlukan alamat IP publik, port, dan informasi nama host.

Penting

  • Nama host DNS harus dapat diselesaikan ke alamat IP, dan alamat IP yang sesuai harus dapat dijangkau.
  • Nama akun penyimpanan terkait tercantum di halaman status konektivitas Jaringan layanan di portal Microsoft Azure.
  • Alamat IP publik yang mendasari akun penyimpanan terkait bersifat dinamis dan dapat berubah tanpa pemberitahuan.

Konektivitas dalam jaringan virtual internal

  • Konektivitas privat Jika gateway yang dihost sendiri disebarkan di jaringan virtual, aktifkan konektivitas privat ke titik akhir konfigurasi v2 dari lokasi gateway yang dihost sendiri, misalnya, menggunakan DNS privat di jaringan yang di-peering.

  • Konektivitas internet. Jika gateway yang dihost sendiri perlu terhubung ke titik akhir konfigurasi v2 melalui internet, konfigurasikan nama host kustom untuk titik akhir konfigurasi dan ekspos titik akhir dengan menggunakan Azure Application Gateway.

Opsi autentikasi

Pengaturan konfigurasi kontainer gateway menyediakan opsi berikut untuk mengautentikasi koneksi antara gateway yang dihost sendiri dan titik akhir konfigurasi instans API Management berbasis cloud.

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

Mengelola akses secara terpisah per aplikasi.

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

Gunakan prosedur standar Microsoft Entra untuk menetapkan atau mencabut izin pengguna atau grup kepada aplikasi serta mengelola rotasi kredensial rahasia.
Token akses gateway. (Juga disebut kunci autentikasi.) Token kedaluwarsa setidaknya setiap 30 hari dan harus diperbarui dalam kontainer.

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

Regenerasi kunci gateway akan membatalkan semua token akses yang dikeluarkan dengan kunci tersebut.

Petunjuk / Saran

Lihat Azure API Management sebagai sumber Event Grid untuk informasi tentang peristiwa Event Grid yang dihasilkan oleh gateway yang dihost sendiri saat token akses gateway mendekati kedaluwarsa atau telah kedaluwarsa. Gunakan peristiwa ini untuk memastikan bahwa gateway yang disebarkan selalu dapat mengautentikasi dengan instans API Management terkait.

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 secara statis" dan dapat bertahan meskipun terjadi 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:

  • Gateway yang dihost sendiri terus beroperasi dengan menggunakan salinan konfigurasi dalam memori.
  • Gateway yang dihentikan dan dihost sendiri tidak akan dapat dimulai.

Saat cadangan konfigurasi diaktifkan dan konektivitas ke Azure terputus:

  • Pengoperasian gateway yang dihost sendiri terus berfungsi dengan menggunakan salinan konfigurasi yang disimpan dalam memori.
  • Gateway yang dihost sendiri yang telah dihentikan dapat memulai ulang dengan menggunakan konfigurasi cadangan.

Ketika konektivitas dipulihkan, setiap gateway yang dihost sendiri yang terpengaruh oleh pemadaman secara otomatis terhubung kembali dengan instans API Management terkait dan mengunduh semua pembaruan konfigurasi yang terjadi saat gateway offline.

Keamanan

Batasan

Fungsionalitas berikut yang tersedia di gateway terkelola tidak tersedia di gateway yang dihost 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)

Protokol yang Didukung

Gateway yang dihost sendiri mendukung TLS v1.2 secara default.

Jika Anda menggunakan domain kustom, Anda dapat mengaktifkan TLS v1.0 dan/atau v1.1 di sarana kontrol.

Cipher suite tersedia

Gateway yang dihost sendiri menggunakan suite sandi berikut untuk 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

Dengan v2.1.1 dan yang lebih baru, Anda dapat mengelola cipher yang digunakan melalui konfigurasi:

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

Konten terkait

  • Last updated on