Apa Itu API Gateway Policies?

Dengan berkembangnya arsitektur cloud-native dan mikroservis, peran API gateway sebagai portal lalu lintas semakin penting. API gateway terutama bertanggung jawab untuk menerima lalu lintas permintaan dan meneruskannya ke layanan upstream yang sesuai. Kebijakan API gateway menentukan logika dan aturan untuk mengelola lalu lintas, yang secara langsung menentukan perilaku lalu lintas bisnis.

Apa itu Kebijakan API Gateway

API gateway umumnya terletak di depan semua layanan upstream. Ketika pengguna mengirim permintaan ke suatu layanan, permintaan tersebut akan pertama kali menuju ke API gateway, dan API gateway biasanya akan memeriksa beberapa hal:

1. Memeriksa apakah permintaan tersebut legal. Apakah permintaan berasal dari daftar pengguna yang dilarang mengakses?
2. Memeriksa apakah permintaan telah diautentikasi dan konten yang diakses telah diotorisasi.
3. Memeriksa apakah permintaan memicu aturan pembatasan tertentu, seperti batas kecepatan.
4. Memeriksa ke layanan upstream mana permintaan akan diteruskan.

Setelah serangkaian langkah ini, permintaan akan ditolak atau mencapai layanan upstream yang ditentukan dengan benar. Kami menyebut aturan pemrosesan ini sebagai kebijakan API gateway. Aturan-aturan ini terus ditambahkan ke gateway oleh administrator gateway saat gateway berjalan. Gateway menerima aturan-aturan ini dan melakukan perilaku pemrosesan lalu lintas yang sesuai.

Mengambil API gateway Apache APISIX sebagai contoh, ada dua jenis informasi konfigurasi APISIX: file konfigurasi untuk memulai gateway, seperti config.yaml, file ini menentukan beberapa konfigurasi yang diperlukan agar gateway dapat berjalan normal. Selain itu, administrator dapat membuat berbagai aturan dan konfigurasi secara dinamis melalui Admin API saat runtime, seperti Route, Consumer, Plugin, dll. Kebijakan API gateway adalah berbagai aturan dan konfigurasi yang dibuat secara dinamis oleh administrator melalui Admin API.

Artikel ini akan menjelaskan skenario empat API gateway, autentikasi dan otorisasi, keamanan, pemrosesan lalu lintas, dan observabilitas, serta bagaimana kebijakan API gateway bekerja di setiap skenario.

Kebijakan Autentikasi dan Otorisasi

Autentikasi dapat mengonfirmasi identitas pemanggil API, dan otorisasi membatasi pemanggil hanya untuk mengakses sumber daya dalam lingkup otoritas.

Misalnya, jika seorang penumpang bepergian ke stasiun, ia akan menggunakan kartu identitasnya untuk "autentikasi" untuk mengonfirmasi identitasnya sebelum memasuki stasiun. Setelah memasuki stasiun, ia akan menunjukkan tiketnya kepada petugas untuk konfirmasi dan "diotorisasi" untuk masuk ke kereta tertentu. Tujuan utama kebijakan autentikasi dan otorisasi adalah memastikan bahwa semua permintaan yang diteruskan ke layanan upstream adalah legal dan permintaan hanya mengakses sumber daya dalam lingkup otoritas. Beberapa kebijakan standar adalah sebagai berikut:

Basic Auth

Kebijakan Basic Access Authentication adalah teknik kontrol akses yang paling sederhana. Umumnya, proxy HTTP pengguna membawa header permintaan untuk autentikasi saat mengirim permintaan, yang biasanya: Authorization: Basic <credentials>, dan credentials mencakup ID pengguna dan kata sandi yang diperlukan untuk autentikasi pengguna, dipisahkan oleh :. Metode ini tidak memerlukan pengaturan kompleks seperti halaman login dan cookie. Ini diautentikasi berdasarkan informasi kredensial sederhana di header permintaan, umumnya nama pengguna dan kata sandi, yang mudah dikonfigurasi dan digunakan.

Contoh permintaan cURL dengan autentikasi dasar adalah sebagai berikut, dengan username dan password:

curl -i -u 'username:password' http://127.0.0.1:8080/hello

Perlu dicatat bahwa informasi dalam credentials tidak akan dienkripsi selama transmisi. Ini hanya dienkode base64, sehingga biasanya perlu digunakan dengan HTTPS untuk memastikan keamanan kata sandi.

Setelah kebijakan ini diimplementasikan di gateway, permintaan tanpa kredensial tidak akan diteruskan kecuali informasi autentikasi yang benar dibawa dalam permintaan. Kebijakan ini mengimplementasikan verifikasi akses API dengan biaya minimal.

Key Auth

Kebijakan Key Auth membatasi panggilan API dengan menambahkan kunci ke API dan menggunakan kunci untuk mengontrol akses ke sumber daya. Hanya permintaan dengan kunci yang benar, yang dapat dibawa di header permintaan atau query, yang dapat mengakses sumber daya. Biasanya, kunci ini juga dapat digunakan untuk membedakan pemanggil API yang berbeda. Sehingga kebijakan atau kontrol sumber daya yang berbeda dapat diimplementasikan untuk pemanggil yang berbeda. Sama seperti basic auth, kunci tidak dienkripsi. Pastikan permintaan menggunakan HTTPS untuk memastikan keamanan.

Ambil contoh plugin key-auth APISIX. Plugin perlu membuat Consumer dengan nilai kunci unik melalui Admin API:

curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "jack-key"
        }
    }
}'

Permintaan ini membuat Consumer bernama jack dengan nilai kunci jack-key.

Saat mengaktifkan plugin di rute, Anda perlu mengonfigurasi lokasi dan nama bidang kunci dalam permintaan. Konfigurasi lokasi default adalah header, dan nama bidang adalah apikey, sehingga kode yang benar untuk meminta rute ini adalah:

curl -i http://127.0.0.1:8080/hello -H 'apikey: jack-key'

Setelah APISIX menerima permintaan ini, APISIX akan mengurai kunci dan mencocokkan Consumer jack dari semua kunci yang dikonfigurasi. Jadi gateway akan tahu bahwa permintaan dikirim oleh jack. Jika tidak ada kunci yang cocok, permintaan dapat dinilai sebagai permintaan ilegal.

JSON Web Token

JSON Web Token (JWT) adalah standar terbuka yang mendefinisikan cara untuk mengirimkan informasi dengan aman antara pihak-pihak dalam bentuk objek json. Kebijakan JWT dapat menggabungkan autentikasi dan otorisasi. Setelah pengguna memberikan otorisasi, token JWT akan dikirimkan ke pengguna, dan pemanggil akan membawa token ini dalam semua permintaan berikutnya untuk memastikan bahwa permintaan telah diotorisasi.

Di API gateway, autentikasi JWT dapat ditambahkan ke gateway melalui kebijakan JWT. Jadi, kita dapat memisahkan logika autentikasi dari kode bisnis, dan pengembang dapat lebih fokus pada implementasi logika bisnis. Ambil contoh plugin jwt-auth APISIX. Plugin harus diaktifkan dan dikonfigurasi di Consumer dengan kunci uniknya, kunci publik dan pribadi untuk enkripsi, algoritma enkripsi, waktu kedaluwarsa token, dll. Pada saat yang sama, Anda perlu mengaktifkan plugin ini di rute dan mengonfigurasi gateway untuk membaca lokasi dan bidang token, seperti header, query, cookie, dll. Plugin ini akan menambahkan API ke API Gateway untuk menerbitkan token. Sebelum mengirim permintaan, API yang menerbitkan token perlu diminta. Token perlu dibawa di lokasi yang ditentukan sesuai dengan informasi konfigurasi saat mengirim permintaan. Setelah permintaan mencapai gateway, gateway akan membaca token dari lokasi yang ditentukan dari permintaan sesuai dengan informasi konfigurasi dan memverifikasi validitas token. Permintaan dapat diteruskan ke layanan upstream setelah verifikasi.

Dibandingkan dengan dua strategi sebelumnya, kebijakan JWT mencakup opsi untuk waktu kedaluwarsa. Token yang diterbitkan dapat kedaluwarsa seiring waktu, tetapi masa berlaku Basic Auth dan Key Auth adalah permanen kecuali server mengubah kata sandi atau kunci. Selain itu, kebijakan JWT dapat dibagikan antara beberapa layanan, yang bermanfaat untuk skenario single sign-on (SSO).

OpenID Connect

OpenID Connect adalah metode autentikasi dan otorisasi berdasarkan protokol OAuth2.0, menyediakan solusi aplikasi yang relatif lengkap. Kebijakan OpenID Connect di API gateway akan memungkinkan layanan upstream mendapatkan informasi pengguna dari penyedia identitas (IdP), sehingga melindungi keamanan API. IdP umum adalah Keycloak, Ory Hydra, Okta, Auth0, dll. Mengambil Apache APISIX sebagai contoh, alur kerja kebijakan OpenID Connect di gateway adalah sebagai berikut:

1. Klien mengirim permintaan ke gateway
2. Setelah menerima permintaan, gateway mengirim permintaan autentikasi ke IdP
3. Pengguna akan dialihkan ke halaman yang disediakan oleh IdP untuk menyelesaikan login autentikasi
4. IdP mengalihkan ke gateway dengan kode autentikasi
5. Gateway meminta Access Token dari IdP melalui kode untuk mendapatkan informasi pengguna
6. Gateway dapat membawa informasi pengguna saat meneruskan permintaan ke upstream

Proses ini memungkinkan autentikasi dan otorisasi dipisahkan dari bisnis, membuat arsitektur lebih granular.

Untuk metode autentikasi dan otorisasi APISIX lebih lanjut, silakan merujuk ke API Gateway Authentication.

Kebijakan Keamanan

Kebijakan keamanan API gateway bertindak seperti penjaga gerbang untuk memastikan akses API yang aman, memungkinkan permintaan legal diteruskan oleh gateway dan memblokir permintaan ilegal di gateway. Menurut OWASP API Security Project, ada banyak ancaman dan serangan yang mungkin terjadi pada pemanggil API. Menggunakan kebijakan keamanan API gateway dapat melakukan verifikasi keamanan pada semua permintaan API, yang memainkan peran penting dalam melindungi API dari ancaman keamanan ini.

Berikut adalah beberapa kebijakan keamanan API gateway yang penting:

Pembatasan Akses IP

Kebijakan pembatasan IP membatasi klien tertentu untuk mengakses API dengan menetapkan IP tertentu atau CIDR dalam daftar izin atau daftar blokir untuk melarang akses ilegal ke data sensitif. Mengonfigurasi kebijakan ini dengan benar akan sangat meningkatkan keamanan API dan memungkinkan tata kelola keamanan API yang lebih tinggi.

Pemblokiran URI

Kebijakan pemblokiran URI mencegat permintaan API yang berpotensi berbahaya dengan menetapkan beberapa aturan URI. Misalnya, beberapa serangan keamanan mendeteksi kerentanan potensial dengan mengendus jalur URI dan kemudian menyerang. Apache APISIX menyediakan plugin uri-blocker untuk memblokir permintaan API yang berbahaya. Seseorang juga dapat menetapkan ekspresi reguler melalui plugin uri-blocker. Gateway API akan memblokir permintaan jika permintaan cocok dengan aturan. Misalnya, jika kita mengonfigurasi root.exe, admin, plugin ini dapat memblokir permintaan */root.exe dan */admin untuk lebih melindungi keamanan API.

CORS

CORS (Cross-origin resource sharing) adalah kebijakan keamanan browser untuk permintaan lintas domain. Umumnya, sebelum mengirim permintaan xhr di browser, browser akan memverifikasi apakah alamat permintaan dan alamat saat ini berada dalam origin yang sama. Permintaan dalam origin yang sama akan dikirim langsung. Jika tidak, browser akan pertama kali mengirim permintaan pra-penerbangan lintas domain tipe OPTION. Akan ada pengaturan CORS terkait di header respons, seperti metode dan kredensial yang diizinkan untuk dibawa dalam permintaan lintas domain. Browser akan memutuskan apakah akan mengirim permintaan formal berdasarkan informasi ini. Untuk detailnya, silakan merujuk ke CORS.

Umumnya, respons yang berisi pengaturan CORS ditetapkan oleh layanan backend. Tetapi jika ada banyak layanan, akan lebih aman dan lebih nyaman untuk memprosesnya secara seragam di tingkat gateway. Kebijakan CORS dapat menetapkan kebijakan resolusi lintas domain yang berbeda pada API yang berbeda, dan layanan upstream tidak perlu lagi menangani logika ini.

CSRF

CSRF adalah serangan pemalsuan permintaan lintas situs, yang menyebabkan pengguna akhir melakukan tindakan yang tidak disengaja pada situs web yang telah mereka autentikasi. Serangan ini umumnya disertai dengan rekayasa sosial (mengirim tautan berbahaya ke korban melalui email). Ketika pengguna mengklik tautan, penyerang menggunakan identitas yang telah diautentikasi korban untuk melakukan operasi serangan pada situs web. Dari perspektif situs web, perilaku apa pun diharapkan karena pengguna telah login.

Biasanya, layanan backend situs web perlu menambahkan middleware tambahan untuk menangani bagian logika ini, dan metode pencegahan juga memiliki standar tertentu. Menggunakan kebijakan CSRF dapat mencegah serangan ini dan melakukan pemrosesan keamanan CSRF di lapisan gateway untuk menyederhanakan kompleksitas logika layanan upstream.

Kebijakan Pemrosesan Lalu Lintas

Kebijakan pemrosesan lalu lintas terutama memastikan bahwa beban upstream dari API gateway untuk penerusan lalu lintas berada dalam rentang yang sehat. Pada saat yang sama, permintaan ditulis ulang sesuai kebutuhan sebelum diteruskan atau dikembalikan ke pemanggil. Jenis kebijakan ini terutama tentang fungsionalitas seperti pembatasan kecepatan, pemutusan sirkuit, caching, dan penulisan ulang.

Pembatasan Kecepatan

Dalam kasus sumber daya yang terbatas, ada batasan pada kemampuan layanan yang dapat disediakan oleh API. Jika panggilan melebihi batas ini, layanan upstream mungkin crash dan menyebabkan beberapa reaksi berantai. Pembatasan kecepatan dapat menghindari kasus seperti itu dan dapat secara efektif mencegah API dari serangan DDOS (Denial-of-service attack).

Kita dapat mengonfigurasi jendela waktu dan jumlah maksimum permintaan yang diizinkan dalam kebijakan pembatasan kecepatan. Gateway API akan menolak permintaan yang melebihi jumlah maksimum yang diizinkan dan mengembalikan pesan kesalahan pembatasan kecepatan. Permintaan tidak akan diizinkan sampai jumlah permintaan kurang dari batas atau jendela waktu berikutnya dibuka.

Variabel untuk penghitungan permintaan dapat ditetapkan dalam permintaan atau sebagai header permintaan tertentu, misalnya, untuk menetapkan kebijakan pembatasan kecepatan yang sesuai menurut IP yang berbeda untuk mencapai fleksibilitas yang lebih baik.

Pemutusan Sirkuit

Kebijakan pemutusan sirkuit API dapat menyediakan kemampuan pemutusan sirkuit untuk layanan upstream. Saat menggunakan kebijakan ini, Anda perlu menetapkan kode status layanan upstream yang sehat dan tidak sehat untuk gateway untuk menilai status layanan upstream. Selain itu, juga perlu menetapkan ambang batas permintaan untuk memicu pemutusan atau memulihkan kesehatan. Ketika layanan upstream terus mengembalikan kode status tidak sehat ke gateway, gateway akan memutus layanan upstream untuk beberapa waktu. Selama periode ini, gateway tidak akan lagi meneruskan permintaan ke upstream tetapi langsung mengembalikan kesalahan. Ini dapat mencegah layanan upstream dari "avalanche" terus menerima permintaan karena kesalahan dan melindungi layanan bisnis. Setelah periode ini, gateway akan mencoba meneruskan permintaan ke upstream lagi. Jika masih mengembalikan kode status tidak sehat, gateway akan terus memutus untuk waktu yang lebih lama (dilipatgandakan). Sampai upstream mengembalikan sejumlah kode status kesehatan, gateway percaya bahwa layanan upstream kembali sehat dan akan terus meneruskan lalu lintas ke node upstream.

Dalam kebijakan ini, juga perlu menetapkan kode status dan informasi yang perlu dikembalikan ketika tidak sehat. Ketika layanan upstream tidak sehat, permintaan dikembalikan langsung di tingkat gateway untuk melindungi stabilitas layanan bisnis.

Pembagian Lalu Lintas

Kebijakan pembagian lalu lintas dapat secara dinamis mengontrol penerusan lalu lintas ke layanan upstream yang berbeda secara proporsional. Ini sangat menguntungkan dalam rilis canary dan deploy biru-hijau.

Rilis canary memungkinkan hanya beberapa permintaan untuk menggunakan layanan baru, sementara bagian lainnya tetap di layanan lama. Jika layanan baru tetap stabil, Anda dapat meningkatkan proporsi dan secara bertahap mentransfer semua permintaan ke layanan baru sampai rasio sepenuhnya beralih untuk menyelesaikan peningkatan.

Rilis biru-hijau adalah mode rilis lain, yang merilis versi baru selama periode puncak tanpa mengganggu layanan. Kedua versi lama dan baru dari layanan hidup berdampingan. Biasanya lingkungan produksi (biru) disalin ke dalam wadah yang identik tetapi terpisah (hijau). Rilis pembaruan baru ke lingkungan hijau, dan kemudian rilis kedua hijau dan biru ke produksi. Lingkungan hijau kemudian dapat diuji dan diperbaiki sementara pengguna masih mengakses sistem biru. Permintaan kemudian dapat dialihkan ke lingkungan hijau menggunakan beberapa kebijakan load-balancing. Lingkungan biru kemudian dapat disimpan sebagai opsi pemulihan bencana atau untuk pembaruan berikutnya.

APISIX mendukung kedua rilis melalui plugin traffic-split, membuat penyebaran bisnis lebih nyaman dan andal.

Penulisan Ulang Respons

Dalam arsitektur mikroservis modern, ada banyak protokol berbeda antara layanan dan tidak ada format data respons yang seragam. Jika logika transkode ini diimplementasikan secara terpisah di masing-masing layanan, akan ada kode logika yang berlebihan, yang sulit untuk dikelola. Beberapa kebijakan penulisan ulang respons dapat menangani konversi protokol, penulisan ulang badan permintaan, dan logika lainnya.

APISIX menyediakan plugin Response Rewrite untuk memodifikasi Body atau Header informasi yang dikembalikan oleh layanan upstream dan mendukung penambahan atau penghapusan header respons, menetapkan aturan untuk memodifikasi badan respons, dll. Ini berguna dalam skenario seperti menetapkan header respons CORS untuk permintaan lintas domain atau menetapkan lokasi untuk pengalihan.

Di sisi lain, APISIX menyediakan proxy-rewrite untuk penulisan ulang permintaan. Plugin ini juga dapat menangani konten permintaan yang diproksi ke layanan upstream. Anda dapat menulis ulang URI permintaan, metode, header permintaan, dll., yang memberikan kemudahan untuk pemrosesan bisnis dalam banyak skenario.

Injeksi Kesalahan

Injeksi kesalahan adalah metode pengujian perangkat lunak yang memastikan perilaku sistem yang benar dengan sengaja memperkenalkan kesalahan. Biasanya, pengujian dilakukan sebelum penyebaran untuk memastikan tidak ada kegagalan potensial di lingkungan produksi. Dalam beberapa skenario pengujian chaos, perlu menyuntikkan beberapa kesalahan ke dalam layanan untuk memverifikasi keandalannya.

Injeksi kesalahan perangkat lunak dapat dikategorikan menjadi injeksi waktu kompilasi dan injeksi waktu runtime. Injeksi waktu kompilasi mengacu pada mengubah beberapa kode atau logika dalam penulisan perangkat lunak. Injeksi waktu runtime menguji perilaku perangkat lunak dengan menetapkan kesalahan dalam lingkungan perangkat lunak yang berjalan. Kebijakan injeksi kesalahan dapat mensimulasikan kesalahan dalam permintaan jaringan aplikasi melalui injeksi waktu runtime. Dengan memilih rasio dalam kebijakan, permintaan dalam rasio ini akan menjalankan logika kesalahan, seperti mengembalikan dengan waktu tunda atau langsung mengembalikan kode kesalahan dan pesan kesalahan yang ditetapkan ke pemanggil. Dengan cara ini, adaptabilitas perangkat lunak dapat ditingkatkan, memungkinkan pengembang untuk melihat beberapa situasi kesalahan yang mungkin terjadi sebelumnya, dan membuat modifikasi adaptif terhadap masalah sebelum rilis.

Konversi Protokol

Kebijakan kelas konversi protokol dapat mengonversi antara beberapa protokol standar, seperti permintaan HTTP umum dan gRPC. Apache APISIX menyediakan plugin grpc-transcode yang dapat mentranskode dan meneruskan permintaan HTTP ke layanan tipe gRPC. Respons dikembalikan ke klien dalam format HTTP. Dengan cara ini, klien hanya dapat fokus pada HTTP tanpa memperhatikan jenis gRPC upstream.

Kebijakan Observabilitas

Observabilitas mengacu pada kemampuan untuk mengukur status operasi sistem melalui data output sistem. Dalam beberapa sistem sederhana, karena jumlah komponen sistem relatif kecil, bug dapat ditemukan dengan menganalisis status setiap komponen ketika terjadi kesalahan. Namun, dalam sistem terdistribusi skala besar, jumlah berbagai komponen mikroservis sangat besar, dan tidak realistis untuk memeriksa komponen satu per satu. Pada saat ini, sistem perlu dapat diamati. Observabilitas memberikan visibilitas sistem yang luas, dan ketika masalah terjadi, dapat memberikan kontrol yang diperlukan kepada insinyur untuk menemukan masalah.

Pengumpulan data dapat diimplementasikan dalam komponen aplikasi. API gateway adalah pintu masuk semua lalu lintas, sehingga mengimplementasikan fitur observabilitas sistem di API gateway dapat mencerminkan penggunaan API sistem. Kebijakan observabilitas API Gateway dapat membantu semua tim:

• Tim insinyur dapat memantau dan menyelesaikan masalah API.
• Tim produk dapat memahami penggunaan API untuk menemukan nilai bisnis di baliknya.
• Tim penjualan dan pertumbuhan dapat memantau penggunaan API, mengawasi peluang bisnis, dan memastikan API memberikan data yang benar.

Kebijakan observabilitas umumnya dibagi menjadi tiga kategori menurut jenis data output: Tracing, Metrics, dan Logging.

Tracing

Dalam sistem terdistribusi skala besar, hubungan antara layanan sangat rumit. Tracing (pelacakan tautan) dapat melacak tautan panggilan lengkap, analisis ketergantungan antar aplikasi, dan statistik permintaan dalam aplikasi terdistribusi. Ketika masalah terjadi dalam sistem, ini dapat membantu insinyur menentukan ruang lingkup dan lokasi investigasi.

Kebijakan tracing dapat mengintegrasikan sistem pelacakan tautan panggilan terdistribusi lainnya di API Gateway untuk mengumpulkan dan mencatat informasi. Misalnya, mengintegrasikan layanan seperti Zipkin dan SkyWalking ke dalam API gateway untuk mengumpulkan data dan komunikasi antarlayanan. Oleh karena itu, kebijakan ini memungkinkan insinyur tahu log mana yang harus dilihat untuk sesi tertentu atau panggilan API terkait dan memverifikasi ruang lingkup pemecahan masalah.

Metrics

Metrics mengacu pada data observasi perangkat lunak yang dikumpulkan selama interval waktu operasi layanan. Data ini terstruktur secara default, yang membuat query dan visualisasi mudah. Seseorang dapat mempelajari status operasi sistem melalui analisis data ini.

Kebijakan metrics dapat mengintegrasikan layanan seperti Prometheus atau Datadog di API gateway untuk menyediakan kemampuan pemantauan dan alarm untuk sistem. Kebijakan ini mengumpulkan data selama operasi gateway melalui berbagai antarmuka API gateway dan melaporkan data ke Prometheus atau Datadog. Dengan memvisualisasikan data ini, pengembang dapat melihat status operasi gateway, informasi statistik permintaan API, dan grafik statistik lainnya.

Logging

Log adalah catatan teks dari peristiwa sistem pada waktu tertentu. Log adalah tempat pertama yang harus diperiksa ketika masalah terjadi dalam sistem. Insinyur mengandalkan konten log untuk menemukan apa yang terjadi pada sistem dan solusi yang sesuai. Konten log umumnya dibagi menjadi log permintaan API dan log operasi gateway. Log permintaan API mencatat semua catatan permintaan API selama operasi API gateway. Insinyur dapat mempelajari informasi akses API melalui catatan ini dan menemukan serta memecahkan masalah permintaan abnormal tepat waktu. Log operasi gateway berisi catatan semua peristiwa yang terjadi selama kerja gateway. Ketika API gateway abnormal, ini dapat digunakan sebagai dasar penting untuk pemecahan masalah.

Kebijakan logging dapat menyimpan log di API gateway di disk server atau mendorongnya ke beberapa server log lain, seperti server log HTTP, server log TCP, server log UDP, dll., atau sistem log lain seperti Kafka, RocketMQ, Clickhouse.

Ringkasan

Artikel ini memperkenalkan empat kebijakan yang umum digunakan di API gateway: autentikasi dan otorisasi, keamanan, pemrosesan lalu lintas, dan observabilitas. API Gateway menerima lalu lintas permintaan sebelum semua layanan upstream, mengontrol di mana dan bagaimana permintaan diteruskan, dan secara langsung menolak atau membatasi permintaan yang tidak aman dan tidak diotorisasi. Kebijakan API Gateway dapat mengonfigurasi semua perilaku ini.

Untuk informasi lebih lanjut tentang API gateway, silakan kunjungi blog dan API7.ai untuk dukungan komersial lebih lanjut.