Kong

前言 當你的 API 以 OpenID Connect 協定實作 authentication(認證)時，就會使用到 Kong OIDC(OpenID Connect) plugin。本篇要關注的是，當利用 OpenID Connect 協定，讓 Kong 在認證階段自動與 IdP（例如 ADFS）整合，獲取並驗證 JWT Token，保證只有合法使用者能夠存取上游服務的這個過程。 驗證流程 當 Kong 收到來自 consumer 的請求後，會進行以下流程： Issuer Discovery Kong 透過 OIDC plugin 中的 issuer 參數，從 .well-known/openid-configuration URL，自動抓取 IdP 的 Metadata。Metadata 包含 jwks_uri（JSON Web Key Set）endpoint，用於後續公鑰獲取。 若在 plugin 的 extra_jwks_uris 有設定放置公鑰的 URL，Kong 會先依序對每個 extra_jwks_uris URL 嘗試下載 JWKS。若所有 extra_jwks_uris 都無法成功（連線失敗或無對應公鑰），再從 .well-known/openid-configuration 中的 jwks_uri 嘗試；若未設定 extra_jwks_uris，則會直接使用 .well-known Metadata 提供的 jwks_uri。 Token 取得: Kong 會對 ADFS 發起請求並獲取並 JWT Token。 ...

前言 某天我在公司 Kong 測試環境的 control plane 上作業時，才發現其中一台 control plane 的服務竟然沒啟用。好奇之下問了之前負責維護的同事，結果他說：「本來就只會啟用一台啊！」於是我又多學了一課，身為啥都學來者不拒的工程師，當然要記錄下來。 HA cluster 高可用性叢集 根據 wikipedia 的定義：「高可用性叢集(High-availability clusters)是以最短的中斷時間為目標而可靠地運作的，支撐伺服器應用的一組電腦。它們通過使用高可用性軟體來管理叢集中的冗餘電腦，當系統組件出現故障時，這些電腦可以繼續提供服務。」簡單來說，就是有備援主機能在其中一台掛掉時接手，讓服務不中斷。 在接手 Kong 之前，我手上的系統也幾乎都是一個服務同時掛載在由兩個節點組成的 cluster 上，流量會透過 NLB(Network Load Balancer，網路負載平衡器)分流到兩個 node 上。 HA cluster 常見有兩種運作模式：Active-Passive 和 Active-Active。 Active-Passive 模式：一台節點（主節點）負責運行服務並處理所有流量，另一台節點則處於待命（備援）狀態，只有主節點故障時才會接手服務。 Active-Active 模式：兩台或多台節點同時運行服務，互相備援，平時都在積極處理流量。當其中一台節點故障時，其他節點會接手其服務。 所以，這次 control plane 採用的是 Active-Passive 模式。But why? 一定有什麼原因吧？（後來想起其實同事很久以前有說過，但我忘了，且當時也沒說那麼細，所以說做筆記很重要）。 Control plane v PostgreSQL Kong 的 Control Plane 負責集中管理 API Gateway 的所有設定、認證，以及 policy 和各種 plugins 的管理操作。不過 control plane 本身並不保存資料，只是管理和派送設定任務。所有設定與狀態資料都必須儲存在獨立運行的 PostgreSQL 資料庫裡，control plane 會以資料庫客戶端身份，透過網路連線到 PostgreSQL 資料庫伺服器，每次有設定變更、查詢、同步請求時都會讀寫這個資料庫。 根據官方文件1，PostgreSQL 不支援多台主機或多個資料庫 instance 同時掛載、讀寫同一份 data directory，否則可能會有資料毀損的風險。事實上，有人實驗過2，即使強行繞過 PostgreSQL 的檢查機制，在你啟用另一個 instance 時，原本掛載的 instance 也會被強制斷開。 ...

我喜歡在文章裡面放張圖，雖然現在 AI 生圖很方便，但還是喜歡放自然一點的，不論是自己拍的或是網路上看到的(from unsplash) 前言 在 Kong API Gateway 的日常維運中，Control plane 與 Data plane 的同步機制是個蠻值得關注的概念。最近在檢視公司架構圖時，我發現到 Control plane 與 Data plane 之間的 policy sync 方向標示為 Data plane 向 Control plane「拉取」最新設置。 簡單畫，公司實際架構圖沒這麼醜 在看到公司架構圖標示 Data plane 會「拉取」設定時，其實我一開始沒有多想，且防火牆確實只開了 Data plane 到 Control plane 的 8005 port。 但後來仔細思考，覺得這種設計有點奇怪——如果是 Data plane 不斷輪詢 Control plane 是否有設定變更，那輪詢頻率要怎麼抓？萬一設定異動很頻繁，會不會造成不必要的流量和效能浪費？而且從系統設計的角度來看，應該是由管理端（Control plane）主動通知執行端（Data plane）有異動才比較合理。這讓我開始思考，究竟同步機制的實際運作方式是什麼？ 這些疑問促使我去查官方文件，才發現實際上是 Control plane 主動推送設定(如下圖)，和我原本的認知有落差。 Control plane 與 Data plane 先簡單說明一下這兩個東西是什麼。 Kong Gateway 在 hybrid mode 下，有兩個重要的角色，分別為 Controle plane 與 Data plane，其功能分別為： ...

小弟最近要接手管理 APIM 了，會把踩的點記錄下來。 在管理 Kong API Gateway 的過程中，發現在啟用 IP Restriction Plugin 並設置白名單後，該 consumer 仍然驗證失敗。經確認此情況與 IP 置換有關。 該 consumer request 路徑為： Client → Load Balancer → Kong API Gateway → Backend Service 在這樣的架構中，Kong 接收到的 IP 並不是實際的 Client IP，而是來自 Load Balancer 的內部 IP。 經確認： Kong 接收到的 client_ip 顯示為內部網段 IP（例如：以 .254 結尾）。 這些 IP 實際上是 Load Balancer 的 IP。 導致 IP Restriction Plugin 誤判來源 IP，合法用戶被錯誤拒絕。 Nginx 真實 IP 辨識機制 Kong 是建構在 Nginx 之上，利用 Nginx 的 ngx_http_realip_module 模組來從 HTTP Header 中擷取真正的 Client IP，並改寫 $remote_addr。 ...

前言 整理一下在 Kong APIM 架構下，Redis 在快取與限流計數器同步上的應用。 因為之前沒接觸過，僅就目前理解部分紀錄，不會提到太多細節，未來有機會再補充～ Redis 快取的用途 Kong API Gateway 可以 Redis 來做快取，主要目的是可以快速回應重複的 API 請求，讓資料變動不頻繁的 API 可以直接回傳快取內容，可減少後端服務壓力。 限流計數器的同步需求 如果系統有對 consumer 限流需求，記錄在 db 是一個選項，但這樣就必須所有 gateway 的節點都跟 db 建立連線，且不適用於 dbless 或是 hybrid mode 的架構。 dbless 是指 data plane 的設置透過 kong.yml 來配置，每次配置都需要重啟服務。 hybrid mode 則是將 Control Plane 和 Data Plane 分離，CP 負責管理與同步設定，DP 專注於流量代理。DP 不直接連資料庫，只從 CP 接收設定。相反地，傳統模式沒有明確區分 DP 和 CP。每一台 Kong 節點同時扮演 CP 和 DP 的角色，也就是說，每個節點都可以管理設定（新增/修改服務、路由、插件等），這是 CP 的功能。每個節點也都會處理用戶端 API 請求，這是 DP 的功能，所有節點也都直接連接到資料庫。 ...