Kong API Gateway 豐富的Plugin 生態圈

簡介Plugin

筆者其實非常多技術學習的源頭，是來自於Kong 的Plugin 生態圈。過去在幫組織導入各式各樣解決方案時，都會陷入一個迷思，那就是 解決方案要能夠包山包海，從各式各樣認證授權、Log查找、追蹤、快取甚至轉換都要有，才是一個優秀且全面的解決方案。

上面那句被強調的話，相信不少資訊人在找尋解決方案時，長官都會給出類似的想像與願望。因此即使你是要找尋一個精準可以打擊痛點的潛水艇，最終這個解決方案可能會希望在潛水艇上頭增加航空母艦般多的功能。

在各種權衡下，最終筆者選擇了Kong API Gateway後，赫然發現原來 潛水艇還是只要精準打擊就好，其他的工作應該交給航母群其他的角色去處理。

這句話其實就是用來描述，Kong 最大的特點：豐富的Plugin 生態圈。

圖6-1 Kong API Gateway Plugin

Kong API Gateway 的 Plugin 是其核心擴展機制，能在請求進入與回應離開 Gateway 的過程中，加入額外的邏輯與功能，不須修改後端API服務的程式碼。

Plugin 依功能可分為多種類型，例如安全與存取控制（如 Key Authentication、JWT、HMAC）負責驗證與授權使用者，可觀測性與日誌（如 File Log、TCP Log、OpenTelemetry）則協助收集 API 請求的執行情況與追蹤資料，方便除錯、監控與分析。藉由靈活組合 Plugin，能針對不同 API 流量應用專屬策略，兼顧安全、可用性與維運監控。

筆者之所以對於Plugin 如此著迷，原因便是每一個Plugin 都是一門學問，也映射到企業的營運樣態。舉幾個例子：

• Log： Log可以根據企業需求，導出至ELK 或Splunk進行問題查找。
• Auth： 認證授權可以根據企業內已有的IDP，如LDAP(AD)/OIDC(ADFS/Keycloak/EntraID)集中化認證授權。或簡單的使用Key auth。
• 快取： 可以結合企業中已經被佈署的Redis或是用Kong原生的快取提供服務。
• 追蹤： 一樣可以根據企業內已經被安裝的Jaeger或是ELK，不斷的傳送opentelemetry 的追蹤資料供查找問題。

圖6-2 Kong豐富的Plugin

Kong Plugin 實在太多可以玩看看了，如果讀者有興趣，可以到Kong Plugin Hub逛逛看，非常多有趣的可以探索。
超連結：Kong Plugin Hub

推薦使用的 Plugin

哪些可以免費玩？

畢竟這是鐵人賽，筆者希望讀者們都可以動手實驗看看，因此首先我們要先來辨識哪些是免費可以使用的Plugin。

圖6-3 不同授權的

從圖6-3可以看到，Plugin 連結的方塊下方，僅有右邊兩塊有被貼上小標籤，最左邊則沒有小標籤。這表示，最左邊這類型的Plugin 可以被自由的使用，而被貼上小標籤Enterprise only 與 AI License Required這兩種類型，則需要額外跟Kong購買授權，才可以使用。

知道了如何辨識免費的Plugin，就可以開始介紹，這次系列文會用到的一些Plugin。

Key Auth

圖 6-4 Key Auth

如同Day 4的鐵人賽範例，範例中利用了這個最簡易的Plugin 來協助Kong初步辨識，連線來源的Consumer 是誰。範例透過要求客戶端在請求中附帶一組預先分配的 API Key（通常放在 HTTP Header）來驗證身分。

1. 範例透過yaml設定一組Key 在指定的Consumer。
2. 客戶端呼叫 API 時必須在請求中附上此 Key。
3. Kong 收到請求後，Key Auth 插件會檢查該 Key 是否有效，若通過則將請求轉發至後端服務，否則回傳 401 Unauthorized。

consumers:
- username: user1@user.com
  custom_id: user1
  keyauth_credentials:
  - key: user1-api-key

這種設定方式最直觀，也最多人使用。建議一定要透過https 來進行保護，否則只要透過網路設備去監錄，就等同於將機敏認證資訊裸奔一樣。

HMAC

圖6-5 HMAC

HMAC 的一種基於 雜湊訊息驗證碼（Hash-based Message Authentication Code） 的 API 驗證方式，比單純的 Key Authentication 更安全。

由於在http header所帶入的authorization是會根據時間的不同，而不斷的變化。因此即使中間網路節點有能力去竊取認證資訊，也僅在有限的時間內有效。從資訊安全的領域，可以有效防止側錄與重放攻擊。

不過缺點就是實作稍微複雜，呼叫端要計算HMAC簽章，而且還會有時間同步的問題需要調整。

這個Plugin 筆者曾經用來解決疑似重放攻擊的行為，可參考文章。
連結：[個案學習] API Server 未經授權連線透過Kong API Gateway 的HMAC-Auth快速排除手段

JWT

圖6-6 JWT

JWT（JSON Web Token）Plug 是 Kong API Gateway 提供的一種基於 Token 驗證 的身份驗證機制，適合用於 無狀態（stateless）API 與跨系統的安全通訊。它透過檢查客戶端提交的 JWT，確認請求方的身份與權限。

不曉得讀者們是否知道，其實主流的OAuth 2 以及OPENIDConnect(OIDC)，都是基於這種JWT的方式來進行更高階的實作。

這次在探索與學習的道路上，又發現了有趣的實踐，也打算在這一併紀錄。

ACL

圖6-7 ACL

ACL（Access Control List）是 Kong API Gateway 用來控制 哪些使用者群組可以存取哪些 API 的授權機制。它不是用來驗證身份（那是 Key Auth、JWT、HMAC 的工作），而是建立在身份驗證之後，用來做細粒度的存取控制。

因此當Consumer數量多起來後，認證之後需要分辨，這一個request是否具備權限。如果未經授權，則會回饋HTTP 403的錯誤。

File log and HTTP Log

圖6-8 File log and HTTP Log

這兩個Plugin放在一起講，因為Log 類型的Plugin 就是為了將Kong 的transation log留存。差別只是在於File Log是以檔案的形式被留存下來，而HTTP Log則是以HTTP協議往ELK或是Splunk送出。

Day 2的範例中，就有使用到File Log將Log留在本端，有興趣的讀者可回頭去看看。

因此佈署策略就可以思考，在Gateway上要透過類似filebeats將logfile 轉送到logstash，或是要直接透過http log與logstash 或elasticsearch直接溝通。

這次筆者打算用elasticsearch做為示範的標的，一同與讀者一起判讀留下來的Log。

OpenTelemetry

圖6-9 OpenTelemetry

OpenTelemetry 插件 是 Kong API Gateway 與 OpenTelemetry（OTel）標準 整合的觀測性工具，用來在 API 請求的生命週期中收集 追蹤（Tracing）、度量（Metrics）與日誌（Logs） 資料，並將其送往相容的後端（如 Jaeger、Zipkin、Prometheus、Grafana Tempo 等）進行分析與可視化。

這也是筆者這次打算談及的可觀測性示範中，會使用到的Plugin，將使用Jaeger作為示範的平台。

小結

今天簡單的介紹了Kong豐富的Plugin生態圈，就如同前面提及的，每一個Plugin都是一門學問，而且涉及到組織的內部生態圈。明天開始，我們將透過Plugin來與不同平台介接，敬請期待與追蹤。